Apple patches decade-old iOS zero-day, possibly exploited by commercial spyware

Apple patched a zero-day vulnerability affecting every iOS version since 1.0, used in what the company calls an "extremely sophisticated attack" against targeted individuals. CVE-2026-20700, discovered by Google's Threat Analysis Group, affects dyld - Apple's dynamic linker - and allows attackers with memory write capability …

[Anonymous Coward]

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.

[Lee D]

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

[Anonymous Coward]

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.

[Lee D]

Re: Two decades

I'm not, because it's not true.

Unsafe code can destroy the safe guarantees of nearby (stack-wise, memory-wise) safe code, just the same as with C.

[Blazde]

Re: Two decades

Unsafe code can destroy the safe guarantees of nearby (stack-wise, memory-wise) safe code

This is not a profound thing to say. It's just what it means to have an arbitrary code execution vulnerability: everything is undermined. That's why it's bad.

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.

You couldn't be more wrong. Rust does an awful lot of smart things to hugely reduce your need to write risky code in the first place. The unsafe blocks are really a last resort and almost never needed in the vast majority of code. It doesn't sound like you have any familiarity with the language at all.

[Anonymous Coward]

Re: Two decades

Or with C for that matter.

It's the same old story again: people arguing you just "have to be smarter" and there's no need for Rust or any other safe language.

[rmullen0]

Re: Two decades

How many people that upvoted this drivel know the first thing about programming? Keep on keeping on with the status quo. It's working out real well for you. Luckily, we live in a perfect world where every developer is 100% skilled and never lets in any buffer overflows. You are right. Don't rely on better tools. Just keep doing things manually. No wait. You all must love running in a hamster wheel and constantly having to patch security holes many of which memory safe languages would eliminate. Self modifying code? Enlighten me on how often that is used. How many buffer overflows appear in drivers versus everywhere else? You sound like a C programmer who is unwilling to change. Insanity is doing the same thing over and over and expecting different results. Moving to memory safe language is decades overdue. It has been obvious for a long time now.

[Mishak]

However, there is also the other side

Rust (and other players) do not guarantee that the code is correct, so logical and requirements errors can still lead to serious vulnerabilities.

Even formal methods cannot guarantee this, as formal proofs can be vacuous (they prove "something", but that may actually be what you wanted).

Still, better tools are better tools - including those for anyone using C (et al) for critical system who want to ensure they are not leaving themselves open to claims of being negligent.

[Anonymous Coward]

Re: However, there is also the other side

> Rust (and other players) do not guarantee that the code is correct

Without a formal language specification, there can be no guarantees or certainty over what Rust does or doesn’t do; Ada on the other hand…

[Anonymous Coward]

Re: However, there is also the other side

No computer language can prevent logical errors. Yes, read that again. None. Nada. Zip.

But Rust prevents memory errors, which is about three-quarters of all programming errors.

[Anonymous Coward]

Re: Two decades

"All it is in a warning cone, like "Wet Floor". That's it. And you can't just avoid having to mop your floors."

And even a "Wet Floor" sign is not unambiguous: is it a warning or an instruction?

OK, that might be a jokey comment/question but I use it to illustrate that, without an understanding of contemporary context, even a simple message can be misunderstood.

There's a train of argument, to support "text-speak" that says an adherence to rules of grammar doesn't matter as long as the message is understood. That part of the argument is relatively sound - but its application is far from sound. A few years ago, I was marking an academic assignment from a student - the assignment had to be submitted in the form of a report to senior management. In the main body of the report, the student presented a good argument for a necessary course of action. Unfortunately, a misplaced comma in the leading bullet point in the report's Conclusions section meant it said the exact opposite of what they'd previously argued. In the real world, gatekeepers in business (often senior managers) rarely have time to read through every report put before them. They'll rarely get beyond the Executive Summary before deciding if it needs further attention; if it does, then they'll usually turn to the Conclusions and Recommendations - the main body of the report is only read when actions are to be taken. Had that been a genuine report and not an academic assignment, it's probable the report would have been filed away under no further action and, depending of the nature of the study, could have led to serious problems for the business.

That's a digression from the ICT focus but I offer it to illustrate that seemingly simple (and seemingly out of date) rules of grammar can become significant. Some rules originate from commonly agreed practice, others from a need to prevent the recurrence of specific problems. Either way, it's not often we ever question why a specific rule is there - we either follow it on the assumption it is still valid or ignore it because we don't understand its relevance. The latter viewpoint is often supported by a lack of previous experience or knowledge; if we've never been exposed to a danger we rarely appreciate the risk.

[waldo kitty]

Re: Two decades

And even a "Wet Floor" sign is not unambiguous: is it a warning or an instruction?

context is important... if that phrase is specifically on a warning cone or warning sign then the phrase is a warning... especially if preceded or followed by "Caution" or another attention grabbing word which may be hilighted in some manner to increase its impression on viewers... if those words were simply on a poster stuck on some random wall or pole, then they would be more ambiguous... but again, context matters...

[Anonymous Coward]

Re: Two decades

>” You cannot assume every developer has sufficient skills to sidestep these pitfalls.”

If you have the skills to use Rust and most of the produce code that compiles with few problems, I suggest you have the skills necessary to write C or C++ programs that avoid the pitfalls…

[Anonymous Coward]

Remember...........................

..................Jamal Khashoggi!

[elsergiovolador]

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.

[amanfromMars 1]

Re: Security by obscurity ..... for Beings in Support of the LOVE* of Apple

Apple’s security model is built on extreme platform control, not transparency. ..... I guess too many fingers got into that disclosed hole, so Apple likely introduced a new one for security services. ..... elsergiovolador

If Apple wanted to singularly mentor administrative rule and monitor exclusive executive reign over multiple security services it would create and introduce two new extreme control platforms - one for security services and another one with new secret security modelling for a novel security service for itself and superintelligently designed to ideally result in ...... well, One Ring to rule them all, One Ring to find them, One Ring to bring them All Out of Darkness and Bind them with Enlightenment.

It is surely not as if they couldn’t do it if they wanted to, is it, even if it be a Client wanting Apple to do it on their behalf and being fully prepared to suitably and probably quite excessively reward them for the privilege and Proprietary Intellectual Property Beta Testing.

* .... Live Operational Virtual Environment

[Jou (Mxyzptlk)]

Write access is enough?

Which results in: Every app, literally, could exploit it. Is there no NX-bit used in iOS? 'cause I cannot believe that the underlying hardware would miss such a feature...

[Dan 55]

What?

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

Sorry, is this supposed to make it easier to understand? I'd rather just stick with the technical description.

[heyrick]

Re: What?

Means you can be pwned through the browser. A pretty good argument in support of asking why browsers have tentacles into so many parts of the OS.

Oh, and does Apple still consider Safari to be an integral part of the OS, or can you now update it separately?

[DS999]

Once again I wish

That when Apple reports on stuff like this they'd also report which hardware is vulnerable. This is exactly the sort of thing that MIE (memory integrity enforcement, introduced with A19/M5 and iOS 26) was intended to fix.

I'm sure they will update us about this at some point in the future, and note which CVEs were automatically mitigated by MIE but it would be better to get that information as part of the CVE.

[mw_foot]

You will update to IOS 26.3

Apple also took the opportunity to stop offering iOS 18 updates to any iPad apart for 7th generation iPads. There’s going to be a lot of vulnerable devices floating around.

[Steve Davies 3]

Re: You will update to IOS 26.3

You might be right but OTOH, Apple did release an IOS update for the iPhone 5 recently. There may well be releases of update for older iPhone and iPad devices that get rid of this issue.

[DS999]

Re: You will update to IOS 26.3

Yeah they sometimes do this but it can be a few days to a week before the older version patches hit.

[rmullen0]

In a just world the scumbags developing and selling these hacks would be locked up

They are nothing but criminals. But, the world already sees that. They see the genocide that is going on in Palestine and know that Israel and the United States are the two biggest criminal organizations on the planet..

[mark l 2]

Considering the vast amount of money Apple is sitting on, i am surprised they don't set up a shell company and purchase some of these commercial spyware tools and then reverse engineer them to see what vulnerabilities they are using on iOS/MacOS so they can be patched. Or am thinking wishfully thinking that Apple likes to stop bad actors abusing their software more than they like their piles of money?

[waldo kitty]

Pro Tip: Always assume there's at least one fox in the hen house until otherwise proven, beyond the shadow of doubt, that all occupants of the hen house are, in fact, the chickens that should be there...

no "shell company" needed, really... someone who is familiar with the grey and darker alleys of the 'net could easily get their hands on the software and dissect it... as long as they have the funds, money talks... "corporate espionage" by any other name, ya know? ;)

[rmullen0]

The IDF is known for infiltrating companies.

[heyrick]

"then reverse engineer them to see what vulnerabilities they are using"

Because not pushing too hard keeps the Three Letters off their backs, while giving plausible deniability.

[amanfromMars 1]

Methinks .....

..... whatever moneybags Apple are going to be doing should always be leaving contemporaries and competition and opposition in the dark and following in their wake. How else are they to successfully lead the deaf, dumb and blind into the future?

The only question to ask is WTF is stopping them from doing what is necessary? Are they missing a few vital key components/correspondents?

[Taliesinawen]

Buffer overflow in dynamic linker/loader

Puzzling how the MMU didn't catch this.

[Anonymous Coward]

And Then There's This Apple Lunacy......

https://www.jalopnik.com/2096908/apple-watch-unlock-car-models-how-to/

Really?