WordPress, a webshell in the fonts, poisoned backups

Of the ten cyber cases in the report, this one is the closest to what we see every day. No state, no budget, no team: one French-speaking individual, in spring 2026, targeting European political parties, media outlets, think tanks, and the software-as-a-service providers these organisations depend on. Out of 42 entities tracked, this person obtained internal access to at least 14. The chapter opens with a blunt observation: “AI has helped to close the capability gap turning low-level ‘hacktivists’ into advanced persistent threats.”

Before the intrusion: a home-made scanner, and traffic that blends into yours #

The first building block is not an exploit, it is a supply chain. This person wrote their own scanner in Rust, designed to crawl public containers for exposed API keys. It did not just collect them: it validated each key, checking that it still worked and what it gave access to.

The refinement is in the next step. Once a key was validated, the tool rotated its use through a local proxy layer, so that the attacker's traffic blended into that of the legitimate owner. This is an attack on detection itself: your usual requests mixed with a third party's on the same key, and no consumption threshold fires cleanly. The report puts it another way: one hacktivist campaign ran for an entire month on stolen keys. It is the triple gain described in the second article: loot, free compute, cover.

An agent framework that checks its own work #

The other piece of tooling deserves the attention of anyone who writes software. The report describes an agent framework in which a lead agent directed specialised sub-agents: reconnaissance before authentication, reconnaissance after authentication, code review, and verification of findings produced by different AI models.

That last role is the most instructive. This person did not trust a single model: they had one model's results cross-checked by another. For an attacker, an imaginary vulnerability means a wasted day and pointless noise on the target. What this changes: the reassuring idea that “AI often gets things wrong, so these attacks will be sloppy” does not hold. You will not see the trial and error, you will see the exploit that works.

The way in: a race condition during WordPress reinstallation #

The signature technique targeted WordPress: a race condition during reinstallation, a transient state not previously documented in public, in which it is possible to create an administrator account without providing valid credentials. A race condition is a window: between two operations that are supposed to follow one another, an interval in which the system accepts what it would refuse before and after.

The report describes how it was built: the exploit was developed and debugged in the same session, with a test bench built along the way. Between the hunch about the flaw and the reliable tool, there was no break in the chain. The technique worked against at least four sites. What this changes: installation routes are alternative authentication paths, written for a moment when there is, precisely, no authentication yet. They must be unreachable from the internet outside the quarter of an hour in which they are used.

The other way in: a search endpoint left open #

On a political campaign management platform, a search endpoint was exposed. This person set their agents to iterate over it, querying it methodically, request after request, until they had emptied it. Result: around 140,000 records exfiltrated, containing users' political opinions.

This is the scenario we come across most often when we take over a business application: an interface that responds correctly to a legitimate request, never designed to absorb a hundred thousand automated ones. Three controls are non-negotiable as soon as an interface returns data about people: object-level authorisation, rate limiting, bounded pagination. Without them, a database becomes a downloadable file.

Staying in: three persistence mechanisms #

This is the part to remember: it invalidates the most common reflex after an incident, “we restore last week's backup and carry on”.

• A must-use WordPress plugin. Placed in a special directory, it runs on every page load, does not appear in the usual list and cannot be deactivated from the dashboard. This one harvested the credentials entered in forms and encrypted them with a public key specific to each site before holding them ready for collection. Encrypted: even if the victim finds the file, they cannot tell what has leaked.
• A webshell hidden among the font files. A webshell is a small script dropped on the server that allows commands to be run on it remotely: a backdoor reachable through the website itself. This one was made on the fly, when the vulnerability allowing the upload was identified: custom-written, it has no known signature, so no antivirus recognises it. And it was tucked away in the last directory anyone thinks of inspecting.
• Poisoned backups. The report is explicit: the actor booby-trapped the victim's backups, presumably to maintain its presence. By restoring its previous environment, the victim reinfected itself. The backup becomes a persistence mechanism that the victim triggers itself, at the worst possible moment.

The media outlet turned into a weapon against its own readers #

At a media outlet, this person deployed a browser exploitation framework: a script injected into the pages, which hooked each reader's browser when the page opened. The setup made it possible to fingerprint thousands of visitors' browsers, and the actor was specifically looking for the newsroom's sessions and credentials. Fingerprinting means recording version, extensions and fonts: enough to know who is vulnerable to what and, above all, enough to pick out, among thousands of anonymous readers, those who come back with an administration session.

What this changes for any site with an audience: a third-party script loaded from your page has the same rights as your own code. Two free controls deal with this: a content security policy, which declares the only origins allowed to run scripts, and subresource integrity, which blocks an external script whose file has changed.

What they did with it: a profiling platform #

The signature tool was called “fafsearch”: a search engine for exposing people. Its make-up, detailed in the report, describes a complete software product:

• a compiled search engine, not a collection of throwaway scripts;
• ingestion pipelines, to absorb new sources continuously;
• cross-referencing between existing public leaks and the data the person had stolen themselves;
• normalisation of national identity and phone numbers: the component that makes it possible to match two files that write the same identifiers in different formats;
• ranking logic for results, tests, containerised deployment.

This is everything a product team takes months to build. This person loaded it with tens of millions of rows, including national health identifiers and data from leaks from the justice system, then published it as anonymous services reachable through Tor, where people from the targeted political movement could be looked up by name.

This is one of the clearest cases we have seen of AI-assisted software engineering applied directly to a mass attack on privacy, and the entire platform was created by just one person.

The loot, and the people behind it #

• 12 to 26 GB of database dumps, an estimate given as a range by the analysts themselves.
• Party donor and member files. Donating and joining reveal a political opinion directly and unambiguously.
• A mailbox of 15,000 messages: not a contact list, but the history of an organisation's relationships and decisions.
• Student application files, including data on minors. These people are neither activists nor donors: they applied somewhere.
• Payment provider data, live credential interception on the compromised sites, and encrypted archives per victim staged on a leak site run by the actor.

The infrastructure, and its timeline #

We do not publish any technical indicators. But the roles and the timeline can be described.

• A key validation server with a North American hosting provider, active from February to June 2026: the component that lived longest, because collection comes before everything else and outlasts it.
• Attack exit points through commercial VPNs and data centres, in seven countries, from late March to late May.
• Exfiltration endpoints housed in hijacked cloud projects, in April and May: the data leaves for another victim's infrastructure.
• A dedicated server with a French hosting provider, used as a staging and scanning machine against European political organisations, in late June and early July: the late phase moves closer to the targets.
• Tor hidden services for the credential vault and the leak site, and a gateway to third-party AI models, also on Tor: a compute supply channel independent of the stolen keys.

The GDPR reading: not a technical incident, a breach of sensitive data #

Had even one of these organisations been French, the legal classification would have been immediate. The loot falls very largely under Article 9 of the GDPR, which prohibits in principle the processing of data revealing political opinions and data concerning health. Disclosing it exposes people to discrimination, to pressure, sometimes to violence.

• Article 9, political opinions. The 140,000 records, the donor files and the membership lists reveal a political opinion in the most literal sense. The profiling platform then made it possible to look people up by name: the leak becomes a tool for targeting individuals.
• Article 9, health. National health identifiers fall into the same category, and here they have a specific function: serving as a reconciliation pivot between several leaks, because they are unique and stable.
• Data on minors. The GDPR considers that children merit specific protection (Recital 38) and its Article 8 governs minors' consent to online services, with the threshold set at 15 in France. A breach involving them calls for heightened vigilance.
• Articles 33 and 34, notification. The breach must be notified to the supervisory authority within 72 hours where feasible; where there is a high risk (a named political profiling database published openly is one), it must also be communicated to the data subjects. Drafting that message in the middle of a crisis, with no template ready, takes days.
• Article 32, security of processing. The regulation requires the ability to restore the availability of and access to personal data in a timely manner. Poisoned backups destroy that ability: a backup never test-restored from scratch is an obligation not met.
• Article 35, impact assessment. Large-scale processing of Article 9 data requires a prior data protection impact assessment: any membership or patient file falls into this category.

“My site is just a brochure, there is nothing to steal” #

We hear this sentence every month; this case takes it apart. A brochure website is a server, and therefore a relay for attacking others; an audience, which an injected script turns into a contact surface; staff credentials, often reused elsewhere; form and application data; and a reputation: a domain on blocklists takes your e-mail down with it.

The WordPress checklist #

Nothing that follows is new, and that is the problem: none of these measures would have required a budget.

1. Update the core, themes and plugins, and delete, rather than deactivate, whatever is no longer used: a deactivated plugin is still an executable file on the server.
2. Inspect wp-content/mu-plugins/. Often empty, never looked at. Any file you did not put there is an incident.
3. File integrity monitoring: a fingerprint of the directory tree compared every day, which alerts on a file that appears in fonts/ or uploads/. The only control capable of catching a webshell with no known signature.
4. Prevent the web server from writing wherever this is not essential, and block PHP execution in upload directories. A webshell dropped in a directory that does not execute is inert.
5. Second factor on all administration accounts, named accounts, removal of accounts belonging to contractors who have left. A plugin that captures entered credentials does not capture a second factor.
6. No installer or configuration file left accessible: the flaw exploited here lived in a transient reinstallation state.
7. A web application firewall and rate limiting in front of the form and the login page: the same logic as subscription bombing and the sovereign CAPTCHA, with banning of repeat sources on the server side.
8. Content security policy and subresource integrity on external scripts.
9. Put limits on search and export interfaces: object-level authorisation, limited pagination, rate capped per account.
10. Access logs that are kept and read. Without them, post-incident analysis comes down to guesswork.
11. An immutable backup, with long retention, actually restored onto a new machine at least twice a year.
12. A written procedure for the first 48 hours: who cuts off what, who informs whom, who drafts the notification. Our disaster recovery plan template fits on a few pages.

Tomorrow: exploit foundries, or how two Chinese students ran an automated pipeline that, in the report's words, yielded “more than a dozen possible zero day findings in a single month” on network appliances.

Sources #

• Anthropic, Detecting and countering misuse of AI: September 2026 (10 September 2026): Cyber operations chapter, GTG-50029 section Hacktivists targeted European political and affiliated entities, pages 34 to 37.
• Anthropic, same report: AI supply chain as target, loot, and attack compute section: the loot, compute and cover triad.
• Regulation (EU) 2016/679 (GDPR): Articles 8, 9, 28, 32, 33, 34 and 35, Recital 38.
• Related articles: immutable 3-2-1 backup, anti-ransomware retention, disaster recovery plan, ANSSI self-audit.