A zero-day in December, off-the-shelf ammunition in August

On 12 December 2025, Apple fixed a WebKit flaw with one of those sentences everyone skims: it was aware of a report that it may have been exploited "in an extremely sophisticated attack against specific targeted individuals". Practical translation for an SME: this is expensive espionage and it is not about you. Two hundred and fifty-eight days later, that same flaw was being served to anyone who opened a gas company's website on an out-of-date iPhone.

On 4 November, the French firm Sekoia published its analysis of that campaign. Three exploit chains — two against iOS, one against Android — served from legitimate websites during one week in late August 2026. And one sentence in the middle of the report: "All three exploit chains rely entirely on known, already-patched vulnerabilities. None of them contain zero-days or work against fully updated devices. Each flaw was resolved by the respective vendor before this campaign began."

What we take from all this is the column that never makes a headline: how many days each piece's patch had been published when it was fired. And the device everything came through, which was the phone and not the server: the one part of the fleet that in most companies has no inventory, no update window and no owner.

Seven days inside somebody else's website

What is hard to swallow about this campaign is how it arrived. Between 27 August and 3 September 2026, the attacker injected code into the file of a Ukrainian web analytics service, Plerdy, loaded by thousands of pages. The addition fits in five lines: once the page finishes loading, create a script tag, point it at someone else's domain, and attach it to the document. That is all. The visitor's browser did the rest, obediently.

During that week, Sekoia says, hundreds of sites were exposed — among them army, special forces and military equipment pages — plus websites compromised one by one: a Ukrainian gas producer, a US chemical industry trade association, a European far-right political party and a Bulgarian military site. Plus two fake domains mirroring real ones. Nobody downloaded an attachment. Nobody clicked a strange email. People opened a page they had been visiting for years.

Your website's perimeter is not your code. It is the list of domains your pages tell the visitor's browser to trust. Analytics, maps, chat, web fonts, the campaign pixel somebody set up in 2019. We wrote about this in another context, when we said your inventory has no line for Brotli: the problem arrives when that list exists nowhere.

How old each piece was

We built this table ourselves by crossing the chains Sekoia describes with each vendor's advisory dates. The last column is calendar days up to 27 August 2026, the day the campaign started.

Three pieces of the long iOS chain are missing — CVE-2025-14174, CVE-2025-43510 and CVE-2025-43520 — all also fixed: the first is WebKit and shipped on that same 12 December; the two kernel ones were fixed earlier, on 5 November 2025 in iOS 18.7.2 — 295 days — although Apple only added their entries to that page on 12 December. And four more are surplus: the kit carried two 2024 flaws inside it as dead, unreachable code — Sekoia says probably from an earlier version of the tooling — plus two alternative routes it never used. An exploit with technical debt. Where that debt comes from is in the report itself, two sections below.

The Qualcomm row deserves a note, because it is the one that translates worst into an action. The vendor bulletin is dated 2 June 2025 — and there Qualcomm already wrote that Google TAG had indications of «limited, targeted exploitation», so this one started as a zero-day too — but a graphics driver patch does not reach a phone when Qualcomm publishes it: it arrives when the device maker integrates and ships it, if it does. We covered another layer of the same problem: the Android patch does not reach the modem. Counting from the August 2025 Android bulletin, where SecurityWeek places it, gives roughly 387 days instead of 451. Still more than a year. The Chrome row has the same problem in reverse, and we will say it before anyone else does: 12 March is the desktop channel date, and the chain attacks Chrome on Android; we could not pin the exact Android channel date to a primary source, so the 168 is our count over the desktop date. And there is a third: the long chain's PAC bypass was fixed on 11 February in iOS 26.3, and we have found no Apple page fixing when that fix reached the 18.x branch. If it did not, then for an iPhone on 18.5 the patch was not on its branch and the 197 days are not comparable with the rest.

What stopped the old chain was one decimal point

The short chain targets iOS 16.7 and, per the report, should work from 16.0 to 17.4 — "should work", Sekoia writes; that is their estimate, not a tested matrix. It is no accident that the ceiling falls right there: its second piece, the Pointer Authentication bypass, was fixed by Apple in 17.5. And that flaw's record carries a detail that sits in the list of fixed versions and almost nobody opens: it was also fixed in iOS 16.7.8, on 13 May 2024, inside the 16 branch itself.

It is worth being exact about who that version exists for, because it is what holds the argument up: Apple shipped iOS 16.7.8 only for iPhone 8, 8 Plus, iPhone X, the 5th-generation iPad and the first two iPad Pros — that is, for devices that cannot move to iOS 17. An iPhone 11 parked on 16.7 is not offered 16.7.8: it is offered 17.5, which fixes the same thing. In both cases the fix was one button away and no new handset was required.

And the branch did not stop in 2024. Apple shipped iOS 16.7.16 on 11 May 2026 for those same models: 108 days before the campaign started. A phone reading plain "16.7" was eight updates behind a branch still alive three months before the attack. On 4 November, CISA added that PAC bypass to its catalogue of exploited flaws and gave federal agencies until 18 November to fix it; the entry piece, CVE-2025-43529, was already in the same catalogue with a 5 January 2026 deadline, eight months before the campaign.

There is a detail in the report that works against the attackers themselves and should not be hidden: the host serving this chain filtered for "iOS 16.7 / 16.7.10". 16.7.10 is from August 2024 and already carries the PAC bypass fix. Sekoia reads it the same way as the dead code: operators reusing exploits without touching the filter. Which means part of the shots were aimed at versions where one of the two links was already broken.

This is the mirror image of the post we published a few hours ago about patching and staying exposed. There the vendor said it had fixed something and had not: updating achieved nothing, and none of it was the customer's fault. In today's short chain the opposite holds. The patch existed, it was free, it was on the right branch and it worked. The decision was ours. In the long chain, the one against iOS 18.5, we cannot say the same: until we know when the PAC bypass fix reached the 18.x branch, we have to leave open the possibility that those users had no button to press.

The kit checks you are a phone before firing

Before serving anything, the code profiles the device. Per Sekoia, three fields can cancel delivery if their values do not add up: screen width and height — it discards dimensions impossible for a phone, of the 99999 variety — and navigator.maxTouchPoints set to zero, which is how a desktop gives itself away. On Android it also only fires at Chrome versions 139 to 145, skipping 143 for a reason the report itself admits it does not know. And if it detects the identifier SM-S938B, one specific phone model, it stops.

The operational conclusion: the campaign deliberately skipped the machines that are inside your patching policy and aimed at the ones that are not. The reason is that the phone is where nobody checks the version. A corporate laptop updates because a tool forces it; a phone updates when its user decides they have put it off long enough.

And what they took was not trivial. On the long iOS chain, as SecurityWeek reports from the paper: messages, emails, voicemails, credentials, tokens, contacts, calls, calendar entries, browser cookies and history, photos and iCloud Drive content. On Android: cookies, account information, passwords, browsing history and Wi-Fi passwords. If that phone opens company mail, you have just lost a mailbox session and, with the cookies, possibly the second factor of that session.

Where the kit came from

The report says it without ceremony, and it is the part that changes the reading most. One of the iOS chains is DarkSword, a kit Sekoia describes as suspected to be developed by a commercial surveillance vendor, and the sample served in this campaign "leverages the same RCE (CVE-2025-43529) as the one available in the DarkSword leaked exploit kit". Leaked quite literally: the full code appeared in a public GitHub repository on 22 and 23 March 2026, 157 days before the campaign started, and those who examined it at the time wrote that it was HTML and JavaScript, material anyone can copy and host on their own server within hours.

That knocks down the comfortable conclusion, which was ours until we read the report to the end: that an intelligence service with a budget chose not to spend its zero-days. What happened came cheaper still. It picked up off the floor a weapon that had been lying there for five months. And it finally explains the dead code, the filter aimed at already-patched versions and everything that looks like carelessness: those are the marks of using somebody else's tool.

Two weeks ago we wrote about SafePay's five doors, not one from 2026, ransomware getting in through old flaws. The temptation is to say this plays in another league. It plays there less than it looks: the same recycled-ammunition economics, with the difference that here the weapon started out expensive. What has fallen is the price of the equipment, and it fell to zero in five months.

The two lists almost nobody has

Two deliverables come out of all this, and neither is buying anything. In a managed modern workplace this is an afternoon's work, and the first time round something nobody expected almost always turns up.

Before this gets retold badly

Four caveats.

If you want somewhere to start, start with the list of phones and their versions. It costs no money and it almost always returns the same result: three or four devices are badly behind, and they all belong to people who travel a lot. If you would rather we did it, drop us a line.

The line we are taking away is not "update your phone". It is that a zero-day has two lives. The first lasts weeks and gets spent against people with names. The second begins the day the patch ships, lasts exactly as long as you take to install it, and stretches every time the weapon changes hands and drops in price.

Sources. Consulted on 5 November 2026. The campaign, the three chains and their CVEs, the dates of the Plerdy compromise (27 August to 3 September 2026), the injected code, the compromised sites and the two fake domains, the screen filters, maxTouchPoints, Chrome versions and excluded model, the dead code and the "moderate to high confidence" attribution all come from Sekoia's report "Poisoned Source: APT29 watering holes targets mobile devices with n-day exploits", published on 4 November 2026. The detail of what the iOS payload steals and the placement of the Qualcomm patch in the August 2025 Android bulletin come from SecurityWeek's coverage. Apple patch dates and versions, from its own security content pages: CVE-2024-27834 fixed on 13 May 2024 in Safari 17.5, iOS and iPadOS 17.5, iOS and iPadOS 16.7.8, macOS Sonoma 14.5, tvOS 17.5 and watchOS 10.5 (CVSS 5.5, credited to Manfred Paul with Trend Micro's Zero Day Initiative); CVE-2025-43529 and CVE-2025-14174 on 12 December 2025, both WebKit, in iOS and iPadOS 18.7.3 and 26.2, with Apple's note, quoted abbreviated in the body and in full here: "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"; CVE-2025-43510 and CVE-2025-43520, Kernel, on the iOS and iPadOS 18.7.2 page, entries added 12 December 2025. CVE-2026-20700, patched on 11 February 2026. CVE-2026-3910, in V8, in the Chrome stable channel update of 12 March 2026 (versions 146.0.7680.75 and .76). CVE-2025-27038, in the Adreno driver, in Qualcomm's security bulletin of 2 June 2025, which already mentioned Google TAG indications of limited, targeted exploitation. The addition of CVE-2024-27834 to CISA's KEV catalogue on 4 November 2026, federal due date the 18th. The public DarkSword leak on GitHub on 22 and 23 March 2026, and the description of the material as HTML and JavaScript reusable within hours, come from TechCrunch's coverage of 23 March 2026; the kit's identification and its link to this campaign come from Sekoia's own report. The existence and date of iOS and iPadOS 16.7.16, 11 May 2026, and the list of models that branch is offered to, come from the corresponding Apple page. The day counts are ours, computed over those dates up to 27 August 2026. What we could not verify, and therefore say so in the body: the exact Chrome for Android channel date (we take the desktop one) and the date on which the CVE-2026-20700 fix reached the iOS 18.x branch, if it did. The reading that iOS 16.7.8 broke the short chain is ours, and is flagged as such in the text; the criteria on device inventory, access policies and third-party domains come from our own work and are not backed by any of those sources.