Ios 18.6.1 0-Click Rce Poc
Key topics
The iOS 18.6.1 0-click Remote Code Execution (RCE) Proof of Concept (POC) has sparked a lively debate about its potential value on the zero-day exploit market. Commenters are weighing in on whether Zerodium, a notorious zero-day broker, would be interested, with some pointing out that the company may not be operational anymore, rendering its value "$0". Others are discussing the exploit's worth, citing a "$15M" price tag for a full-chain mobile iOS exploit, although some are skeptical about such high prices being actually paid. The AirDrop requirement for the exploit is also seen as a significant factor in decreasing its value.
Snapshot generated from the HN discussion
Discussion Activity
Active discussionFirst comment
20m
Peak period
18
18-24h
Avg / period
6.2
Based on 56 loaded comments
Key moments
- 01Story posted
Aug 25, 2025 at 6:05 PM EDT
4 months ago
Step 01 - 02First comment
Aug 25, 2025 at 6:26 PM EDT
20m after posting
Step 02 - 03Peak activity
18 comments in 18-24h
Hottest window of the conversation
Step 03 - 04Latest activity
Aug 28, 2025 at 11:22 AM EDT
4 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
https://news.ycombinator.com/item?id=43025038
This might be a weird corner case where Apple would outbid the grey market, but generally even though Apple comes in lower than the grey market (for these very specific kinds of vulnerabilities), the term sheets are different, and the rest of the terms tend to favor going with Apple.
0. https://advance-sec.com/#bounty
We recorded a podcast with Mark Dowd a year ago where he said nobody actually gets "list prices" for iOS full chain at $2.5MM (you can make considerably more than that by selling to multiple parties and by selling maintenance) --- and that's iOS, the highest-valued vulnerabilities.
The DNG file did have the 01 byte at `2FD00` (from xxd or hexdump -C). However it didn't have a byte position `3E40B`. I tried searching and there is literally no entry at that position. I found a 02 value at 3e40 but not at 3e40b. Is this a typo?
Where did you find it to try and repro?
Did you find a 02 at 3E40B? I found 01 at 2FD00, but there was no 3E40B byte position entry.
I did find something similar at 00003e40: 00003e40 02 00 04 00 0a 00 00 00 30 01 00 00 00 00 00 00 |........0.......|
Curious if you (clearly smarter than me) know why it didn't show correctly in the xxd or hexdump for the file. Would love to learn.
I'm actually really curious about how the ITW exploit for this CVE worked; the OOB write is quite obvious in hindsight but going from OOB write to execution on iOS is very much not easy these days, and going from OOB write to sandbox escape should be extremely hard, especially since I thought (?) all image previews in iMessage should be behind BlastDoor. There's a lot of interesting stuff that's still missing here.
See my other comment. There's an exploit in the wild that uses this bug to get RCE, but this specific example just causes a crash.
> I'm actually really curious about how the ITW exploit for this CVE worked
It's really weird to see only a single OOB write patched for a full 0-click chain in the wild - how did they get code execution? PAC+ASLR bypass? Sandbox escape/kernel escalation?
Literally only RawCamera is patched in the update - were the other bugs in the chain already patched? Too difficult to patch immediately? (ie - close the front door while working on replacing the other locks?)? Still unknown? (ie - found a crash dump from RawCamera but didn't get as sample of the full chain?)
> For me, there is only lockdown mode. That is the Apple Experience.
iOS backups can be scanned for the presence of this CVE-2025-43300 DNG processing vulnerability, via OSS tool for iOS forensics, https://github.com/msuiche/elegant-bouncer | https://www.msuiche.com/posts/elegantbouncer-when-you-cant-g...
https://x.com/darknavyorg/status/1959271176062251333> While reproducing the iOS ITW CVE-2025-43300 (support.apple.com/en-us/124925), we accidentally triggered another old DNG image parsing vulnerability. The analysis is still ongoing.
https://docs.mvt.re/en/latest/iocs/
I am interested in finding out more on why Yara can't be used to find structural patterns? it is supposed to do a lot more than simple string and byte-pattern matching. Maybe ELEGANTBOUNCER requires keeping/maintaining a complex state machine to evaluate/analyze content?
For non-iOS defense, run GrapheneOS with all the default safeguards enabled.
"Fuzzing ImageIO" (2020), https://googleprojectzero.blogspot.com/2020/04/fuzzing-image...
> This blog post discusses an old type of issue, vulnerabilities in image format parsers, in a new(er) context: on interactionless code paths in popular messenger apps. This research was focused on the Apple ecosystem and the image parsing API provided by it: the ImageIO framework. Multiple vulnerabilities in image parsing code were found, reported to Apple or the respective open source image library maintainers, and subsequently fixed. During this research, a lightweight and low-overhead guided fuzzing approach for closed source binaries was implemented and is released alongside this blogpost.
"ImageIO, the infamous iOS Zero Click Attack Vector" (2024), https://r00tkitsmm.github.io/fuzzing/2024/03/29/iOSImageIO.h...
> I used LLDB to examine the testHeader functions, it turned out there are three new testHeader functions for different file formats, such as KTX2 and WebP and ETC, so because they were fairly new I thought maybe they have not been fuzzed by Project Zero... I ported Project Zero’s harness to Jackalope fuzzer.. My fuzzing effort found several vulnerabilities [fixed by Apple]..
Identifying an exploit in iOS requires a significant amount of knowledge in how the OS works, what existing exploits are and how you could chain them together to create a larger exploit.
I've have very limited experience, but reading about how some people identify and exploit these things is extremely impressive.
I don't see them using Rust when they have their own language under their full control, especially since both are targeting LLVM anyway.
https://citizenlab.ca/2025/06/first-forensic-confirmation-of...
https://citizenlab.ca/2023/09/blastpass-nso-group-iphone-zer...
https://citizenlab.ca/2021/09/forcedentry-nso-group-imessage...
https://citizenlab.ca/2020/12/the-great-ipwn-journalists-hac...
[1] https://support.apple.com/en-us/124925
macOS Ventura 13.7.8 | macOS Sonoma 14.7.8 | macOS Sequoia 15.6.1
iPadOS 17.7.10 | iPadOS 18.6.2 | iOS 18.6.2
Usually, its multiple CVE's in a security update.
Examples:
- https://support.apple.com/en-us/122375 (macOS Ventura 13.7.5)
- https://support.apple.com/en-us/122718 (macOS Ventura 13.7.6)
- https://support.apple.com/en-us/124151 (macOS Ventura 13.7.7)
--------------------------- References/Sources ---------------------------
[0] https://support.apple.com/en-us/124925 -> https://support.apple.com/en-us/124929 | (124925 -> 124929)
https://support.apple.com/en-us/100100
https://nvd.nist.gov/vuln/detail/CVE-2025-43300#vulnConfigur...