PHP : deux failles critiques ont fuité avant l’heure, un correctif d’urgence arrive ce 21 octobre !

Si vous administrez un serveur web sur lequel PHP est installé, la journée risque d'être chargée. Deux failles de sécurité critiques dans PHP seront patchées ce mercredi 21 octobre 2026 : l'équipe de PHP invite tout le monde à se préparer. Cela est d'autant plus vrai que ces failles auraient déjà fuitées.... Voici ce que l'on sait.

Le 20 octobre 2026, l'équipe de sécurité de PHP a publié une annonce inhabituelle sur php.net : une mise à jour de sécurité pour PHP sera publiée le mercredi 21 octobre 2026 à 14 h 00 UTC, soit 16 h 00 heure de Paris. Elle doit corriger deux vulnérabilités critiques, associées toutes les deux à un score de 9.2 sur 10, selon le CVSS v4.0.

"Nous invitons tous les utilisateurs de PHP à se préparer dès maintenant afin de pouvoir effectuer la mise à jour dès que la nouvelle version sera disponible.", peut-on lire.

C'est brûlant, mais nous ne savons pas grand-chose de plus : ni les versions affectées, ni les versions correctives, ni la façon dont ses failles sont exploitables (ce qui n'est pas plus mal dans un premier temps). Ces détails seront ajoutés aux bulletins qui vont accompagner les correctifs de sécurité.

L'équipe de PHP prévient également : "Nous nous réservons le droit de publier plus tôt", notamment si des détails techniques deviennent publics ou si une exploitation active est observée.

Cet avertissement n'est probablement pas anodin. En effet, un message publié sur le forum Hacker News, supprimé depuis, annonçait deux failles menant à une exécution de code à distance (RCE) dans PHP, avec un score CVSS de 10. Et ces vulnérabilités affecteraient de nombreuses versions de PHP, en remontant jusqu'à PHP 5.

watchTowr confirme la fuite des informations

Les chercheurs de watchTowr ont confirmé l'existence de ces deux vulnérabilités, référencées CVE-2026-109618 et CVE-2026-109619. "Nous pouvons confirmer que ces vulnérabilités sont bien réelles", affirme Benjamin Harris, CEO de watchTowr. D'après lui, elles affecteraient PHP 5, 6, 7 et 8.

watchTowr indique avoir reproduit CVE-2026-109618, sans publier de détails techniques avant la sortie des correctifs. Pour le moment, ces failles ne seraient pas exploitées par les cybercriminels, mais la situation peut rapidement évoluer. watchTowr mentionne donc deux identifiants de CVE qui n'ont pas été cité dans l'annonce officielle de PHP.

Session Upload Progress : la piste à surveiller en attendant le correctif

Le chercheur Kirill Firsov, qui semble lié à la découverte, a évoqué ces failles sous le nom de « php2shell » sur X, en recommandant une mesure temporaire : désactiver la fonction Session Upload Progress de PHP. La société japonaise GMO Flatt Security va dans le même sens dans son analyse. D'après ses propres recherches, il s'agirait d'une corruption mémoire liée à cette fonction de l'extension session, activée par défaut. Elle reconnaît toutefois ne pas pouvoir garantir à 100 % l'efficacité de cette mesure tant que les correctifs ne sont pas publiés.

L'équipe PHP n'a ni confirmé ni infirmé cette piste... Désormais, il ne reste plus qu'à attendre 16 h. En attendant, voici ce que vous pouvez faire :

• Inventaire : identifiez tous les serveurs et conteneurs qui exécutent PHP, y compris les instances oubliées.

• Mesure temporaire : passez la directive session.upload_progress.enabled à Off dans le php.ini utilisé par le serveur web (sous Debian et Ubuntu, celui de PHP-FPM ou d'Apache, pas celui de la CLI), puis rechargez le service. Attention, les barres de progression d'upload basées sur cette fonction ne fonctionneront plus.

• Mise à jour : installez les nouvelles versions dès leur publication. Si vous utilisez les paquets de votre distribution, surveillez aussi les bulletins de sécurité de l'éditeur.

• Versions obsolètes : seules les branches 8.2 à 8.5 sont encore maintenues par le projet PHP. Les serveurs sous PHP 8.1 ou plus ancien ne devraient donc pas recevoir de correctif officiel, ce qui rend la mesure temporaire d'autant plus importante, en attendant une migration. À moins que l'équipe de PHP fasse une exception...

La méthode à appliquer dépend de votre environnement, voici quelques instructions pour vous aider :

• Serveur avec PHP-FPM (qui est recommandé plutôt que le module Apache) : créez un fichier dédié, par exemple 99-php2shell.ini, dans le dossier conf.d de PHP-FPM (/etc/php/8.4/fpm/conf.d/ sous Debian 13), avec la ligne session.upload_progress.enabled = Off, puis rechargez PHP-FPM. Tous les pools sont couverts et le fichier restera présent lorsqu'une mise à jour sera installée (libre à vous de le supprimer quand les patchs seront appliqués). Mon tutoriel sur la configuration d'Apache2 avec PHP-FPM détaille l'organisation de ces fichiers.

• Apache avec mod_php : même principe dans le dossier conf.d d'Apache (/etc/php/8.4/apache2/conf.d/), puis rechargez Apache.

• Hébergement mutualisé : ajoutez la directive php_flag session.upload_progress.enabled off dans le .htaccess si l'hébergeur utilise mod_php.

• Conteneurs Docker : avec les images php officielles, placez le fichier .ini dans /usr/local/etc/php/conf.d/ (montage ou Dockerfile), puis redémarrez le conteneur.

Pour vérifier, fiez-vous à un phpinfo() appelé via le serveur web (page à supprimer ensuite) ou à la commande php-fpm -i.

On en reparle dans la journée...!

Ajouter IT-Connect à mes
sources préférées

Cofondateur d'IT-Connect et Microsoft MVP "Cloud and Datacenter Management". Mon obsession depuis près de 15 ans ? Rendre l'administration système et la cybersécurité accessibles, que vous soyez junior ou confirmé. Plus qu'un métier, l'IT est pour moi une véritable passion. J’accompagne au quotidien les sysadmins et les professionnels de l’IT dans leur montée en compétences et leur veille technique.