Loading vulnerability…
CVE-2024-27804 is a memory-handling vulnerability in AppleAVD. An application may be able to trigger unexpected system termination. Apple addressed the issue through improved memory handling in iOS 17.5, iPadOS 17.5, macOS Sonoma 14.5, tvOS 17.5, visionOS 1.3, and watchOS 10.5.
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.
2 valid exploits after Mallory filtered fakes, detection scripts, and README-only repos.
This repository is a proof-of-concept (PoC) iOS application demonstrating CVE-2024-27804, an information disclosure vulnerability in Apple's iOS (specifically 17.3/17.3.1). The exploit is implemented in Objective-C and C, with the main logic in Exploit.m and flip.c. The application loads a crafted video file and uses AVFoundation to process video frames, while interposing the IOConnectCallMethod kernel API to leak kernel memory from the kalloc.4096 zone. Leaked addresses and values are logged in the app's UI. The exploit is local and requires the app to be run on a physical iOS device with the vulnerable version. The repository is structured as a standard iOS app with UI components (ViewController), exploit logic (Exploit, flip.c), and standard app boilerplate (AppDelegate, main.m, info.plist).
This repository is a proof-of-concept (POC) exploit for CVE-2024-27804, targeting Apple devices running Darwin Kernel 23.2.0 (macOS, ARM64). The exploit demonstrates a kernel panic triggered by corrupting memory during video decoding via the VideoToolbox framework. The repository contains: - `flip.c`: Implements a dynamic library (flip.dylib) that interposes the IOConnectCallMethod function, flipping a bit in a buffer to corrupt memory. - `vtdecode.m`: Objective-C program that loads a video file and decodes it using VideoToolbox, running the decoding in-process and calling a specific function (VTApplyRestrictions) to ensure the decoding does not use a separate service. This increases the likelihood of triggering the vulnerability locally. - `build.sh`: Compiles the exploit components. - `panic.sh`: Runs the exploit by setting the DYLD_INSERT_LIBRARIES environment variable to load the malicious dynamic library and then executing the vtdecode binary on a sample video file. - `README.md`: Provides usage instructions and includes a sample kernel panic log, showing the effect of the exploit. The exploit is local-only and requires the user to execute the code on a vulnerable system. It does not provide remote code execution or privilege escalation, but demonstrates the ability to crash the kernel (denial of service) by corrupting memory in the VideoToolbox subsystem. The endpoints of interest are the VideoToolbox framework path and the sample input video file. The code is written in C, Objective-C, and Bash, and is structured as a typical POC for a kernel-level vulnerability.
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.
3 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.