Apple patches decade-old iOS zero-day, possibly exploited by commercial spyware
- Reference: 1770904873
- News link: https://www.theregister.co.uk/2026/02/12/apple_ios_263/
- Source link:
CVE-2026-20700, discovered by Google's Threat Analysis Group, affects dyld - Apple's dynamic linker - and allows attackers with memory write capability to execute arbitrary code. Apple said the flaw was exploited in the wild and may have been part of an exploit chain.
Its [1]advisory stated: "An attacker with memory write capability may be able to execute arbitrary code. Apple is aware of a report that this issue may have been exploited in an extremely sophisticated attack against specific targeted individuals on versions of iOS before iOS 26."
[2]
Google's researchers also referenced two December vulnerabilities in their report that both carry 8.8 CVSS scores.
[3]
[4]
CVE-2025-14174 is an out-of-bounds memory access flaw in Google Chrome's ANGLE graphics engine on Mac that could be exploited through a malicious webpage.
The other, CVE-2025-43529, is a use-after-free leading to code execution.
[5]
Brian Milbier, deputy CISO at Huntress, said: "Think of dyld as the doorman for your phone. Every single app that wants to run must first pass through this doorman to be assembled and given permission to start.
"Usually, the doorman checks credentials and places apps in a high-security 'sandbox' where they can't touch your private data. This vulnerability allows an attacker to trick the doorman into handing over a master key before security checks even begin."
[6]Ireland wants to give its cops spyware, ability to crack encrypted messages
[7]Stalkerware slinger pleads guilty for selling snooper software to suspicious spouses
[8]Apple, Google forced to issue emergency 0-day patches
[9]Two Android 0-day bugs disclosed and fixed, plus 105 more to patch
By chaining this with WebKit flaws Apple also addressed in the iOS 26.3 update, "attackers have created a 'zero-click' or 'one-click' path to total control. They use a fake ID to bypass the front gate – your browser – and then exploit the doorman's flaw to take over the entire building," Milbier added.
"This level of sophistication resembles other exploits developed by the commercial surveillance industry. These are private companies that also developed prominent spyware tools like [10]Pegasus and [11]Predator . They sell these types of exploits or tools to government clients. While some updates in this patch address minor issues, such as data leakage from physical access, the dyld/WebKit chain is in a different league. iOS 26.3 closes a door that has been unlocked for over a decade."
Apple's updates for iOS and iPadOS also feature a host of other fixes for various bugs, including flaws that grant root access and disclose sensitive user information, but CVE-2026-20700 is the only one it said was exploited in the wild. ®
Get our [12]Tech Resources
[1] https://support.apple.com/en-us/126346
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/cybercrime&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2aY4HMAQAU4P7GIN-xSBLPwAAAUQ&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/cybercrime&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aY4HMAQAU4P7GIN-xSBLPwAAAUQ&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/cybercrime&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33aY4HMAQAU4P7GIN-xSBLPwAAAUQ&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/cybercrime&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aY4HMAQAU4P7GIN-xSBLPwAAAUQ&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[6] https://www.theregister.com/2026/01/21/ireland_wants_to_give_police/
[7] https://www.theregister.com/2026/01/07/stalkerware_slinger_pleads_guilty/
[8] https://www.theregister.com/2025/12/15/apple_follows_google_by_emergency/
[9] https://www.theregister.com/2025/12/02/android_0_days/
[10] https://www.theregister.com/2024/04/02/polish_pegasus_inquiry/
[11] https://www.theregister.com/2024/09/17/predator_spyware_sanctions/
[12] https://whitepapers.theregister.com/
Re: Two decades
You're really over-egging the Rust thing, sorry.
Rust just makes you put unsafe code inside an unsafe declaration - it does nothing to stop it happening. And code inside unsafe can destroy the guarantees of surrounding safe blocks.
But the biggest problem - there are some things which are IMPOSSIBLE to do outside an unsafe declaration - many of them at the system layer (like device drivers, DMA, bus interfacing, self-modifying code, etc. etc. etc.).
Just writing something in Rust doesn't fix it. It just means that you put a nice little warning cone around the potentially-dodgy statements. That's all it does. It doesn't do anything about AVOIDING THE NEED for those unsafe statements.
Literally anything that assumes the values or bounds referenced in a piece of arbitrary memory (i.e. every hardware interface like USB, PCI, etc.) is "unsafe". Basically anything that you'd use a pointer derefernece or casting for in C code. You can't write a device driver for 99% of modern hardware in "safe"-statements-only Rust. It's simply not possible.
All it is in a warning cone, like "Wet Floor". That's it. And you can't just avoid having to mop your floors.
Applications - yes, slightly different. Most applications do not need such functionality (but not all!).
However at an OS level, there is no avoiding unsafe code, and the only difference between C and Rust is that Rust puts a little warning cone over it. You can still screw up the OS and get compromised by it, and it can even break your "safe" code that's nearby (memory-wise, not necessarily source-code-wise).
Re: Two decades
You're sidestepping the fact that all code outside of the 'unsafe" blocks is safe and that in regular C *all* code is inherently unsafe. Even in operating systems the (vast) majority of code can be written in safe Rust.
As far as device drivers are concerned: it depends on the driver. If you're writing a simple driver for a UART chip where you manipulate some registers then most of the code is probably unsafe. Others have much more logic and memory manipulation in them that would greatly benefit from Rust.
Remember...........................
..................Jamal Khashoggi!
Security by obscurity
Apple’s security model is built on extreme platform control, not transparency.
Yes, iOS blocks a lot of low-effort malware. That keeps devices free from the visible chaos people associate with insecurity. No toolbars. No random AV pop-ups. No obvious nonsense. That part works.
But users are also not permitted to inspect their own systems in any meaningful way. You cannot run a deep system scanner. You cannot examine kernel integrity. You cannot install independent security tooling with sufficient privileges to verify what is actually happening on the device. You are structurally prevented from checking.
At the same time, iOS has repeatedly been compromised by high-end (notice the PR spin, someone compromised iOS then it must be high-end ;-) ) exploit chains, including zero-click spyware deployed against journalists and activists. Victims had no visible signs. That is documented history.
Apple allegedly patches these vulnerabilities, often with minimal initial disclosure. There is no built-in forensic mode that tells an owner, “your device was compromised.” There is no official scanner that says, “this device shows indicators of a Pegasus-class infection.” The model is: update, move on, trust me bro.
So the public experience is cleanliness. The underlying reality is that integrity verification is monopolised by the same company that builds the system.
You are not allowed to independently verify whether someone is listening. You are required to trust that no one is.
I guess too many fingers got into that disclosed hole, so Apple likely introduced a new one for security services.
Two decades
If it was present in iOS 1.0 then was present for almost two decades since the first iPhone came out in 2007.
This is quite a long time for a vulnerability not to be noticed. And it's no wonder everyone's migrating towards Rust. You cannot assume every developer has sufficient skills to sidestep these pitfalls. And then there's deadlines and managers shouting in your ear. It's wonderful someone came up with a systems programming language which downright prevents you from making mistakes.