Deux failles critiques dans le moteur de PHP, surnommées PHP2Shell

22 octobre 2026 — Sécurité, serveurs web

PHP a sorti hier soir une mise à jour de sécurité pour deux failles dans le moteur lui-même, CVE-2026-109618 et CVE-2026-109619, que tout le monde appelle déjà PHP2Shell. Elles permettent d’exécuter du code sur le serveur à distance, sans être authentifié. Les détails avaient fuité la veille et Cloudflare a vu passer des tentatives d’attaque dès mercredi matin, avant même la publication des correctifs. Si vous avez un serveur web avec PHP dessus, c’est à faire aujourd’hui.

Un peu de contexte

Mardi 20 octobre, quelqu’un a publié sur Hacker News les identifiants de deux vulnérabilités encore sous embargo. watchTowr a confirmé qu’elles existaient bien, et l’équipe de sécurité de PHP a annoncé dans la foulée une version corrective pour le mercredi 21 à 14 h UTC, soit 16 h chez nous. Elle est sortie à l’heure : 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Debian et Ubuntu ont publié leurs paquets dans l’après-midi.

Les deux failles sont notées 9,2 en CVSS v4.0. Elles sont dans PHP, pas dans WordPress ni dans une extension : on peut les déclencher pendant que PHP traite la requête, avant que le code du site ne tourne.

La première, CVE-2026-109618, concerne la gestion du dépassement de mémoire. Quand une requête atteint le memory_limit, PHP abandonne le traitement en cours d’un coup. Si ça tombe au milieu de l’initialisation des données de la requête, certaines structures internes restent à moitié remplies, et c’est exploitable.

La seconde, CVE-2026-109619, est un pointeur global qui continue de désigner de la mémoire appartenant à une requête après que celle-ci a été libérée. Un use-after-free assez classique.

Toutes les versions de 5.4 à 8.5.11 sont touchées, et peu importe comment PHP tourne : PHP-FPM, mod_php, CGI, FrankenPHP, LiteSpeed.

Quelles versions installer

Côté projet PHP :

Côté distributions, attention : Debian et Ubuntu appliquent le correctif sur leur propre version de PHP, donc php -v peut très bien afficher le même numéro qu’avant. Sur une Ubuntu 24.04 à jour, on lit toujours 8.3.6. Il faut regarder la version complète du paquet.

Mercredi soir, Debian testing (forky) et sid n’étaient pas encore corrigées. Le dépôt de Sury (packages.sury.org, ou le PPA ondrej sous Ubuntu) a déjà les versions 8.2 à 8.5 à jour.

La mise à jour sous Debian / Ubuntu

On commence par voir ce qui est installé. Il n’est pas rare d’avoir deux branches côte à côte sur la même machine (une 8.2 oubliée à côté de la 8.3, par exemple), et il faut tout mettre à jour.

php -v
dpkg -l | grep -E '^ii +(php|libapache2-mod-php)'

Ensuite la mise à jour proprement dite. J’ai pris php8.3 comme exemple, adaptez à votre branche. Un apt upgrade complet marche aussi, évidemment.

sudo apt update
apt-cache policy php8.3-common
sudo apt install --only-upgrade 'php8.3*'

Ne pas oublier de redémarrer PHP. Un PHP-FPM ou un Apache lancé avant la mise à jour garde l’ancien code en mémoire, et le serveur reste vulnérable tant qu’il n’a pas été relancé.

# PHP-FPM
sudo systemctl restart php8.3-fpm

# Apache avec mod_php
sudo systemctl restart apache2

Pour vérifier avec les paquets Debian ou Ubuntu, les deux CVE doivent apparaître dans le changelog :

zgrep -E 'CVE-2026-10961[89]' /usr/share/doc/php8.3-common/changelog.Debian.gz

Avec les paquets Sury ou un PHP compilé soi-même, php -v doit afficher 8.5.12, 8.4.27, 8.3.36 ou 8.2.35. La CLI et le PHP servi par le site ne sont pas toujours les mêmes ; dans le doute, un phpinfo() temporaire tranche la question (et on le supprime juste après).

Sur les autres systèmes, rien de bien différent. Sous RHEL, Alma ou Rocky, c’est sudo dnf upgrade 'php*' puis un redémarrage de php-fpm ou httpd. Sous Docker, il faut reconstruire les images à partir d’une image PHP à jour et recréer les conteneurs : tirer la nouvelle image sans relancer ne change rien. Et pour un PHP compilé à la main, il faut recompiler depuis les sources corrigées.

Le cas de PHP 8.1 et plus ancien

Le projet PHP ne sort pas de nouvelle version pour ces branches. L’équipe de sécurité a quand même publié des correctifs en sources pour 7.4, 8.0 et 8.1, et les distributions les ont intégrés : Ubuntu 22.04 les reçoit en standard, les versions plus anciennes via Ubuntu Pro. Si vous n’êtes dans aucun de ces cas, il n’y a pas vraiment d’autre solution que de migrer. Et quitte à migrer, autant viser 8.3 ou 8.4 directement : la 8.2 n’a plus que dix semaines de support devant elle.

En attendant, on peut limiter la casse avec ce réglage dans le php.ini du serveur web (/etc/php/X.Y/fpm/php.ini ou /etc/php/X.Y/apache2/php.ini), suivi d’un redémarrage :

session.upload_progress.enabled = 0

Pour faire court : mettez à jour vers 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 (ou les paquets de votre distribution), redémarrez PHP-FPM ou Apache, et vérifiez que le correctif est bien pris en compte.

Sources : IT-Connect · Huntress · Google Cloud · runZero · Debian Security Tracker · php.net