Je sais que c'est à la mode en ce moment de vibecoder des outils qui manipulent des PDF donc c'est pour ça que je relaie cette alerte de Wordfence qui vient de publier le détail d'une faille dans Ghostscript (c'est un programme très connu qui transforme grosso modo les PDF en images).

Argus, l'agent IA de recherche de faille de Wordfence, a donc trouvé cette vuln d'un score CVSS de 9,8 sur 10 référencée sous le code CVE-2026-39919. Elle est assez grave puisqu'un PDF piégé contenant une image JPEG 2000, forgé pour l'occasion, suffit à faire écrire Ghostscript au-delà de sa mémoire et donc à introduire dans la mémoire de la machine du code malveillant.

Côté WordPress pur, le chemin est tordu car pour fabriquer la miniature d'un PDF, Wordpress appelle Imagick, qui appelle ImageMagick, qui lance ensuite Ghostscript. Mais Wordfence a obtenu par ce biais une exécution de code sans authentification sur un site de test monté pour l'occasion, y compris avec le paramétrage de sandbox -dSAFER activé.

Pour être touché, il faut donc 4 choses en même temps :

• 1/ Qu'un visiteur ou un compte limité puisse téléverser un PDF
• 2/ Que quelque chose en génère un aperçu
• 3/ Que votre serveur ait Imagick ou un outil qui appelle Ghostscript
• 4/ Et que ce Ghostscript n'ait pas le correctif.

Comme vous le savez surement, WordPress de base ne laisse pas un anonyme envoyer de PDF dans la médiathèque, donc il faut qu'un plugin, un formulaire ou un compte lui ouvre la porte pour que la première condition soit remplie.

Bien sûr, ça ne s'arrête pas à WordPress puisque tout ce qui est outil de gestion de documents, services d'impression, passerelles mail ou API de conversion peuvent être également exposés à partir du moment où ils donnent des PDF inconnus à un Ghostscript vulnérable.

Maintenant pas de panique parce que ces exploits mis au point par Wordfence exigent quand même d'être forgés spécifiquement pour l'environnement ciblé et aucune exploitation sauvage n'a été constatée pour le moment.

Maintenant si un attaquant connait votre build ou vise un hébergeur dont plusieurs sites partagent la même image, ça fera surement des dégât, donc il vaut mieux patcher ça.

D'après la page de sécurité d'Ubuntu et le suivi de Debian , Ubuntu a corrigé ses 22.04, 24.04 et 26.04, et Debian sa 13, tandis que Debian 12 reste marquée vulnérable. Red Hat a des paquets corrigés pour RHEL 8, 9 et 10, AlmaLinux 10 aussi depuis le 2 octobre, et Wordfence notait au 9 octobre que Fedora 44 et Alpine 3.22 et 3.23 en étaient encore à leurs anciennes révisions.

Et ne vous fiez pas au numéro que renvoie gs --version puisqu'Ubuntu 22.04 greffe son correctif sur un Ghostscript qui continue de se présenter comme une version 9.55.0. C'est surtout la révision du paquet qui tranche. Un dpkg -s ghostscript la donnera sur Debian et Ubuntu et un rpm -q ghostscript vous donnera l'info sur une Red Hat / Fedora.

Et sous Docker, il faudra "pull" une image à jour, reconstruire sans le cache et redéployer tout ça.

Reste une parade si le correctif n'existe pas encore pour votre système qui est expliqué sur la page de politique de sécurité d'ImageMagick . Sur cette page, vous trouverez une règle à intégrer dans le fichier policy.xml, qui ne laisse que l'écriture des formats PDF, PS, PS2, PS3 et XPS, et désactive l'aperçu de PDF.

La commande magick identify -list policy permet ensuite de vérifier que le changement est bien pris en compte. Bien sûr, elle ne fonctionne qu'avec ImageMagick et il est possible qu'une autre bibliothèque se glisse entre votre application et Ghostscript, donc soyez vigilant.

Dans tous les cas, si vous avez un doute, le mieux reste encore de demander à votre hébergeur si son Ghostscript dispose du correctif de la CVE-2026-39919.

Source : le billet de Wordfence et l'article de BleepingComputer

Vous avez un site sous WordPress ? Alors lâchez tout ce que vous faites deux minutes, parce que là c'est du sérieux !!

Cette nouvelle attaque baptisée WP2Shell permet de compromettre une installation Wordpress sans passer par le moindre plugin. Heureusement, un patch est sorti en urgence le 17 juillet !

En temps normal, quand une alerte sécu tombe sur WordPress, le fautif c'est un plugin tiers vérolé , un truc installé un soir de flemme et oublié depuis des lustres. Mais cette fois, rien de tout ça puisque le trou de sécu se trouve dans le cœur de WordPress lui-même.

Dans le détail, WP2Shell enchaîne deux failles. La première, CVE-2026-63030 , est une confusion de route dans l'API REST batch, sur l'endpoint /wp-json/batch/v1. La seconde, CVE-2026-60137 , est une injection SQL bien planquée dans le paramètre author__not_in de WP_Query. Chacune dans son coin, c'est déjà vilain, mais mises bout à bout, elles offrent une exécution de code à distance.

Pas de compte, pas de mot de passe, et encore moins de plugin exotique mais simplement quelques requêtes HTTP et hop, c'est plié !

Côté versions, la chaîne complète touche WordPress 6.9.0 à 6.9.4 et 7.0.0 à 7.0.1. Si votre site est dans cette fourchette, vous êtes donc exposé. Les correctifs sont arrivés avec les versions 6.9.5 et 7.0.2. Et si vous vous traînez encore une vieille 6.8.x, sachez que seule l'injection SQL vous concerne potentiellement mais qu'elle a été patchée depuis la version 6.8.6.

Derrière cette trouvaille, on trouve Adam Kues, chercheur chez Assetnote (une branche de Searchlight Cyber), qui a assemblé et documenté toute la chaîne avant de la remonter proprement via le programme HackerOne de WordPress. Les détails techniques les plus croustillants restent sous le coude le temps que la planète patche mais l'équipe a mis en ligne un outil, wp2shell.com , pour vérifier si votre site est vulnérable. Allez-y, ça coûte rien !

Autre signal qui ne trompe pas, WordPress.org a déclenché les mises à jour automatiques forcées sur les sites concernés. Une mesure réservée aux failles vraiment graves, comme à l'époque où la faille critique de Really Simple Security avait exposé des millions de sites. Il y a donc de bonnes chances que votre installation toute pourrie dont vous ne vous occupez pas parce que vous êtes un mauvais webmaster ^^ ait déjà été rustinée toute seule. Vraiment, vous ne méritez pas les équipes sécu de Wordpress ^^

Mais ne pariez pas votre site là-dessus non plus... Car si vous avez désactivé les mises à jour auto (et beaucoup d'hébergeurs et d'admins le font), personne n'aura rien poussé chez vous. Sans oublier qu'un bout de PoC circule déjà sur GitHub (les chercheurs gardent pour eux le dernier maillon vers la RCE, mais ça n'arrêtera pas longtemps les motivés), et les scans automatisés ont commencé.

En attendant de patcher, bloquez surtout donc l'accès anonyme à l'endpoint batch de l'API REST via votre WAF ou votre plugin de sécu. Attention, pas seulement la forme /wp-json/batch/v1 : sa variante ?rest_route=/batch/v1 doit sauter aussi, sinon autant laisser la clé sur la porte. Cloudflare propose d'ailleurs des règles toutes prêtes. Et pour durcir le reste de votre config, ma vieille série sur le sujet reste d'actualité.

En tout cas, quand on sait qu'il y a +500 millions de sites actuellement propulsés par Wordpress, même s'ils ne sont pas tous concernés par cette faille, ça reste une surface d'attaque gigantesque !!

Bref, filez vérifier votre version. Sous 6.9.5 ou 7.0.2, vous mettez à jour et vous bloquez le batch en attendant. Deux minutes chrono, et votre site dort tranquille !

Source : Security Affairs