Or just spend a few billion tokens rewriting the whole chain in a memory safe language. This nonsense is inexcusable in 2026
it's a feature. expect next exploit to also be pdf or image related.
So pdf and images are the best vector for iPhones.
Once you escape the parser you have to reach and escape the sandbox and from there reach the kernel.
The best solution would be ditching it completely for a simpler subset of features. But that will never happen.
Like the saying goes:
Everyone uses only 20% of the features, but it's a different 20% for different people.
"~70% of the vulnerabilities Microsoft assigns a CVE each year continue to be memory safety issues" - Microsoft [1]
"We adopted Rust for its security and are seeing a 1000x reduction in memory safety vulnerability density compared to Android’s C and C++ code." - Google on Android [2]
This is also worth looking: https://www.chromium.org/Home/chromium-security/memory-safet...
References: 1. https://www.microsoft.com/en-us/msrc/blog/2019/07/a-proactiv... 2. https://blog.google/security/rust-in-android-move-fast-fix-t...
They don’t seem convinced that that would be a meaningful use of time for them. (2025)
https://itsfoss.com/news/ffmpeg-swipe-at-rust/
And 6 months ago someone did a little experiment using Claude to rewrite FFmpeg in Rust. It was by the own description by the person that had the AI do it, significantly slower than FFmpeg even when incorporating assembly code from FFmpeg.
https://github.com/sharifhsn/wedeo
Maybe with further advancements it is now possible to get a better result, or soon.
But if you are going to copy their assembly code into the Rust protect how do you definitively prove that no memory unsafe operations are happening in those parts? Seems to me that either the whole thing should be safe Rust, if the point of the rewrite is memory safety.
You certainly can still write security vulnerabilities that don't involve memory safety violations, and these languages always have unsafe escape hatches that you can use to shoot yourself in the foot. But as long as you don't just sprinkle unsafe on everything, using a safer language is going to make a ton of vulnerabilities just disappear.
Looking at the issues from this past week, safe languages won't stop you from using 4 as your private key, but they would have entirely prevented the PHP vulnerability.
On less powerful machines, dear Mutt+isync+msmtp users like me, please use AERC (written in Go) against these. It's slower, but far more secure than C. Also, SLRN needs a Go rewritten clone (able to point to slrn's caché) like nothing else. Comp.misc and comp.arch still are extremely valuable.
Who am I kidding, I think the PDF format will outlive us.
if apple parsed pdf with (js, swift, rust) none of this would be possible. the problem is memory-unsafe code.
Interpreters and compilers can have bugs. Bugs can cause memory safety issues.
They have the means, they have the motivation
Lately they have fewer and fewer excuses not to