Le 28 août 2026, j’ai reçu comme tous les clients de l’éditeur le mail qui annonce une faille de sécurité WP Rocket, sauf que je fais tourner l’extension sur des serveurs WordPress que j’infogère pour mes clients, donc sur des sites qui ne m’appartiennent pas, et j’ai voulu vérifier moi-même plutôt que de cliquer sur « mettre à jour » et passer à autre chose.
Bien m’en a pris, parce que la mise à jour n’a pas suffi : après être passé en 3.23.3.3, mes clés étaient toujours accessibles en ligne. Voici ce que j’ai trouvé, comment je l’ai vérifié, et ce que ça change pour vous si vous administrez des WordPress à distance.
Ce que dit le mail de WP Rocket du 28 août 2026
Le message annonce que la faille pouvait exposer trois choses : l’adresse e-mail du compte, la clé de licence WP Rocket, et le cas échéant les clés API Cloudflare et Sucuri si vous utilisez ces intégrations.
L’éditeur précise qu’il a été prévenu dans la nuit du 26 au 27 août, qu’un correctif est sorti dès le 27, et qu’aucune exposition de données n’a été signalée à ce jour. Il recommande de passer en 3.23.3.3 sans attendre, et de régénérer les clés API Cloudflare et Sucuri par précaution.
Le mail est honnête et il est arrivé vite, ce qui n’est pas si courant. Il est simplement incomplet sur un point, et c’est celui qui m’a occupé la journée.
La faille de sécurité WP Rocket : des réglages écrits en clair dans un répertoire public
La fonctionnalité fautive est arrivée en version 3.23.1, sous un intitulé parfaitement innocent : sauvegarder automatiquement les réglages de WP Rocket à chaque mise à jour de l’extension. L’idée se défend, personne n’a envie de reperdre sa configuration lors d’une montée de version.
Sauf qu’à chaque montée de version, l’extension écrivait l’intégralité de ses options, en JSON parfaitement lisible, dans un fichier de ce genre :
wp-content/wp-rocket-config/wp_rocket_settings_backup_3.23.1_2026-08-05-16-42-10.json
Pourquoi ce fichier était accessible depuis le web
Trois problèmes qui s’additionnent, et c’est leur addition qui fait la faille.
Le répertoire wp-rocket-config est situé dans wp-content, donc dans l’arborescence servie par votre serveur web, et il ne contient qu’un index.html vide, posé là pour empêcher le listing du dossier. Aucune règle Apache ni nginx n’interdit l’accès direct aux fichiers qu’il contient : si vous connaissez le nom, vous obtenez le fichier.
Le nom, justement, n’a rien d’aléatoire. Il est construit à partir de la version précédente de l’extension, qui est publique, et d’un horodatage. Pas de hash, pas de composant secret.
Et le contenu est le tableau brut des réglages de l’extension, celui qui embarque consumer_email, consumer_key (votre clé de licence), cloudflare_api_key, cloudflare_email et sucuri_waf_api_key. Vos secrets, en texte, servis par votre propre serveur.
Quelles versions de WP Rocket sont concernées
Les versions touchées vont de la 3.23.1 à la 3.23.3.2. Avant la 3.23.1, le code n’existait pas, donc les sites restés sur une version antérieure n’ont jamais rien écrit.
Détail qui aggrave l’affaire : l’extension conservait les 4 dernières sauvegardes. Les fichiers ne se remplaçaient donc pas les uns les autres, ils s’accumulaient sur place, mise à jour après mise à jour, sur des sites de production.
Le correctif 3.23.3.3 supprime la sauvegarde au lieu de la protéger
J’ai lu le correctif en espérant y trouver un nom de fichier haché, une règle de blocage sur le répertoire, ou un déplacement hors de l’arborescence web. Il n’y a rien de tout ça.
La sauvegarde automatique est purement et simplement retirée, et le code qui l’écrivait est remplacé par du code qui efface les fichiers déjà présents. C’est la bonne décision : une sauvegarde de réglages que personne n’a demandée ne vaut pas ce risque, et l’export manuel des réglages existait déjà dans l’interface pour ceux qui en ont l’usage.
Je note au passage que le changelog public de WP Rocket ne mentionne pour la 3.23.3.3 qu’un correctif d’erreur fatale sur le vidage du cache, sans un mot sur les sauvegardes de réglages. L’information de sécurité est passée par mail, uniquement, ce qui veut dire qu’un site géré par un prestataire dont l’adresse ne reçoit plus rien est passé complètement à côté.
Mettre à jour WP Rocket depuis MainWP ne supprime pas les fichiers
C’est ici que le mail de l’éditeur est incomplet.
J’ai mis à jour mes sites depuis MainWP, j’ai vérifié derrière, et les fichiers JSON étaient toujours là, bien tranquilles, avec les clés dedans.
L’effacement est accroché à un événement interne que l’extension n’émet que depuis l’administration de WordPress, via admin_init, quand elle constate que la version présente sur le disque ne correspond plus à celle enregistrée en base de données.
Or pendant la requête de mise à jour, l’ancienne version de l’extension est encore chargée en mémoire, donc l’écart de version n’existe pas encore et rien ne se déclenche. Il faudrait une requête suivante pour que le ménage parte, et cette requête suivante n’arrive jamais tant que personne n’ouvre le tableau de bord, puisque le client MainWP traite ses ordres sur une URL du site public et non dans wp-admin.
J’ai confirmé le comportement dans les deux sens : les fichiers sont restés en place après la mise à jour, et ils ont disparu à la seconde où j’ai ouvert une page d’administration du site avec un compte administrateur.
Autrement dit, si vous pilotez un parc de sites WordPress à distance, avec MainWP ou avec n’importe quel outil équivalent, vous avez peut-être coché « mis à jour » sur votre tableau de bord hier, et vos clés sont toujours en ligne aujourd’hui.
Comment vérifier si vos clés WP Rocket ont fuité
Retrouver les fichiers restants
La première question est simple : est-ce que les fichiers sont encore là ? Un find lancé en root à la racine des sites du serveur suffit à répondre, et il couvre d’un coup tous les WordPress hébergés dessus :
find /var/www/users -path '*/wp-content/wp-rocket-config/wp_rocket_settings_backup_*.json' -ls
Chez moi, il remonte quatre fichiers, tous sur libremaster.com, un par montée de version depuis le 5 août :
4231 Aug 5 18:42 wp_rocket_settings_backup_3.23.1_2026-08-05-16-42-10.json 4238 Aug 14 11:27 wp_rocket_settings_backup_3.23.1.1_2026-08-14-09-27-33.json 4102 Aug 19 23:08 wp_rocket_settings_backup_3.23.2.1_2026-08-19-21-08-54.json 4102 Aug 24 19:33 wp_rocket_settings_backup_3.23.2.2_2026-08-24-17-33-02.json
Quatre fichiers de 4 ko, en clair, servis par nginx, pendant trois semaines. Adaptez le chemin de départ à votre hébergement, /var/www ou /home selon les cas, et si vous n’avez qu’un site, lancez le find depuis sa racine.
Pour les faire disparaître, ouvrir une page d’administration de chaque site suffit, et c’est le plus propre puisque c’est exactement ce que l’extension est censée faire toute seule. C’est d’ailleurs le même find qui m’a servi de contrôle : relancé après ma visite dans wp-admin, il ne renvoie plus rien du tout.
Lire les journaux d’accès
Mais la suppression ne règle que l’avenir. La vraie question, celle que le mail de l’éditeur ne pose pas, c’est : est-ce que quelqu’un est allé chercher ces fichiers avant que je les efface ? Et seuls les journaux d’accès du serveur peuvent y répondre.
zgrep -Ehi 'wp_rocket_settings_backup_[^ "]*\.json' /var/www/users/*/log/nginx/*access*log* zgrep -Ehi 'wp-rocket-config' /var/www/users/*/log/nginx/*access*log*
La première commande cherche les fichiers eux-mêmes, la seconde élargit à tout ce qui aurait pu ressembler à un scan du répertoire, et zgrep traite au passage les journaux compressés par la rotation, ce qui évite de passer à côté de la moitié de la fenêtre. Là encore, le chemin est celui de mon infrastructure, le vôtre sera /var/log/nginx sur une installation standard.
Si des lignes remontent, il reste à ne garder que ce qui a réellement été servi, en filtrant sur le code HTTP, neuvième champ du format combined :
zgrep -Ehi 'wp_rocket_settings_backup_[^ "]*\.json' /var/www/users/*/log/nginx/*access*log* \ | awk '$9 ~ /^(200|206)$/'
Résultat chez moi : aucune ligne, ni sur le nom des fichiers, ni sur le répertoire. Personne n’a rien demandé.
Avec une réserve que je préfère écrire noir sur blanc, parce qu’elle vaut aussi pour vous, et qu’un simple ls -l sur le répertoire de journaux la met en évidence : mes journaux nginx sont conservés 15 jours, le plus ancien remonte au 13 août, et le premier fichier a été écrit le 5. Il y a donc une semaine entière sur laquelle je n’ai aucune donnée, et sur laquelle je ne peux rien affirmer.
Faut-il régénérer sa clé de licence et ses clés API ?
Vu qu’aucun de ces fichiers n’était référencé nulle part et qu’il fallait deviner un horodatage à la seconde près pour tomber dessus, j’estime le risque réel très faible sur mon propre site.
Mais si une seule de ces requêtes était sortie en 200 dans mes journaux, je régénérais la clé Cloudflare, la clé Sucuri et la licence WP Rocket dans la foulée, sans discuter et sans chercher à me rassurer.
Et si vous ne conservez aucun journal d’accès, ou qu’ils ne remontent pas jusqu’à votre passage en 3.23.1, vous êtes dans le doute, ce qui est en soi une raison suffisante pour régénérer. Une clé Cloudflare donne la main sur votre DNS, donc sur votre nom de domaine et sur vos e-mails, ce qui est très au-dessus de l’enjeu d’une licence de cache.
Ce que cette faille dit de la sécurité WordPress
Une extension installée sur un très grand nombre de sites a écrit des secrets en clair dans un répertoire public pendant plusieurs versions, et personne ne l’a vu passer, ni chez l’éditeur ni chez les milliers de professionnels qui l’installent tous les jours.
Ce n’est pas un procès fait à WP Rocket, qui reste une bonne extension, à condition de la configurer et de ne pas la considérer comme une case cochée. C’est un rappel que la sécurité d’un WordPress ne se joue pas dans le CMS, mais en dessous, dans ce que le serveur accepte de servir et dans ce que vous êtes capable de retrouver dans vos journaux trois semaines après les faits.
Sans journaux d’accès conservés, sans inventaire de vos sites, et sans personne pour lire un correctif avant de l’appliquer, vous ne pouvez tout simplement pas répondre à la question posée par ce mail, et un WordPress dont personne ne surveille les entrées finit toujours par être visité.
C’est le travail que je fais sur les serveurs de mes clients, mises à jour et vérifications comprises. Si vous avez lu tout ça en vous demandant qui, chez vous, va aller regarder, on peut en parler. 🙂