PHP2Shell : deux failles critiques dans PHP, et un correctif qui ne passe pas par WordPress

Le 21 octobre 2026, le projet PHP a publié quatre versions de sécurité (8.5.12, 8.4.27, 8.3.36 et 8.2.35) qui corrigent deux failles critiques, CVE-2026-109618 et CVE-2026-109619, notées 9,2 sur 10 et regroupées sous le nom PHP2Shell. D’après l’annonce de php.net, elles peuvent permettre à un attaquant d’exécuter du code à distance sans authentification.

Les failles se situent dans le moteur PHP, et non dans un plugin ou dans le code d’un site mal entretenu. WordPress, Drupal, Joomla, Magento, Symfony ou Laravel peuvent donc être concernés même si leur propre code est à jour. Mettre à jour le CMS ne règle rien: c’est la version de PHP installée sur le serveur qui doit changer.

Les sites sous PHP 8.1 ou plus ancien sont les plus mal placés. Cette branche est en fin de vie et php.net n’a publié aucun correctif pour elle. D’après le relevé de Digidop du 22 octobre, tiré des statistiques de WordPress.org, 35,8 % des sites WordPress tournent sur PHP 8.1 ou moins. Ils doivent migrer. Seules les branches 8.2 à 8.5 sont supportées, et la 8.2 ne reçoit des correctifs de sécurité que jusqu’au 31 décembre 2026. Mieux vaut viser la 8.3 ou plus récente.

Le délai n’a pas joué en faveur des défenseurs. Selon Paperjam, qui cite Amazon, des attaques avaient commencé au moins le 17 octobre, quatre jours avant les correctifs. Cloudflare a signalé des tentatives avant la publication et watchTowr en a observé sur ses serveurs-pièges. Aucune grande infrastructure n’avait documenté publiquement d’intrusion réussie attribuée avec certitude à PHP2Shell à la date de l’article, mais l’État luxembourgeois a coupé temporairement certains services par précaution dès le 21 octobre.

Pour une PME, la difficulté est surtout organisationnelle. Le site tourne chez un hébergeur ou un prestataire, la version de PHP n’apparaît dans aucun tableau de bord que la direction regarde, et personne n’a ce sujet dans sa fiche de poste. Cette mise à jour relève d’un administrateur systèmes ou d’un profil DevOps, et ce profil n’existe pas toujours dans une petite structure.

Demandez à l’hébergeur ou au prestataire quelle version de PHP tourne sur chaque site, et à quelle date elle passera dans une version corrigée. Sous WordPress, la version s’affiche dans Outils, puis Santé du site. Une fois la mise à jour faite, les processus PHP doivent être redémarrés: tant que les anciens tournent en mémoire, le serveur reste vulnérable.