What happened
For a week in 2026, the Plerdy analytics tracker loaded code that profiled visitors' phones and served exploits to some of them.
Why it slipped through
The tag kept its URL, its domain and its vendor, so every allowlist and vendor review still trusted it.
What catches it
A change in the file's contents at the same URL, new behaviour, and new destinations, seen as the browser receives them.
What happened to the Plerdy analytics tracker?
Between 27 August and 3 September 2026, the tracker file that Plerdy serves to the sites using it was changed to load attacker code. That code checked each visitor's device and served exploit chains to some iPhones and Android phones running older versions. The security firm Sekoia published its analysis on 4 November 2026 and attributes the campaign to APT29 with moderate to high confidence. The tracker was cleaned after about a week.
What happened, step by step
- 27 August 2026: the Plerdy tracker file starts loading extra code. Thousands of sites use the tracker, most of them in Ukraine.
- On each visit: the added code profiles the visitor's device first, and only then chooses what to serve.
- For some visitors: an exploit chain for that platform. Sekoia recovered two for iOS and one for Android, all for flaws that were already patched, so only phones that had not been updated were at risk.
- On Android: the payload collected browser cookies, saved logins and browsing history, plus Wi-Fi settings.
- 3 September 2026: the tracker is clean again.
- 4 November 2026: Sekoia publishes its report. It shared the list of affected sites only with national CERTs and law enforcement, so this post names none.
Nothing on the affected sites themselves had to change. The site owners added the tracker once, as the vendor instructs, and the vendor's file did the rest.
Why the usual controls missed it
Every control below answers a question about where a script comes from. None of them asks what the script contains today.
The same pattern hit the DebugBear performance script in October, where a trusted monitoring tag drained crypto wallets. See the DebugBear incident and tag manager security for how third-party tags reach your pages.
It is not only about card data
Most writing about hostile scripts is about skimmers that copy payment details. Here the target was the visitor's phone itself. The route is the same, though: a trusted third-party script changes, and every page that loads it runs the new code. On a checkout page, the same access could have copied what customers type into the card fields.
What PCI DSS 6.4.3 & 11.6.1 say about analytics tags
Both requirements cover every script that runs in the customer's browser on a payment page, analytics tags included. 6.4.3 asks for an inventory with a business justification for each script, and a way to confirm each one is authorised and has not been tampered with. 11.6.1 asks for a mechanism that alerts you to unauthorised changes to script contents and security-impacting HTTP headers as the browser receives them, at least weekly. A vendor file that changes for a week is exactly the change 11.6.1 is there to catch.
See every script on your checkout, vendor tags included, and get alerted when one changes. Free on 1,000 page views a month.
What to do this week
- Check whether any of your pages load the Plerdy tracker, and which pages
- List every third-party tag on your payment pages and remove the ones checkout does not need, analytics included
- Watch the contents of every script as the browser receives it, and alert on changes at the same URL
- Alert when a script starts doing something new, such as reading form fields or adding scripts
- Watch where your pages send data, and alert on new destinations
- Restrict connect-src and form-action in your CSP to the destinations you expect
- If a vendor tag changes without a release note, ask the vendor before you trust it again
How Script Monitoring catches it
Script Monitoring records every script that runs on your pages in real visitor sessions, vendor tags included. Each script is fetched, hashed and archived off the page, so a change in a vendor's file at the same URL raises an alert even though the domain and the vendor never changed. It shows what the new code does and where it sends data, and you can block a script at runtime by URL, host, domain or vendor. On payment pages the same record is your evidence for PCI DSS 6.4.3 & 11.6.1. Read more on AI script analysis and web skimming protection.
Sources and methodology
The dates, the attribution and the technical details are from Sekoia's report "Poisoned Source: APT29 Watering Holes Targets Mobile Devices" (4 November 2026), with coverage by Help Net Security and The Record. Plerdy had not published a statement when this post was written. Requirement descriptions are paraphrased from PCI DSS v4.0.1, published by the PCI Security Standards Council. Written on 10 November 2026 and will be updated if Plerdy or Sekoia publish more.
Ask an AI
Don’t just take our word for it
What happened in the Plerdy analytics script compromise, and how do you detect a trusted third-party script that turns hostile?
Frequently asked questions
Was my site affected if it uses Plerdy?
If your pages loaded the Plerdy tracker between 27 August and 3 September 2026, your visitors received the changed file, though only some devices were targeted. Sekoia has not published the list of sites; ask Plerdy, and check your own records of what your pages loaded in that window.
Were card details stolen?
Nothing published says so. The payload targeted visitors' phones, and on Android it collected browser cookies, saved logins and history. The same access to a tracker on a checkout page could be used to copy card data instead.
Who was behind it?
Sekoia attributes the campaign to APT29, also known as Midnight Blizzard or Cozy Bear, with moderate to high confidence.
Would a Content Security Policy have stopped it?
Not the script itself, because its domain was already allowed. A tight connect-src can make it harder for changed code to send data to new places, which is why it is still worth having.
Does PCI DSS 6.4.3 cover analytics scripts?
Yes. It covers every script loaded and executed in the customer's browser on a payment page, whoever provides it.