TranslatePress : faille critique sur 400 000 sites, que faire

Une extension installée sur plus de quatre cent mille sites vient de faire l'objet d'une correction de sécurité qui mérite une réaction immédiate. TranslatePress, l'un des outils de traduction les plus répandus de l'écosystème WordPress, comportait une faille permettant à un visiteur non identifié d'obtenir le lien de réinitialisation du mot de passe d'un administrateur, de changer ce mot de passe et de se connecter à sa place. Le résultat est une prise de contrôle complète du site, sans compte préalable et sans interaction de la victime. Une condition précise limite heureusement la portée de l'attaque, le correctif est disponible depuis le 13 août 2026, et une partie des sites protégés par un pare-feu ne le sera qu'à la mi-septembre. Nous détaillons ici le mécanisme, la condition qui détermine si un site est réellement exposé, la marche à suivre dans l'ordre, et ce que cet épisode dit du risque que représente une extension.

Ce que dit l'avis de sécurité

Le communiqué est court et chacune de ses phrases porte une information opérationnelle, y compris celles qui semblent anodines.

La faille en une phrase

Un attaquant non authentifié peut obtenir le lien de réinitialisation du mot de passe d'un administrateur, réinitialiser ce mot de passe et se connecter en tant que cet administrateur. Il n'a besoin d'aucun compte sur le site, d'aucun identifiant, et la victime n'a rien à faire pour que l'attaque réussisse. Cette combinaison, absence d'authentification et gain d'un accès administrateur, place la vulnérabilité dans la catégorie la plus grave, celle qui aboutit à la perte complète du site sans étape intermédiaire à franchir.

La condition qui limite la portée

Le point le plus important de l'avis est souvent lu trop vite : la clé de réinitialisation n'est divulguée que si la langue du profil de l'administrateur visé est réglée sur une langue secondaire publiée. Autrement dit, un site multilingue dont les administrateurs sont restés dans la langue principale n'est pas exposé de la même manière. Cette condition ne doit pas rassurer trop vite, puisqu'un administrateur qui bascule son profil dans une autre langue devient vulnérable sans le savoir, mais elle explique pourquoi tous les sites concernés ne sont pas exploitables.

Le calendrier

Le signalement a été reçu le 11 août 2026 par le programme de recherche de vulnérabilités qui l'a traité. Les détails complets ont été transmis à l'éditeur le 12 août, celui-ci a accusé réception le 13 et publié une version entièrement corrigée le jour même. Ce délai de deux jours entre la transmission et le correctif est remarquable et mérite d'être signalé, tant l'inverse est fréquent. La réactivité de l'éditeur fait ici partie de l'information utile pour juger de la fiabilité d'une extension.

Versions concernées et correctif

La règle de protection publiée cible la version 3.3.1 de l'extension, et la version corrigée est la 3.3.2. Toute installation restée en 3.3.1 ou antérieure doit être considérée comme exposée jusqu'à preuve du contraire. La mise à jour est le seul remède réel : aucun réglage, aucune désactivation partielle et aucune protection périphérique ne remplace le correctif du code. Vérifier le numéro de version installé est donc le tout premier geste, avant même de se demander si le site remplit la condition évoquée plus haut.

Le décalage entre protection payante et gratuite

Les sites disposant de la version payante du pare-feu ont reçu une règle bloquant les tentatives connues dès le 13 août 2026. Les sites utilisant la version gratuite du même outil recevront cette règle trente jours plus tard, le 12 septembre 2026. Ce décalage est le modèle économique assumé de l'éditeur du pare-feu, et il crée une fenêtre d'un mois pendant laquelle une part importante des installations n'est couverte ni par le correctif, si elles ne sont pas à jour, ni par la règle de protection. Cette fenêtre est exactement celle que les campagnes automatisées exploitent.

Ce qui n'est pas encore public

Au moment où nous écrivons, les détails techniques complets et l'identifiant public de la vulnérabilité ne sont pas encore diffusés, ce qui est la pratique normale pour laisser aux sites le temps de se mettre à jour. Cette discrétion est temporaire : la description complète finira par circuler, et le délai dont disposent les retardataires se compte en jours plutôt qu'en semaines. Un épisode comparable est décrit dans notre article sur la faille WordPress critique de juillet 2026.

Pourquoi ce type de faille est le plus redoutable

Toutes les vulnérabilités ne se valent pas, et celles qui font le plus de bruit ne sont pas celles qui font le plus de dégâts.

Prise de contrôle et exécution de code

Obtenir un accès administrateur ne donne pas directement l'exécution de code sur le serveur, mais l'administration de WordPress permet d'installer une extension ou de modifier un fichier de thème, ce qui revient au même en deux clics. La distinction académique entre les deux catégories n'a donc aucune portée pratique ici. Un attaquant qui entre en administrateur dispose du site, de sa base de données, de ses fichiers, et souvent d'un point d'appui vers les autres sites hébergés sur le même compte.

Le mot qui change tout

Le qualificatif non authentifié est celui qu'il faut chercher en priorité dans un avis de sécurité. Une faille exploitable par un contributeur suppose que l'attaquant dispose déjà d'un compte, ce qui restreint énormément la population concernée. Une faille exploitable sans aucun compte est accessible à n'importe quel automate qui parcourt le web. Entre les deux, le facteur de risque n'est pas double ou triple, il se compte en ordres de grandeur, et il justifie une réaction dans la journée plutôt que dans le mois.

Le mécanisme du lien de réinitialisation

La procédure de récupération de mot de passe repose sur une clé à usage unique, envoyée par courriel et censée n'être connue que du titulaire du compte. Toute fuite de cette clé vers une page publique, un contenu traduit ou une réponse de serveur transforme un mécanisme de confort en porte d'entrée. C'est un schéma récurrent : les failles de ce type reviennent régulièrement dans des extensions différentes, parce que la clé transite par de nombreuses couches et qu'il suffit qu'une seule l'affiche.

Ce que les chiffres disent des failles réellement exploitées

Le décalage entre ce que l'on découvre et ce que l'on attaque est spectaculaire. Les défauts de contrôle d'accès représentent environ quatorze pour cent des vulnérabilités publiées mais près de cinquante-sept pour cent des exploitations constatées. À l'inverse, les injections de script, qui constituent près de la moitié des découvertes, ne pèsent qu'un pour cent des attaques réelles. Une faille de prise de contrôle non authentifiée appartient à la première famille, celle qui se retrouve effectivement dans les campagnes automatisées.

Le volume de failles publiées

Le dernier bilan annuel du secteur recense plus de onze mille vulnérabilités publiées sur une année, en hausse de plus de quarante pour cent, dont quatre-vingt-onze pour cent concernent des extensions et neuf pour cent des thèmes. Le noyau de WordPress lui-même n'en concentre qu'une poignée, toutes de faible gravité. Ce déséquilibre est la donnée structurante de la sécurité de cet écosystème : le risque ne vient presque jamais du logiciel de base, il vient de ce qu'on lui ajoute.

Le délai sans correctif

Près de la moitié des vulnérabilités publiées ne disposaient d'aucun correctif au moment de leur divulgation publique. Cette proportion rend la mise à jour insuffisante à elle seule et justifie de conserver une couche de protection au niveau du serveur ou du pare-feu applicatif. Elle relativise aussi l'idée qu'un site à jour est un site sûr : il est simplement à jour, ce qui reste la meilleure position disponible mais ne couvre pas la période pendant laquelle personne ne sait encore.

Que faire maintenant, dans l'ordre

La succession des gestes compte autant que les gestes eux-mêmes, parce qu'une mise à jour effacera certaines traces utiles au diagnostic.

Vérifier la présence et la version

La première question est de savoir si l'extension est installée, ce qui n'a rien d'évident sur un site repris ou géré à plusieurs. La liste des extensions de l'administration donne la réponse en dix secondes, avec le numéro de version en face. Une extension désactivée mais toujours présente reste un sujet, car ses fichiers demeurent accessibles et certaines failles s'exploitent sans que l'extension soit active. Le relevé doit couvrir tous les sites du parc, pas seulement celui auquel on pense. Sur un parc de plusieurs dizaines de sites, une commande en ligne de commande produit cette liste en une minute là où le passage par les interfaces demande une demi journée.

Mettre à jour immédiatement

Si la version installée est antérieure à la 3.3.2, la mise à jour prime sur tout le reste, y compris sur l'envie de comprendre d'abord. Sur un site à enjeu, la manoeuvre se fait après une sauvegarde et, si possible, sur un environnement de test, mais l'arbitrage penche clairement vers la rapidité lorsqu'une prise de contrôle non authentifiée est en jeu. Une extension de traduction touche l'affichage public, ce qui rend la vérification visuelle après mise à jour rapide et concluante. Il suffit d'ouvrir une page dans chaque langue publiée et de contrôler que le sélecteur, les traductions et les adresses se comportent comme avant.

Contrôler la langue des profils administrateurs

Une fois la mise à jour faite, il reste utile de vérifier quels comptes administrateurs avaient leur profil réglé sur une langue secondaire, puisque ce sont eux qui étaient réellement exposés. Cette information oriente la suite du contrôle : un site multilingue dont plusieurs administrateurs travaillaient dans une autre langue mérite une inspection plus poussée qu'un site dont tous les comptes étaient restés en langue principale. Cette information se relève dans la liste des comptes, colonne par colonne, et elle mérite d'être notée avec sa date.

Chercher les traces

Les indices d'une exploitation réussie sont toujours les mêmes : un compte administrateur inconnu, une adresse de courriel modifiée sur un compte existant, une date de dernière connexion incohérente, une extension apparue sans raison, un fichier récemment modifié dans le thème. Les journaux du serveur permettent de repérer les requêtes anormales vers les points d'entrée de l'extension. Cette recherche se fait avant toute réinstallation, faute de quoi les traces disparaissent avec le problème. Conserver une copie des journaux du mois écoulé, avant toute intervention, coûte quelques mégaoctets et sauve régulièrement un diagnostic.

Changer les mots de passe et couper les sessions

Si le moindre doute subsiste, tous les mots de passe administrateurs doivent être changés et les sessions ouvertes invalidées, faute de quoi un attaquant déjà entré conserve son accès malgré la correction de la faille. C'est l'erreur classique de la remédiation précipitée : on corrige la porte et on laisse la personne à l'intérieur. Les clés d'authentification stockées dans le fichier de configuration se régénèrent également, ce qui déconnecte tout le monde d'un coup.

Si le site a été compromis

Un site dont la compromission est avérée ne se nettoie pas en supprimant ce que l'on trouve. Il se restaure à partir d'une sauvegarde antérieure à l'intrusion, puis se met à jour avant d'être remis en ligne, ou se fait traiter par un service spécialisé lorsque aucune sauvegarde saine n'existe. Les outils de surveillance disponibles sont présentés dans notre article sur la manière de protéger un site WordPress avec Wordfence.

Réduire l'exposition pour la prochaine fois

Il y aura une prochaine fois, et la question utile est de savoir dans quel état le site sera au moment où elle arrivera.

Réduire le nombre d'extensions

Chaque extension installée est une surface d'attaque supplémentaire dont on dépend sans contrôle sur son code. Le seul levier structurel consiste à en avoir moins, en retirant celles qui rendent un service marginal et celles qui ne servent plus. Un inventaire annuel, avec pour chacune la question de savoir ce qui casse si on la supprime, réduit régulièrement la liste d'un tiers. Les critères de sélection sont développés dans notre article sur la façon de bien choisir une extension pour WordPress.

Activer les mises à jour automatiques

Sur la plupart des sites, l'activation des mises à jour automatiques des extensions est le meilleur compromis disponible : le risque d'une régression est réel mais très inférieur au risque de rester exposé plusieurs semaines. Sur un site à fort enjeu, la solution consiste à automatiser les correctifs de sécurité et à traiter manuellement les évolutions majeures. Une sauvegarde quotidienne vérifiée rend cette automatisation nettement plus confortable à assumer.

Surveiller les annonces

S'abonner aux avis de sécurité des acteurs qui publient ces informations coûte une adresse de courriel et fait gagner des semaines. La difficulté n'est pas de recevoir ces messages mais de les traiter : un avis lu et non relié à l'inventaire des extensions du parc ne sert à rien. La bonne pratique consiste à tenir une liste des extensions utilisées sur l'ensemble des sites gérés, afin de savoir en trente secondes si une annonce concerne quelqu'un.

Limiter les comptes administrateurs

Cette faille cible spécifiquement les administrateurs. Un site comptant huit comptes de ce niveau offre huit cibles, souvent pour trois personnes qui en ont réellement besoin. Ramener les autres à des rôles moins puissants réduit mécaniquement la surface, améliore la traçabilité et ne coûte qu'une conversation. C'est l'une des mesures les plus rentables de toute la sécurité WordPress, et l'une des moins appliquées.

Vérifier ses sauvegardes

Une sauvegarde dont la restauration n'a jamais été testée est une hypothèse, pas une sécurité. Le contrôle consiste à restaurer réellement une copie sur un environnement séparé, une fois par trimestre, et à noter la date. La valeur de cette vérification apparaît exactement le jour où l'on découvre une compromission datant de trois semaines et où la question devient de savoir jusqu'à quand on peut remonter sans perdre de contenu. C'est aussi le moment où l'on découvre que la rétention configurée était de sept jours.

Lire l'information de première main

Les reprises d'avis de sécurité perdent en route les conditions d'exploitation, qui sont pourtant ce qui détermine si un site est concerné. Dans le cas présent, la condition sur la langue du profil administrateur change complètement l'évaluation du risque et elle disparaît de la plupart des résumés. Le réflexe utile consiste à remonter à la source, ici la base de vulnérabilités de Wordfence pour TranslatePress, qui liste les avis publiés pour cette extension avec leur périmètre exact.