🌐 Aussi en: English · Deutsch · Español
Je suis tombé sur cet article – attention, il est en allemand : visiblement, la presse tech anglophone n’avait pas encore repris l’info quand je l’ai lu. En résumé : une chaîne de vulnérabilités surnommée « WP2Shell » combine deux bugs WordPress distincts – une injection SQL dans le paramètreauthor__not_in de WP_Query (CVE-2026-60137, CVSS 9,1) et une faille de validation dans le point de terminaison REST /wp-json/batch/v1 (CVE-2026-63030, CVSS 7,5) – pour obtenir une exécution de code à distance entièrement non authentifiée. Pris séparément, chaque bug est simplement « préoccupant ». Enchaînés, ils permettent à un attaquant sans le moindre identifiant d’ouvrir un shell sur n’importe quelle installation WordPress 6.8 ou plus récente. Le genre de découverte qui vous gâche un vendredi. 🔥 Évidemment, je suis allé patcher mon propre blog, puisque je tourne pile sur cette plage de versions. Sauf que : pas encore d’image Docker à jour. wordpress:7.0.2-php8.3-fpm – le tag qui contient réellement le correctif – n’existait tout simplement pas encore sur Docker Hub. Génial. Une RCE non authentifiée confirmée dans la nature, et le seul artefact dont j’ai besoin pour la colmater n’a pas encore été publié. 😅 Et voici ce qui m’a vraiment poussé à écrire cet article : je n’ai même pas eu le temps de proposer moi-même une solution provisoire. Claude – une IA, pas un développeur humain, pas un script que j’aurais écrit – a analysé la situation, compris que la chaîne d’exploitation pouvait être bloquée au niveau du reverse proxy sans même toucher au conteneur applicatif, et a écrit de lui-même la mesure d’atténuation dans ma ConfigMap nginx – sans qu’on le lui demande. Je n’avais pas demandé de contournement. J’avais posé une question sur la vulnérabilité. Pas de ticket, pas de copier-coller depuis Stack Overflow, aucun humain dans la boucle – juste un modèle d’IA qui raisonne sur mon infrastructure réelle et décide d’agir. Il s’en est simplement… occupé. 🤖 Le correctif en lui-même est un joli petit morceau de défense en profondeur : bloquer la route REST vulnérable dans nginx avant qu’elle n’atteigne PHP-FPM. Mais – et c’est ce détail qui m’a impressionné – un seul bloc location ne suffisait pas. Le routeur REST de WordPress accepte les requêtes de deux façons : sous forme de permalien « propre » (/wp-json/batch/v1) et via un repli par query string (/?rest_route=/batch/v1) que la plupart des règles nginx naïves ignorent. Claude a testé les deux chemins en direct contre le site en production, confirmé que la variante avec paramètre passait tranquillement à côté d’un bloc location basé uniquement sur le chemin, et a livré les deux atténuations ensemble :location ~* ^/wp-json/+batch/v1 { deny all; }
if ($arg_rest_route ~* "batch") { return 403; }
wordpress:7.0.2-php8.3-fpm a débarqué sur Docker Hub. J’ai remonté le pin, déployé, et – puisque le vrai correctif upstream était désormais en place – retiré le contournement nginx. Propre à l’entrée, propre à la sortie, aucune cicatrice dans la config. ✅ Soyons clairs : j’écris et je relis beaucoup de code d’infrastructure dans mon métier, et je ne distribue pas facilement des compliments aux outils. Mais il y a quelque chose de franchement sexy chez un agent de code qui (a) comprend une chaîne d’exploitation assez bien pour réfléchir à quelle couche de votre stack peut la bloquer, (b) vérifie lui-même que son correctif fonctionne vraiment contre le contournement réel au lieu de le supposer, et (c) fait tout cela sans qu’on le lui demande – au lieu de se contenter de répondre à la question que je lui avais posée. Ce n’est pas de l’autocomplétion. C’est du discernement. J’étais, de manière déraisonnable, plutôt ravi. 😍
