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.php lorsqu’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_body

Utiliser 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.

Cet article a pour but de décrire le dispositif de déchiffrement automatique de volumes chiffrés avec LUKS. Il ne décrit pas la manière de créer un volume chiffré, ni le déchiffrement manuel (qui restera possible en plus du déchiffrement automatique).

Contexte

Lorsqu’un serveur démarre, ses volumes chiffrés ne sont pas déchiffrés et pas montés. Par défaut, si les partitions ne sont pas en montage automatique il faut faire les actions à la main après le démarrage, et si les partitions sont configurées pour un montage auto alors il faut saisir la passphrase au démarrage.

Dans notre cas (chez Evolix), ce déchiffrement n’est pas fait automatiquement car nous n’avons pas mis en place de moyen de déchiffrement stocké localement de manière sécurisée.

En revanche, en utilisant le binôme « Clevis + Tang » il est possible de faire ce déchiffrement automatiquement grace à un moyen de déchiffrement distant et sécurisé.

Clevis + Tang

Clevis est un outil qui permet d’automatiser le déchiffrement. Parmi les méthodes possibles il y a l’utilisation d’une ressource réseau pour obtenir des éléments de déchiffrement.

Tang est cette ressource réseau (un très simple serveur HTTP) qui stocke et communique des éléments qui seront utilisés par Clevis pour le déchiffrement.

C’est un peu comme si on stockait la passphrase ailleurs sur le réseau pour éviter de la stocker localement. En réalité ça n’est pas la passphrase elle-même mais une partie d’une information qui va autoriser le déchiffrement. Si le serveur qui a son volume chiffré (et Clevis configuré) est séparé (en termes de réseau) du serveur Tang, alors le déchiffrement automatique ne peut pas avoir lieu.

Il est important de préciser que la partie Tang doit être protégée, car si on arrive à extraire à la fois le volume chiffré et les données de Tang, il devient possible de déchiffrer le volume.

Par exemple, si la partie Clevis et la partie Tang sont physiquement proches (dans la même baie ou salle de datacenter, ou dans 2 serveurs virtuels gérés par le même hyperviseur) il faut que les données de Tang soient stockées de manière chiffrées elles-aussi. On retrouve alors le problème de départ : comment déchiffrer le volume qui contient ces données ?

Jusque-là nous avons accepté les contraintes d’un déchiffrement manuel pour Tang, en estimant que ça sera suffisamment rare pour ne pas être problématique. Mais on peut envisager de déchiffrer automatiquement les données de Tang grâce un autre serveur Tang qui ne souffre pas des limites de proximité. On ne fait que reporter le problème, mais ça reste envisageable si on a plusieurs frontières réseau et physiques disponibles.

Il est aussi conseillé de protéger Tang au niveau réseau ; si possible avec des restrictions d’interfaces d’écoute (uniquement sur un LAN…), et à minima avec des restrictions d’IP source pour ne pas que n’importe qui puisse récupérer en HTTP les informations de Tang.

Scenarios opérationnels

Si le serveur Tang est le seul à redémarrer (pour une maintenance…), alors il faut s’y connecter (en console ou SSH), déverrouiller/monter le volume chiffré pour Tang. Et c’est tout. Tang ne doit être disponible qu’au moment du déchiffrement automatique.

Si un serveur avec Clevis redémarre et le serveur Tang est disponible, alors le déchiffrement du volume et le montage de la partition va se faire automatiquement. Il n’y a aucune action manuelle à faire.

Si un serveur avec Clevis redémarre et le serveur Tang n’est pas disponible, alors on peut faire le déchiffrement manuellement, ou bien rendre le serveur avec Tang disponible et déclencher le déverrouillage par Clevis.