WordPress, un webshell dans les polices, des sauvegardes empoisonnées

Sur les dix cas cyber du rapport, celui-ci est le plus proche de ce que nous voyons au quotidien. Pas d'État, pas de budget, pas d'équipe : une seule personne francophone, au printemps 2026, visant des partis politiques européens, des médias, des cercles de réflexion, et les prestataires en mode logiciel-service dont ces organisations dépendent. Sur 42 entités suivies, elle a obtenu un accès interne à au moins 14. Le chapitre s'ouvre sur un constat sans détour : l'IA a refermé l'écart de capacité et transforme des hacktivistes de bas niveau en menaces persistantes avancées.

Avant l'intrusion : un scanner maison, et un trafic qui se fond dans le vôtre #

La première brique n'est pas un exploit, c'est une chaîne d'approvisionnement. Cette personne a écrit son propre scanner en Rust, chargé de parcourir les conteneurs publics pour y détecter des clés d'API exposées. Il ne collectait pas seulement : il validait chaque clé, vérifiait qu'elle fonctionnait encore et ce à quoi elle donnait droit.

Le raffinement est dans l'étape suivante. Une fois la clé validée, l'outil faisait tourner son usage à travers une couche de proxy locale, pour que le trafic de l'attaquante se fonde dans celui du propriétaire légitime. C'est une attaque contre la détection elle-même : vos requêtes habituelles mélangées à celles d'un tiers sur la même clé, et aucun seuil de consommation ne se déclenche proprement. Le rapport le dit autrement : une campagne hacktiviste a tourné un mois entier sur des clés volées. C'est la triple prise décrite dans le deuxième article : butin, calcul gratuit, couverture.

Un cadre d'agents qui se relit lui-même #

L'autre pièce d'outillage mérite l'attention de quiconque écrit du logiciel. Le rapport décrit un cadre d'agents où un agent principal pilotait des sous-agents spécialisés : reconnaissance avant authentification, reconnaissance après authentification, revue de code, et vérification des constats issus de différents modèles d'IA.

Ce dernier rôle est le plus instructif. Cette personne ne faisait pas confiance à un modèle unique : elle faisait recouper les résultats d'un modèle par un autre. Pour un attaquant, une vulnérabilité imaginaire, c'est une journée perdue et du bruit inutile sur la cible. Ce que ça change : l'idée rassurante selon laquelle « l'IA se trompe souvent, donc ces attaques seront brouillonnes » ne tient pas. Vous ne verrez pas les tâtonnements, vous verrez l'exploit qui fonctionne.

L'entrée : une condition de course à la réinstallation de WordPress #

La technique signature visait WordPress : une condition de course lors de la réinstallation, état transitoire jusque-là non documenté publiquement, dans lequel il est possible de créer un compte administrateur sans fournir d'identifiants valides. Une condition de course, c'est une fenêtre : entre deux opérations censées s'enchaîner, un intervalle où le système accepte ce qu'il refuserait avant et après.

Le rapport précise la fabrication : l'exploit a été développé et débogué dans la même session, avec un banc d'essai construit au passage. Entre l'intuition de la faille et l'outil fiable, aucune rupture de charge. La technique a fonctionné contre au moins quatre sites. Ce que ça change : les routes d'installation sont des chemins d'authentification alternatifs, écrits pour un moment où il n'y a précisément pas encore d'authentification. Elles doivent être inatteignables depuis Internet en dehors du quart d'heure où on s'en sert.

L'autre entrée : un point d'interface de recherche laissé ouvert #

Sur une plateforme de gestion de campagne politique, un point d'interface de recherche était exposé. Cette personne a chargé ses agents d'itérer dessus - de le solliciter méthodiquement, requête après requête, jusqu'à en vider le contenu. Résultat : environ 140 000 enregistrements exfiltrés, contenant les opinions politiques des utilisateurs.

C'est le scénario que nous rencontrons le plus souvent en reprenant une application métier : une interface qui répond correctement à une requête légitime, jamais pensée pour en encaisser cent mille automatisées. Trois contrôles sont non négociables dès qu'une interface retourne des données de personnes - autorisation objet par objet, limitation de débit, pagination bornée. Leur absence transforme une base en fichier téléchargeable.

Rester : trois mécanismes de persistance #

C'est la partie à retenir : elle invalide le réflexe le plus répandu en cas d'incident, « on restaure la sauvegarde de la semaine dernière et on repart ».

• Une extension WordPress à chargement obligatoire. Placée dans un répertoire spécial, elle s'exécute à chaque chargement de page, n'apparaît pas dans la liste habituelle et ne peut pas être désactivée depuis le tableau de bord. Celle-ci récoltait les identifiants saisis dans les formulaires et les chiffrait avec une clé publique propre à chaque site avant de les tenir prêts à être collectés. Chiffrés : même en trouvant le fichier, la victime ne sait pas ce qui a fuité.
• Un webshell caché parmi les fichiers de polices. Un webshell est un petit script déposé sur le serveur, qui permet d'y exécuter des commandes à distance - une porte dérobée accessible par le site lui-même. Celui-ci a été fabriqué à la volée, quand la vulnérabilité permettant le dépôt a été identifiée : écrit sur mesure, il n'a aucune signature connue, donc aucun antivirus ne le reconnaît. Et il a été rangé dans le dernier répertoire qu'on pense à inspecter.
• Des sauvegardes empoisonnées. Le rapport est explicite : l'acteur a piégé les sauvegardes de la victime, vraisemblablement pour maintenir sa présence. En restaurant son environnement précédent, la victime se réinfectait. La sauvegarde devient un mécanisme de persistance que la victime déclenche elle-même, au pire moment.

Le média transformé en arme contre ses propres lecteurs #

Chez un média, cette personne a déployé un cadre d'exploitation de navigateur : un script injecté dans les pages, qui accrochait le navigateur de chaque lecteur à l'ouverture. Le dispositif a permis de prendre l'empreinte de milliers de navigateurs visiteurs, et l'acteur y cherchait spécifiquement les sessions et les identifiants de la rédaction. Prendre une empreinte, c'est relever version, extensions et polices : de quoi savoir qui est vulnérable à quoi, et surtout de quoi repérer, parmi des milliers de lecteurs anonymes, ceux qui reviennent avec une session d'administration.

Ce que ça change pour tout site qui a une audience : un script tiers chargé depuis votre page a les mêmes droits que votre code. Deux contrôles gratuits répondent à ça - une politique de sécurité de contenu, qui déclare les seules origines autorisées à exécuter du script, et un contrôle d'intégrité des ressources, qui bloque un script externe dont le fichier a changé.

Ce qu'elle en a fait : une plateforme de fichage #

L'outil signature s'appelait « fafsearch » : un moteur de recherche de mise à nu de personnes. Sa composition, détaillée par le rapport, décrit un produit logiciel complet :

• un moteur de recherche compilé, et non un assemblage de scripts jetables ;
• des pipelines d'ingestion, pour absorber de nouvelles sources en continu ;
• un croisement entre les fuites publiques existantes et les données volées par ses propres soins ;
• une normalisation des numéros d'identité nationale et de téléphone - la brique qui permet de rapprocher deux fichiers écrivant les mêmes identifiants dans des formats différents ;
• une logique de classement des résultats, des tests, un déploiement conteneurisé.

Il y a là tout ce qu'une équipe produit met des mois à construire. Cette personne l'a chargé de dizaines de millions de lignes - dont des identifiants de santé nationaux et des données issues de fuites du système judiciaire - puis publié en services anonymes accessibles par Tor, où les personnes du mouvement politique visé pouvaient être recherchées par leur nom.

C'est l'un des cas les plus nets que nous ayons vus d'ingénierie logicielle assistée par IA appliquée directement à une attaque de masse contre la vie privée - et l'ensemble de la plateforme a été créé par une seule personne.

Le butin, et les personnes derrière #

• 12 à 26 Go de vidages de bases, estimation donnée en fourchette par les analystes eux-mêmes.
• Des fichiers de donateurs et d'adhérents de partis. Donner et adhérer révèlent une opinion politique de façon directe et non équivoque.
• Une boîte aux lettres de 15 000 messages : pas une liste de contacts, mais l'historique des relations et des arbitrages d'une organisation.
• Des dossiers de candidature d'étudiants, incluant des données de mineurs. Ces personnes ne sont ni militantes ni donatrices : elles ont postulé quelque part.
• Des données de prestataire de paiement, une interception d'identifiants en direct sur les sites compromis, et des archives chiffrées par victime mises en scène sur un site de fuite tenu par l'acteur.

L'infrastructure, et son calendrier #

Nous ne publions aucun indicateur technique. Mais les rôles et le calendrier se racontent.

• Un serveur de validation de clés chez un hébergeur nord-américain, actif de février à juin 2026 : la pièce qui vit le plus longtemps, parce que la collecte précède et survit à tout le reste.
• Des sorties d'attaque par VPN commerciaux et centres de données, sur sept pays, de fin mars à fin mai.
• Des points d'exfiltration logés dans des projets cloud détournés, en avril et mai : les données sortent vers l'infrastructure d'une autre victime.
• Un serveur dédié chez un hébergeur français, machine de préparation et de scan contre les organisations politiques européennes, fin juin et début juillet : la phase tardive se rapproche des cibles.
• Des services cachés en Tor pour le coffre à identifiants et le site de fuite - et une passerelle vers des modèles d'IA tiers, également en Tor : un canal d'approvisionnement en calcul indépendant des clés volées.

La lecture RGPD : pas un incident technique, une violation de données sensibles #

Si une seule de ces organisations avait été française, la qualification aurait été immédiate. Le butin relève très largement de l'article 9 du RGPD, qui interdit par principe de traiter les données révélant les opinions politiques et les données concernant la santé. Leur divulgation expose les personnes à la discrimination, à la pression, parfois à la violence.

• Article 9, opinions politiques. Les 140 000 enregistrements, les fichiers de donateurs et les listes d'adhérents révèlent une opinion politique au sens le plus littéral. La plateforme de fichage a ensuite permis de chercher des personnes par leur nom : la fuite devient un outil de ciblage individuel.
• Article 9, santé. Les identifiants de santé nationaux relèvent de la même catégorie, et ils ont ici une fonction précise : servir de pivot de réconciliation entre plusieurs fuites, parce qu'ils sont uniques et stables.
• Données de mineurs. Le RGPD considère que les enfants méritent une protection spécifique (considérant 38) et son article 8 encadre le consentement des mineurs aux services en ligne, seuil fixé à 15 ans en France. Une violation qui les concerne appelle une vigilance renforcée.
• Articles 33 et 34, notification. La violation se notifie à l'autorité de contrôle sous 72 heures si possible ; en cas de risque élevé - un fichage politique nominatif publié en accès libre en est un - elle se communique aussi aux personnes concernées. Rédiger ce message en pleine crise, sans modèle préparé, prend des jours.
• Article 32, sécurité du traitement. Le règlement exige la capacité à rétablir la disponibilité des données et l'accès à celles-ci dans des délais appropriés. Des sauvegardes empoisonnées détruisent cette capacité : une sauvegarde jamais restaurée à blanc est une obligation non tenue.
• Article 35, analyse d'impact. Un traitement à grande échelle de données de l'article 9 impose une analyse d'impact préalable : tout fichier d'adhérents ou de patients en relève.

« Mon site est une vitrine, il n'y a rien à voler » #

Nous entendons cette phrase chaque mois ; ce cas la démonte. Un site vitrine, c'est un serveur, donc un relais pour attaquer les autres ; une audience, qu'un script injecté transforme en surface de contact ; des identifiants de collaborateurs, souvent réutilisés ailleurs ; des données de formulaire et de candidature ; et une réputation - un domaine sur les listes de blocage emporte votre messagerie avec lui.

La liste de contrôle WordPress #

Rien de ce qui suit n'est nouveau, et c'est le problème : aucune de ces mesures n'aurait demandé de budget.

1. Mettre à jour le cœur, les thèmes et les extensions - et supprimer, pas désactiver, ce qui ne sert plus : une extension désactivée reste un fichier exécutable sur le serveur.
2. Inspecter wp-content/mu-plugins/. Souvent vide, jamais regardé. Tout fichier que vous n'y avez pas mis est un incident.
3. Contrôle d'intégrité des fichiers : une empreinte de l'arborescence comparée chaque jour, qui alerte sur le fichier apparu dans fonts/ ou uploads/. Seul contrôle capable d'attraper un webshell sans signature connue.
4. Interdire l'écriture par le serveur web là où ce n'est pas indispensable, et l'exécution de PHP dans les répertoires de téléversement. Un webshell déposé dans un répertoire qui n'exécute pas est inerte.
5. Second facteur sur tous les comptes d'administration, comptes nominatifs, suppression des comptes des prestataires partis. Une extension qui capture les identifiants saisis ne capture pas un second facteur.
6. Aucun installateur ni fichier de configuration laissé accessible : la faille exploitée ici vivait dans un état transitoire de réinstallation.
7. Un pare-feu applicatif et une limitation de débit devant le formulaire et la page de connexion - même logique que le bombardement d'inscriptions et que le CAPTCHA souverain, avec un bannissement des sources répétitives côté serveur.
8. Politique de sécurité de contenu et contrôle d'intégrité des ressources sur les scripts externes.
9. Borner les interfaces de recherche et d'export : autorisation objet par objet, pagination limitée, débit plafonné par compte.
10. Des journaux d'accès conservés et lus. Sans eux, l'analyse post-incident se résume à des suppositions.
11. Une sauvegarde immuable, à rétention longue, restaurée pour de vrai sur une machine neuve au moins deux fois par an.
12. Une procédure écrite pour les 48 premières heures : qui coupe quoi, qui prévient qui, qui rédige la notification. Notre trame de plan de reprise d'activité tient en quelques pages.

Demain : les fonderies d'exploits, ou comment deux étudiants chinois ont fait tourner une chaîne automatisée qui sortait « plus d'une douzaine de vulnérabilités inconnues en un mois » sur des équipements réseau.

Sources #

• Anthropic, Detecting and countering misuse of AI: September 2026 (10 septembre 2026) - chapitre Cyber operations, section GTG-50029 Hacktivists targeted European political and affiliated entities, pages 34 à 37.
• Anthropic, même rapport - section AI supply chain as target, loot, and attack compute : triade butin / calcul / couverture.
• Règlement (UE) 2016/679 (RGPD) : articles 8, 9, 28, 32, 33, 34 et 35, considérant 38.
• Nos articles connexes : sauvegarde 3-2-1 immuable, rétention anti-rançongiciel, plan de reprise d'activité, auto-audit ANSSI.