CVE-2026-64747 is a buffer overflow in Apple’s AVEVideoEncoder component. Insufficient size validation may allow a locally executing application to trigger memory corruption and execute arbitrary code with kernel privileges. Apple addressed the issue through improved size validation.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
3 valid exploits after Mallory filtered fakes, detection scripts, and README-only repos.
This eight-file C research repository documents CVE-2026-64747 in Apple's AppleAVE2 video-encoder kernel driver. Its primary artifact, poc_ave2_reach.c, uses direct macOS IOKit APIs and the accompanying ave2_wire.h layout definitions to match the local AppleAVE2Driver service, open an encoder user client with type 1, create a session through selector 1, and issue an asynchronous selector-4 configure request. README.md, WIRE_FORMAT.md, and FIRE_READY.md provide reverse-engineered selector contracts, structure sizes and offsets, validation behavior, and the claimed vulnerable/fixed arithmetic differential; evidence files contain I/O Registry output and kernel logs from fixed-host validation runs. The claimed flaw is an unchecked 32-bit LRB (lookaside reference buffer) size calculation in the HEVC 10-bit multipass path, where the calculator is called with parameter 2 equal to 5. The documented 64656x8080 dimensions, with 4:2:0 chroma and 10-bit depth settings, yield a 0x80000000 aggregate result while remaining below a separate product clamp. In the vulnerable 905.36.1 calculator this may lead to a negative effective allocation size, an undersized DART/IOMMU work buffer, and subsequent encoder DMA memory corruption. The fixed 905.40.1 implementation adds component and 64-bit total overflow checks. This is a local reachability/trigger-construction PoC rather than a complete privilege-escalation exploit. The included evidence was collected on macOS 26.6.2 with fixed AppleAVE2 905.40.1, where the crafted dimensions reached deep codec validation but were rejected by a device-capability check before the LRB calculator. The repository acknowledges that capability-table acceptance and exact mode-5 dispatch selection remain unresolved, so no successful overflow or RCE is demonstrated.
This repository is a research exploit/trigger set for Apple AppleAVE2 / AVEVideoEncoder integer-overflow-to-kernel-OOB-write exploitation, centered on CVE-2026-64747. The main exploit capability is to supply oversized video dimensions, especially 65537x65537, so width*height overflows a 32-bit calculation, producing an undersized buffer allocation and then an out-of-bounds kernel write during encoding. Repository structure has three main parts: (1) a Swift/iOS app under IPA/AVE263 that provides multiple trigger paths, (2) C probe programs under probes/ for direct AppleAVE2Driver user client experimentation, and (3) markdown reports documenting reverse engineering, offsets, exploit-chain reasoning, and post-exploitation ideas. The GitHub Actions workflow builds an unsigned IPA and signs it ad hoc with entitlements. The Swift app contains three variants: AVERunner.swift uses AVAssetWriter and VTCompressionSession to reach the encoder through normal media frameworks; AVERunnerV2.swift cycles through several dimension sets and logs callback behavior; AVERunnerV3.swift bypasses framework validation and directly opens the AppleAVE2Driver IOKit service, probing selectors 0-15. AppDelegate.swift exposes these as UI buttons in a simple test app. AVE263Trigger.swift is a standalone minimal trigger class with the same oversized-dimension concept. The C probes are more low-level. ave_probe5.c enumerates AppleAVE2Driver IOExternalMethodDispatch selectors 0-8 with exact structure sizes. ave_probe6.c focuses on IO_Open and related methods with candidate field layouts. ave_probe7.c attempts a fuller chain: IO_Open followed by IO_Start using oversized dimensions to hit the vulnerable multiplication path. physrw_helpers.c is not a working payload but a post-exploitation sketch describing how an OOB write might overwrite a device object field, redirect a PAC-protected vtable call through object replacement, and then derive kernel read/write primitives. No network C2 or remote endpoints are present. Fingerprintable targets are local/OS-specific: the AppleAVE2Driver IOKit service, AppleAVE2UserClient entitlement class, private AVE entitlements, the temporary file poc.mov, and specific IOKit selectors. Overall, this is an operational local kernel exploit research repository for iOS/iPadOS devices, not merely a detector or README.
This repository is a standalone Swift/Xcode iOS application, not part of a common exploit framework. Its purpose is to probe and potentially trigger CVE-2026-64747, described as an Apple AGXG14P command queue count-bitmask out-of-bounds condition on iPhone 13/A15 running iOS 26.5.2. The repo contains 12 files total, with the main logic in four Swift source files: AGXProbeApp.swift (app entry), ContentView.swift (UI/controller), AGXStress.swift (GPU stress/trigger logic), and AGXDump.swift (userland binary dumping). There is also an Xcode project, Info.plist, README, GitHub Actions build workflow, and a large repos.json metadata file. The main exploit capability is in AGXStress.swift. It creates a Metal device and command queue, builds inline Metal shader code at runtime, and repeatedly exercises multiple GPU submission patterns intended to influence the vulnerable queue count bitmask path. The documented phases include slotStorm, eventStorm, bitStorm, maskStorm, hugeBatch, inFlight, fenceStorm, renderPath, multiQueue, computeHeavy, chainedEvents, and mixed. These phases attempt to drive high-bit values, large batches, many in-flight command buffers, fences, render/compute/blit activity, and multi-queue pressure. The expected outcome is not code execution but empirical triggering of the kernel bug, evidenced by app death, GPU stall, or full device reboot/kernel panic. Because no post-exploitation payload or shell is included, this is best classified as a proof-of-concept trigger probe rather than a weaponized exploit. A secondary capability is AGXDump.swift, which enumerates dyld-loaded images in the current process and dumps binaries whose paths contain AGX, Metal, CoreMTL, IOKit, or IOGPU. It reconstructs rebased memory images from mapped segments and writes them to the app Documents directory under agx_dump, along with metadata text files containing segment and symbol table information. This supports reverse engineering of the userland side of the vulnerability without jailbreak access. No network exploitation or C2 behavior is present. The observable endpoints are almost entirely local file paths and artifact names: the app writes agxprobe.log and agx_dump outputs into the Documents directory, exposes them via UIFileSharingEnabled, and the CI workflow builds AGXProbe.app and packages AGXProbe.ipa. The README references sideloading/install URLs and operational guidance, but the exploit logic itself does not contact remote hosts. Overall, the repository is a local, device-resident iOS GPU vulnerability trigger harness plus binary-dumping utility for Apple AGX/Metal reverse engineering. It is a real exploit-related PoC, but not a full exploit chain and not a detection-only script.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
4 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.