Seven Of The Eight Flaws Were Already On The Exploited List. The Eighth Was Added The Day The Report Landed.

On Wednesday 4 November the French threat intelligence firm Sekoia published a watering hole campaign it attributes, with moderate to high confidence, to APT29. The delivery was a compromised third-party analytics tracker and two lookalike domains that quietly proxied real websites. The payloads took cookies, Keychain passwords and tokens, Wi-Fi keys and message databases from iPhones and Android handsets, with no click and no persistence. The part worth taking to a board is not the tradecraft. It is that every vulnerability in the three working exploit chains had already been patched, and seven of the eight were sitting on CISA's Known Exploited Vulnerabilities catalogue, with their remediation deadlines already expired, before the week of the compromise began.

What happened

Three dates do most of the work here, and they are a long way apart.

The route from a third-party analytics tracker to a phone's Keychain. The websites that carried the script were not themselves breached.

Between 27 August and 3 September 2026, according to Sekoia, an intrusion set compromised Plerdy, a Ukrainian website analytics tracker. Plerdy is the sort of product a marketing team buys and a security team never sees: one script tag in a page template, loaded on every visit. Sekoia says the compromise exposed hundreds of legitimate websites and their visitors, and separately that the tracker is loaded by thousands of websites, the large majority of them Ukrainian. The report gives both figures and does not reconcile them, which is worth noting rather than averaging.

Alongside the tracker, Sekoia names two reverse proxies: america250.holiday, which proxied the website of the United States 250th anniversary initiative, and theowo.club, now offline, which proxied the website of the Raffles London at The OWO hotel. A reverse proxy of this kind serves the genuine site to the visitor and adds the attacker's script on the way through. Neither of those organisations is reported as breached, and that distinction matters: a convincing copy of your website, serving your real content, is not a compromise of your estate, and will not appear in any of your logs.

What arrived next depended on the visitor. Sekoia describes fingerprinting followed by a matched exploit chain, served only where one would work. The Android chain targets Chrome 139 through 145, excludes version 143 for reasons Sekoia says remain unclear, and stops outright if a Samsung Galaxy S25 Ultra is detected. On iOS, the broader of the two chains collected message databases, Keychain passwords and tokens, Wi-Fi pre-shared keys, contacts, call history, Safari history and cookies, location caches, health data and photos. On Android the haul was narrower: Chrome cookies, saved logins and history, plus Wi-Fi configuration files. Sekoia says the payloads exfiltrate without establishing persistence. Nothing stayed behind on the device, which is also why nothing would be found by looking for it later.

Sekoia uncovered the activity in mid-October and published on 4 November. On the same day, CISA added CVE-2024-27834 to its Known Exploited Vulnerabilities catalogue with a federal remediation deadline of 18 November 2026. Apple had fixed that flaw in May 2024.

• May 2024Apple ships the fix for CVE-2024-27834 in iOS 16.7.8 and 17.5, macOS Sonoma 14.5, tvOS 17.5, watchOS 10.5 and Safari 17.5. The flaw does not reach CISA's exploited list for another two and a half years.
• 3 June 2025 to 20 March 2026Seven of the eight vulnerabilities later used in the active chains are added to CISA's Known Exploited Vulnerabilities catalogue. Their federal remediation deadlines run from 24 June 2025 to 3 April 2026.
• 27 August to 3 September 2026The Plerdy analytics tracker is compromised, a window of one week. By this point every one of those seven deadlines has passed, the most recent of them 146 days earlier.
• Mid-October 2026Sekoia uncovers the campaign. Roughly six weeks have elapsed since the tracker compromise ended.
• Wednesday 4 November 2026Sekoia publishes. CISA adds CVE-2024-27834 to the exploited list the same day, with a deadline of 18 November 2026 that binds United States federal civilian agencies.

One caution on the technical detail. Sekoia assigns CVE-2025-14174 to an iOS sandbox escape, while CISA and the national vulnerability record describe that identifier as a Google Chromium flaw. Rather than resolve a discrepancy between a vendor report and the national record, this briefing does not map individual vulnerabilities to individual chains or platforms anywhere. Where the table below names a vendor and product, it is quoting the catalogue entry, not describing the chain.

Why this one is different

The eight vulnerabilities used in the three active chains, as CISA's catalogue records them. Seven were listed, and had passed their remediation deadlines, before the compromise window opened.

Most campaigns of this shape are reported for their novelty. This one is worth reading for the opposite reason. There was no zero-day, no unknown technique and no new product to buy. Sekoia states plainly that a user running an up-to-date operating system is safe from these attacks.

Set that against the catalogue. CISA's Known Exploited Vulnerabilities list is not a severity ranking or a prediction. A vulnerability goes on it when there is evidence it is being exploited in the wild. Seven of the eight flaws used here had been on that list for between five and fifteen months before the compromise window opened. Every one of those seven remediation deadlines had already expired. The eighth, CVE-2024-27834, was added on the day the research was published and carried a patch dating from May 2024.

Those deadlines bind United States federal civilian agencies. They do not bind a company in London, Dublin or Frankfurt, and nothing in this briefing suggests otherwise. The relevance is different and more uncomfortable. The intelligence that would have prevented this was free, public, machine-readable and months old. No subscription, no vendor relationship, no analyst. What was missing was not the signal. It was a device that had acted on it.

That matters because of where the exposure sat. Server patching is instrumented, measured and reported. Laptop patching is usually managed. The phone in a director's pocket, running an operating system two releases behind because the update has been deferred since the summer, often sits outside the service level entirely, while holding a live session to the applications that matter most. This campaign went looking for exactly that device, and served it only where it would work.

Commercial exposure for UK and European organisations

Four faces, in the order a board is likely to meet them.

Identity, not devices. The headline loss in a campaign of this kind is not the handset. On one of the chains, browser cookies were the entire objective. A stolen session cookie is an authenticated session, and an authenticated session does not stop at the second factor, because the second factor has already been satisfied. If a device holding a live session to your finance, email or identity platform was in scope, the exposure runs to every application that session reaches, and it survives a password reset. Keychain passwords and tokens appear in Sekoia's iOS list as well, which widens that further.

Regulatory. For UK organisations the applicable instrument is the UK GDPR, and the clause is worth quoting rather than paraphrasing. Article 32(1) requires that, "taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons", the controller and the processor "shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk". The ICO's guidance does not specify patching, and no regulator has made any finding in connection with this campaign. The pressure such a clause creates is evidential rather than prescriptive: an organisation asked to justify its measures will find it easier to do so where a documented patch standard existed for the devices holding sessions, and harder where mobile sat outside every standard it had written. On the supplier side, the same guidance states that a controller "must choose a data processor that provides sufficient guarantees about its security measures", and that the written contract "must stipulate that the processor takes all measures required under Article 32". An analytics tracker running on your public website is such a processor.

Your own web estate. This campaign ran through someone else's script on somebody else's page. The same architecture exists on virtually every corporate website: analytics, consent management, chat widgets, A/B testing, advertising pixels, each loaded from a third-party domain at page render, each capable of being changed without you being told. The two organisations whose sites were proxied here were not breached and could not have detected it. The thousands of sites loading the compromised tracker were not breached either. They had bought a product. That is the uncomfortable part of the model, and the reason a current inventory of third-party tags belongs to security rather than to marketing.

Governance. The gap is ownership rather than control. Mobile device management usually reports enrolment and compliance, not operating system currency against known exploited vulnerabilities. Executive and personal devices are frequently exempted at the point the policy is written, because enforcing a minimum build on the chief executive's handset is a political act rather than a technical one. The result is that the devices with the broadest access run the loosest standard, and nobody has been asked to sign that off.

What leaders should do now

Six decisions available this week. None of them waits on an attribution or on a device count that has not been published.

None of the following depends on the attribution being confirmed, a victim count being published, or any further technical disclosure. All of it is available this week.

1. Set a minimum build at the access layer. Not a policy asking people to update, which is a request. A conditional access rule that refuses a session to a device below a named operating system and browser build, which is a control. This campaign fingerprinted the visitor and served a chain only where one would work, so the device that is current is the device that was never in scope.
2. Produce the list of third-party scripts on your own sites. Every tag on every public web property, with a named owner and a date last reviewed. Where no such list exists, that absence is itself the finding, and the board should see it as one.
3. Treat session material as the objective it is. Shorten session lifetimes on the highest-value applications, bind tokens to a device where the platform supports it, and rehearse revoking every session at once. Mass revocation is one of those capabilities that everyone assumes exists until the evening it is needed.
4. Decide who owns the phone that holds the session. Write down which devices are permitted to hold a corporate session, what the minimum build is, who is accountable when one falls behind, and what happens on the thirtieth day. If executives are exempt, record that as an accepted risk with a named owner rather than leaving it as an unexamined practice.
5. Run the exploited vulnerabilities list against phones and browsers. The catalogue is public, machine-readable and free. Its deadlines are not your obligation, but it is the clearest available signal of what is actually being used against people. Set your own internal clock against it and apply that clock to the mobile estate, not only to servers.
6. Decide the credential rotation order before you need it. If an executive's handset were credibly in scope, which credentials would you rotate, in what sequence, and who authorises it at two in the morning? Sekoia's list runs from Keychain passwords and tokens to Wi-Fi keys and message databases. The assumption to plan against is that the credentials left, not merely that a device was touched.

Three questions for the board

• Question oneWhat is the minimum operating system build permitted to hold a session to our most sensitive application, and what technically enforces it? If the answer is a policy document rather than a control, that is the answer.
• Question twoWho owns the list of third-party scripts running on our public websites, when was it last reviewed, and would we learn from anyone other than a researcher if one of them changed?
• Question threeIf a director's phone were credibly compromised this evening, which credentials would we rotate, in what order, and who makes that call without waiting for the morning?

Strategic takeaway

The instinct after a nation-state report is to ask what new capability the adversary has acquired. Here the honest answer is none worth naming. The chains were assembled from flaws that vendors had patched and that a government agency had publicly listed as exploited, in some cases more than a year earlier. The operation's only real innovation was in distribution: find a script that thousands of trusted pages already load, and let those pages do the delivery.

Which reframes the spending question. An organisation that responds to this by buying a mobile threat detection product has bought a second signal while the first one was already free and already being ignored. The work that actually closes this exposure is unglamorous and cheap: a minimum build enforced at the access layer, a list of the scripts on your own pages, and a named owner for the devices that hold your sessions. None of it requires knowing who ran this campaign, and all of it is achievable inside a quarter.

Confidence note

Confirmed from the primary record, independent of the vendor report: the eight vulnerabilities used in the active chains appear in CISA's Known Exploited Vulnerabilities catalogue with the dates set out in the table above, taken directly from the machine-readable catalogue, version 2026.11.04, released on 4 November 2026. Seven were added between 3 June 2025 and 20 March 2026, with deadlines falling between 24 June 2025 and 3 April 2026. CVE-2024-27834 was added on 4 November 2026 with a deadline of 18 November 2026, and CISA's entry records Apple's May 2024 advisories as the fix. The intervals stated in this briefing were computed from those dates against the compromise window Sekoia reports.

Reported by Sekoia as its own findings, and at the time of writing uncorroborated by a second researcher: the compromise of the Plerdy tracker and its 27 August to 3 September 2026 window; the identification of america250.holiday and theowo.club as reverse proxies; the composition and targeting of the three exploit chains; the data classes collected on each platform; the absence of persistence; the exclusion of Chrome 143 and the halt on detection of a Samsung Galaxy S25 Ultra; and the statement that none of the chains works against fully updated devices.

Assessed rather than established. Sekoia assesses "with moderate to high confidence" that the campaign was conducted by APT29, "or at least one of its subgroups". The attribution of APT29 to Russia's SVR is widely held but is not established by this report. Sekoia describes the iOS kit as "a suspected Commercial Surveillance Vendor-developed iOS exploit kit", and says its analysis of the chain "supports the idea that the exploits came from a third party", which is an assessment and not a finding.

Not established by any source at the time of writing: the number of devices compromised, which Sekoia does not disclose while saying it is working with CERTs to support victim identification; the identity of any victim organisation; and how the Plerdy tracker itself was compromised. No UK organisation has been named as a victim of this campaign. A London hotel's website was impersonated by a reverse proxy, which is an abuse of that brand and not a breach of that organisation. No regulator has commented on the campaign and no enforcement action has been reported.

Garzon Cyber Solutions delivers cybersecurity advisory, compliance certification and specialist technology recruitment as one integrated capability for organisations in the UK, EU and beyond.