WordPress est une application web libre de gestion de contenu, historiquement conçue pour publier des blogs. Aujourd’hui, elle est utilisée pour des sites vitrines, médias, boutiques en ligne ou sites institutionnels. C’est surtout le CMS le plus utilisé au monde : WordPress équipe actuellement environ 40 % de l’ensemble des sites web. Cette popularité a une conséquence directe : lorsqu’une faille touche WordPress lui-même, le nombre de sites potentiellement concernés est considérable. Et l’été 2026 a été particulièrement mouvementé.
Cinq failles critiques en moins de 3 mois
Depuis mi-juillet, plusieurs vulnérabilités importantes ont été découvertes dans le cœur de WordPress, c’est-à-dire dans WordPress lui-même et non dans des extensions tierces.
Le 17 juillet, wp2shell (CVE-2026-63030 et CVE-2026-60137) permet, sous certaines conditions, d’aller jusqu’à l’exécution de code à distance sans authentification. La correction est publiée notamment dans WordPress 7.0.2 et 6.9.5.
Le 6 août sort XSS2Shell (CVE-2026-64638), une vulnérabilité XSS exploitable sans authentification peut être utilisée contre le navigateur d’un administrateur connecté, puis chaînée jusqu’à une exécution de code. Elle est corrigée notamment dans WordPress 7.0.3, 6.9.6 et 6.8.7.
Le 17 septembre, WordPress publie une nouvelle série de correctifs avec notamment Click2Shell : une URL spécialement construite peut exploiter les droits d’un administrateur connecté et, combinée à certaines conditions, aboutir là encore à de l’exécution de code. Et Comment2Shell (CVE-2026-93485) : un commentaire malveillant peut contenir du code JavaScript qui s’exécutera lorsqu’un administrateur le consultera, ouvrant ensuite la voie à une compromission du site. C’est corrigé notamment dans WordPress 7.1.1, 7.0.5 et 6.9.9.
Enfin, le 22 septembre, la faille CVE-2026-87902 sort concernant la résolution des templates de pages. Elle permet dans certaines configurations une traversée de répertoires et une inclusion de fichier pouvant elle aussi aboutir à une exécution de code. Elle est corrigée notamment dans WordPress 7.1.2, 7.0.6 et 6.9.9.
WordPress doit être mis à jour en continu
La découverte et l’exploitation de failles critiques s’est considérablement accélérée et le constat est simple : on ne doit plus réaliser les mises à jour à la main (même plusieurs fois par semaine). En effet, les failles récentes ne concernent pas uniquement des plugins exotiques : plusieurs touchent directement le cœur de WordPress, certaines sont exploitables sans authentification et plusieurs peuvent conduire à une compromission complète du site. Nous recommandons donc plus que jamais d’activer les mises à jour automatiques de WordPress Core, des plugins et des thèmes. Cela se fait directement dans les paramètres « Mises à jour de WordPress » (/wp-admin/update-core.php) et dans les paramètres des extensions et thèmes où il faut « Activer les mises à jour auto ».
Il faut évidemment conserver une certaine vigilance sur les plugins critiques ou très spécifiques, mais le risque principal n’est plus tellement qu’une mise à jour provoque une régression : c’est qu’un composant vulnérable reste exposé plusieurs heures après la publication d’une faille critique.
Au pire si vous avez une extension pas encore compatible avec la dernière version, activez « les mises à jour de maintenance et de sécurité uniquement ». WordPress maintient à ce jour toutes les versions de 5.0 à 7.1, donc vous aurez ainsi les corrections de sécurité les plus sensibles.
Surveiller les mises à jour
Activer les mises à jour automatiques ne suffit pas. Une mise à jour peut échouer : problème de permissions, erreur PHP, plugin défaillant, blocage réseau, etc. Il est donc important de vérifier régulièrement que les versions attendues sont réellement installées.
C’est notamment là que l’outil WP-CLI est très utile : pas forcément pour déclencher les mises à jour qui sont gérées directement par WordPress, mais pour automatiser la vérification des versions de WordPress, des plugins et des thèmes. Voici comment on peut l’utiliser dans des scripts :
$ php wp-cli.phar core check-update
$ php wp-cli.phar plugin list --status=active --fields=update_version | egrep -v '(^\+|update_version)'
$ php wp-cli.phar theme list --status=active --fields=update_version | egrep -v '(^\+|update_version|^$)'Sur un parc de plusieurs sites, il devient ainsi possible de détecter simplement qu’un WordPress n’a pas reçu une mise à jour. Il existe aussi des interfaces pour gérer de nombreux sites WordPress comme Manage WP développé par GoDaddy.
Réduire la surface d’attaque
Les mises à jour restent la protection principale, mais elles doivent être complétées par quelques mesures simples. Nous recommandons notamment :
- de restreindre par adresse IP l’accès à l’administration WordPress ;
- de bloquer complètement
/xmlrpc.phplorsqu’il n’est pas utilisé ; - d’empêcher l’exécution de PHP dans certains répertoires qui n’ont normalement vocation qu’à contenir des fichiers statiques ;
- de limiter au maximum les plugins et thèmes installés et de supprimer ceux qui ne sont plus utilisés.
Notre documentation détaille plusieurs de ces recommandations.
Utiliser ModSecurity comme WAF
L’utilisation d’un Web Application Firewall (WAF) comme ModSecurity, constitue également une couche de protection intéressante. Un WAF peut détecter et bloquer certaines familles d’attaques classiques, par exemple des injections SQL, XSS ou tentatives d’inclusion de fichiers. Il permet de réagir rapidement lorsqu’une nouvelle vulnérabilité est publiée mais aussi de bloquer des robots qui vont inonder les sites de requêtes pour tenter d’exploiter une faille publiée.
Pour certaines failles, nous avons ainsi pu déployer des règles de mitigation, afin de protéger les sites des requêtes malveillantes… même après les mises à jour, ce qui économise des ressources vu le nombre de scans.
# Exemple avec la faille CVE-2026-87902
<IfModule security2_module>
SecRule ARGS:pagename "@rx (?:^|[\\/])\.\.(?:[\\/]|$)" \
"id:8790201,\
phase:2,\
deny,status:406,\
t:none,t:urlDecodeUni,\
log,msg:'WordPress CVE-2026-87902 path traversal'"
</IfModule>Des mitigations (souvent moins complètes que modsecurity) peuvent aussi être déployées directement sur Apache, Nginx ou HAProxy. Quelques exemples en vrac :
# pour Apache
<If "%{REQUEST_METHOD} == 'POST' && %{REQUEST_URI} =~ m#/wp-comments-post\.php$#">
Require all denied
</If>
# pour Nginx
if ($uri ~ /wp-json/batch/v1) { return 403; }
if ($arg_rest_route ~* "(/|%2f)batch(/|%2f)v1") { return 403; }
# pour HAProxy
option http-buffer-request
acl wordpress_87902_query query -m reg -i (^|&)pagename=[^&]*(/|%2f|%252f)(\.|%2e|%252e){2}(/|%2f|%252f)
acl wordpress_87902_body req.body_param(pagename) -m reg -i (/|%2f|%252f)(\.|%2e|%252e){2}(/|%2f|%252f)
http-request deny if wordpress_87902_query
http-request deny if wordpress_87902_bodyUtiliser un plugin de sécurité
L’utilisation d’un plugin spécialisé devient également une protection raisonnable pour un WordPress exposé sur Internet. On peut notamment citer Wordfence et SecuPress qui proposent différentes fonctions de firewall, de détection de vulnérabilités, de contrôle d’intégrité ou de sécurisation des connexions.
Des sauvegardes fluides et testées
Dernier point, peut-être le plus important : en cas de doute sur une compromission, il faudra restaurer une sauvegarde de WordPress à une date où l’on est sûr qu’il n’y a pas de code malveillant. Il est donc important d’avoir un outil de sauvegarde qui se lance régulièrement, qui peut être lancé à la demande, et permette une restauration simple et rapide. Il faut aussi conserver les sauvegardes sur une durée suffisamment longue : une compromission peut rester invisible pendant plusieurs semaines ou mois, si l’on découvre tardivement qu’un site a été piraté toutes les sauvegardes récentes peuvent déjà contenir le code malveillant.
Il existe de nombreuses solutions de sauvegarde (au niveau système, via un plugin, etc.). Pour les sites critiques, nous préconisons d’avoir des scripts en local qui permettent de rendre fluide la création de sauvegardes automatisées ou à la demande, et que ces sauvegardes soient aussi envoyées vers des serveurs externes et cloisonnés. Dans ce but nous partageons nos petits scripts qui s’appuient sur mysqldump et tar avec compression xz.
Et naturellement, une sauvegarde n’a réellement de valeur que si sa restauration a déjà été testée. Il faut donc tester régulièrement la restauration en suivant une procédure, afin de ne pas improviser le jour où l’incident survient.
Conclusion
Depuis quelques années, l’exploitation de WordPress a donc changé. Il ne suffit plus d’installer le site et d’appliquer quelques mises à jour de temps en temps. Maintenir un WordPress à jour est devenu un process permanent, et il faut désormais considérer comme « standards » les pratiques suivantes :
- mises à jour automatiques de WordPress, des plugins et des thèmes ;
- surveillance effective de ces mises à jour ;
- restreindre l’accès à l’administration ;
- installer un plugin de sécurité ;
- filtrage complémentaire avec un WAF ;
- sauvegardes fréquentes, automatisées et conservées suffisamment longtemps.
