Faille TranslatePress : 400 000 sites WordPress à mettre à jour

Une prise de contrôle possible sans authentification

Une faille TranslatePress met en danger plus de 400 000 sites WordPress qui utilisent cette extension de traduction multilingue. Toutes les versions jusqu'à la 3.3.1 incluse sont vulnérables ; la 3.3.2 corrige le problème. Il s'agit d'un défaut de contrôle d'accès : un attaquant non authentifié, c'est-à-dire sans compte ni mot de passe sur le site, peut récupérer le lien de réinitialisation du mot de passe d'un administrateur et prendre ainsi le contrôle complet de l'installation. Une condition limite l'exploitation réelle : le profil de l'administrateur visé doit avoir sa langue réglée sur une langue secondaire publiée par le site, ce qui réduit le nombre d'installations effectivement attaquables. Le risque reste sérieux compte tenu du nombre de sites concernés et de la nature de la prise de contrôle, qui donne à l'attaquant les pleins pouvoirs sur le contenu, les comptes et le code du site.

Un correctif publié en quarante-huit heures

Le calendrier de traitement a été rapide. La faille a été signalée le 11 août 2026, les détails ont été transmis à l'éditeur le 12 août, et la version corrective 3.3.2 est sortie le 13 août 2026. Côté protection réseau, la règle de pare-feu applicatif a été activée dès le 13 août pour les abonnés payants du service de sécurité concerné, tandis que la même règle ne sera disponible pour les utilisateurs de la version gratuite qu'un mois plus tard, le 12 septembre 2026. La consigne pour tout site utilisant TranslatePress est donc de vérifier sans attendre la version installée depuis le menu des extensions et de passer manuellement en 3.3.2 si la mise à jour automatique n'a pas encore été appliquée. Sur un site en production, il est prudent de réaliser une sauvegarde avant la mise à jour, puis de contrôler l'affichage des pages traduites une fois l'opération terminée.

Le rappel d'un risque structurel du côté des extensions

Cette faille illustre un schéma bien connu de l'écosystème WordPress. Le CMS équipe environ 42 pour cent des sites web dans le monde, ce qui en fait une cible de choix, et la grande majorité des intrusions passe par une extension ou un thème plutôt que par le cœur du logiciel. Selon un bilan de sécurité publié fin août 2026, les extensions et les thèmes sont en cause dans environ 91 pour cent des compromissions, et plus de 11 000 vulnérabilités ont été recensées sur l'ensemble de l'écosystème en 2025. Le délai entre la publication d'une faille et ses premières exploitations se compte parfois en heures. Multiplier les extensions installées, en conserver d'inactives ou négliger leurs mises à jour revient donc à élargir mécaniquement la surface d'attaque d'un site, quelle que soit la qualité de son hébergement.

Sécuriser un site WordPress au-delà du correctif

La mise à jour règle le cas immédiat, mais sécuriser un site WordPress dans la durée suppose un socle plus large, valable pour toutes les extensions :

• appliquer les mises à jour du cœur, des thèmes et des extensions sous 24 heures, en activant les mises à jour automatiques pour les correctifs mineurs
• n'installer que des extensions issues du répertoire officiel WordPress.org et supprimer celles qui sont inactives
• protéger la connexion : authentification à deux facteurs, limitation des tentatives, adresse de connexion personnalisée
• utiliser des mots de passe d'au moins seize caractères et bannir l'identifiant admin
• programmer des sauvegardes quotidiennes stockées hors du serveur, avec une restauration testée régulièrement
• placer un pare-feu applicatif devant le site, via l'hébergeur ou un service spécialisé

Ces réflexes valent pour tous les sites, mais l'échéance à retenir dans le cas présent est le 12 septembre 2026 : c'est la date à laquelle la règle de pare-feu gratuite couvrira les installations qui n'auront pas encore migré. D'ici là, la mise à jour vers TranslatePress 3.3.2 reste la seule protection fiable, et rien ne justifie de la reporter. Si un site venait malgré tout à être compromis et que des données personnelles se trouvaient exposées, l'éditeur devrait notifier la CNIL dans les 72 heures, restaurer une sauvegarde antérieure à l'intrusion et réinitialiser l'ensemble des identifiants, y compris ceux des comptes de base de données et des accès à l'hébergement. Conserver une trace datée de ces opérations facilite ensuite les échanges avec l'hébergeur et, le cas échéant, avec l'autorité.