PHP2Shell : deux failles critiques de PHP permettent de prendre la main sur les serveurs web sans authentification

Le 21 octobre 2026, le projet PHP a publié en urgence les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35 pour corriger CVE-2026-109618 et CVE-2026-109619, deux failles mémoire qui permettent d’exécuter du code à distance avec une simple requête HTTP, sans compte. Le CERT-FR a émis une alerte : toute installation PHP exposée au web doit être mise à jour, y compris les vieilles branches 7.x et 8.0–8.1.

Ce qui s’est passé

Le projet PHP a diffusé le 21 octobre 2026 une mise à jour de sécurité critique, PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, qui comble deux failles d’exécution de code à distance surnommées PHP2Shell, notées chacune 9,2 en CVSS 4.0. Le CERT-FR a publié dans la foulée l’alerte CERTFR-2026-ALE-014. CVE-2026-109618 tient à la gestion du manque de mémoire : une requête peut être interrompue alors que ses données internes ne sont qu’à moitié initialisées, et la phase de nettoyage réutilise ensuite ces données invalides. Des requêtes multipart surdimensionnées suffisent notamment à la déclencher. CVE-2026-109619 est une utilisation de mémoire libérée : un état laissé par une requête subsiste dans le processus et sert à la requête suivante.

Qui est concerné

Selon php.net, toutes les installations qui servent des pages web sont visées : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Les avis de l’équipe PHP indiquent qu’une exécution de code complète, sans authentification, a été démontrée sur mod_php en configuration par défaut, et sur FPM pour la seconde faille. Le CERT-FR range parmi les versions vulnérables toutes les 5.x, 6.x, 7.x, 8.0 et 8.1 ; à titre exceptionnel, l’équipe PHP a publié des correctifs minimaux sous forme de code source pour les branches 7.4, 8.0 et 8.1, qui ne sont plus maintenues. Aucune exploitation active n’était signalée par les sources officielles au moment de la rédaction, mais des démonstrations circulent sur des forums, d’après ZATAZ. WordPress, Drupal, Joomla et les applications maison reposent tous sur PHP.

Que faire maintenant

1. Recensez vos versions de PHP sur chaque serveur et conteneur : php -v, en vérifiant la version réellement utilisée par le serveur web (pool FPM, module Apache).
2. Mettez à jour vers 8.2.35, 8.3.36, 8.4.27 ou 8.5.12, ou installez les paquets corrigés de votre distribution (apt update && apt upgrade, dnf upgrade 'php*'), puis redémarrez PHP-FPM ou Apache pour qu’aucun ancien processus ne reste actif.
3. Si vous ne pouvez pas corriger aujourd’hui : passez session.upload_progress.enabled = Off dans php.ini, comme le préconise le CERT-FR, ainsi que fatal_error_backtraces à Off ; l’équipe PHP prévient que ces réglages ne ferment pas toutes les portes.
4. En 7.4, 8.0 ou 8.1 : appliquez sans attendre les rétroportages ou les correctifs de votre éditeur, et planifiez la migration vers une branche maintenue (la 8.2 elle-même s’arrête le 31 décembre 2026).
5. Surveillez vos journaux : plantages de processus PHP, erreurs de dépassement mémoire, fichiers inattendus dans les répertoires web.

Notre avis

PHP fait tourner une grande partie des sites d’entreprise, souvent dans des versions dont plus personne ne se souvient. Ces failles rappellent qu’il faut inventorier les environnements d’exécution, pas seulement les applications, et traiter une branche PHP en fin de vie comme un risque à éliminer plutôt qu’un héritage à supporter.

Sources

• PHP — Critical security release: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35
• CERT-FR — CERTFR-2026-ALE-014 : Multiples vulnérabilités dans PHP
• PHP (GitHub security advisory) — RCE via OOM corruption
• PHP (GitHub security advisory) — RCE via stale global state
• ZATAZ — PHP2Shell : deux failles critiques menacent les serveurs web

Comment nous choisissons, vérifions et rédigeons nos analyses →