$0, given it's patched in ios 18.6.2

$0, since I don't think Zerodium still exists.

I know the thread is saying $0 because Zerodium doesn't exist anymore, but there are others. This [0] one for a full chain mobile iOS is at $15M. I agree with tptacek though, the airdrop would reduce the value but you may still be in the low 7 figure range for 0 click RCE.

0. https://advance-sec.com/#bounty

Maybe you need to iMessage it to someone else? Just guessing.

I downloaded the image he provided (https://www.dpreview.com/sample-galleries/4949897610/pentax-...)

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?

  dd status=none if=IMGP0847.DNG bs=1 skip=0x3e40b count=1 | xxd
  00000000: 02

  xxd IMGP0847.DNG | grep 03e400:
  0003e400: ffd8 ffc3 000e 0e10 800c 5002 0011 0001  ..........P.....

>Where's the 0-click or the RCE 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.

Apple patched it on August 20, so presumably any release from after this date is not vulnerable.

I would think mvt and related ioc repos would support these newer indicators,but sadly I'm not seeing that:

https://docs.mvt.re/en/latest/iocs/

  Traditional detection approaches like YARA rules, IOC matching, and signature-based systems fall apart when:

   • You don’t have the actual malicious samples to create signatures from
   • The attackers use polymorphic techniques that change file hashes
   • The exploit leverages legitimate file format features in unexpected ways
   • You need to detect future variants of the same technique

  The Philosophy: Structure Over Signatures

  ELEGANTBOUNCER takes a fundamentally different approach to threat detection. Instead of looking for specific byte patterns or known-bad indicators, it analyzes the structural properties of files that make exploits possible.

Assuming someone hasn't removed it from the filesystem

>For iOS defense, enable Lockdown Mode and reboot daily to evict non-persistent malware

For non-iOS defense, run GrapheneOS with all the default safeguards enabled.

Experience /n Fuzzing (when you try a bunch of stuff automatically) /n Reverse engineering the code (using tools like ghidra or hopper)

Lots of experience in what are common exploit tactics are and where to look and test if things will break.

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.

Fuzzing is one approach.

"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]..

I have no idea what you're talking about; Apple has one of the largest and most sophisticated software security practices on the planet.

ImageIO has been fuzzed by Google and others, https://news.ycombinator.com/item?id=45034650

Look up iMessage's "blastdoor" sandbox: https://support.apple.com/guide/security/blastdoor-for-messa...

unfortunately sandboxes also have bugs which allows for RCE. this is typically called a "full chain" because it chains together a series of bugs (initial decoder exploit + sandbox escape exploit) to gain full RCE

For some reason, Apple seems reluctant about using Rust on their operating systems.

Also image formats are fairly stable, so they are a good candidate for a verified F* parser. Not sure how easy it is for pdf, maybe start with a reasonable subset of it.

Apple should formalize the iMessage de facto DeviceAndAccountTakeover() API call. I lost count how many zero-click it has. Tim Apple can take the privacy high road all day but it doesn't matter if the code is rotten.

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...

This isn't just an iOS thing, and they do sandbox it. Parsers are hard.