Le 21 octobre 2026, Axios a rapporté une attaque potentielle exploitant deux failles de PHP ainsi que la mise hors ligne temporaire de dizaines de sites aux États-Unis, au Royaume-Uni et ailleurs. Au moment de la publication des correctifs, The PHP Foundation indiquait que son équipe n’avait identifié aucun exploit fonctionnel. Sous certaines conditions, les deux failles pouvaient permettre une exécution de code à distance sans authentification, ou RCE, c’est-à-dire l’exécution de code sur un serveur à distance.
La séquence de divulgation avait été bousculée avant la publication. Le 20 octobre, les identifiants CVE ont commencé à circuler en ligne. The PHP Foundation a indiqué que le projet avait avancé sa préannonce et déplacé la publication prévue le 22 octobre au 21. Calif a ensuite publié par erreur une vidéo montrant une preuve de concept en action, dont des copies ont circulé en ligne. Le 21 octobre à 07 h 41 UTC, Chainguard a publié des images de compilation contenant le correctif, plus de six heures avant la publication coordonnée.
Deux failles, deux mécanismes
PHP a associé CVE-2026-109618 à une corruption liée à l’épuisement de mémoire, et CVE-2026-109619 à un état global obsolète après une erreur fatale. Les deux vulnérabilités pouvaient permettre une RCE sans authentification sous certaines conditions. PHP leur a attribué à chacune un score de 9,2 selon CVSS v4.0.
| Identifiant | Mécanisme | Impact décrit |
| CVE-2026-109618 | Une erreur d’épuisement de mémoire peut laisser des données internes de requête partiellement initialisées, ensuite traitées comme valides. | RCE sans authentification sous certaines conditions. Wiz a aussi démontré une divulgation à distance de mémoire de processus. |
| CVE-2026-109619 | Après une erreur fatale, un état interne peut rester associé à une mémoire libérée. Une requête ultérieure traitée par le même worker, ou processus de traitement, peut réutiliser cet état. | RCE sans authentification sous certaines conditions. |
Wiz a rapporté avoir démontré une RCE sans authentification sur des images conteneurisées de WordPress, Drupal et Joomla qui étaient alors à jour. Selon l’entreprise, les failles se trouvent dans PHP lui-même et ne nécessitent donc pas de défaut propre à ces systèmes de gestion de contenu.
PHP a indiqué que toutes les installations servant des requêtes web étaient concernées et a désigné mod_php comme le mode de déploiement le plus risqué. Dans le scénario démontré, une requête sans authentification pouvait atteindre le chemin vulnérable avant l’exécution du code de l’application. Wiz a indiqué que des versions concernées remontaient jusqu’à PHP 5.4.
Des chercheurs assistés par l’IA, des correctifs menés par PHP
OpenAI a indiqué que des chercheurs de Calif avaient repéré une faille critique avec GPT-5.6 Sol dans le cadre de son initiative Patch the Planet. Wiz a indépendamment découvert et signalé les deux vulnérabilités. The PHP Foundation a aussi rapporté qu’un développeur de PHP avait repéré dès 2024 les premiers signes du problème de corruption mémoire. Le 11 août 2026, Ryan A, chercheur chez Calif, a signalé une exécution de code à distance liée à cette même cause. Les mainteneurs de PHP ont dirigé la mise au point et la publication des correctifs.
Versions corrigées et suite à donner
Le 21 octobre, PHP a publié les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35 pour corriger les deux failles. L’avis de sécurité officiel de PHP décrit les vulnérabilités et les versions concernées. NeoTeo avait également présenté les versions de PHP qui corrigent les deux failles critiques.
PHP 8.1 et les versions antérieures ne reçoivent plus de mises à jour du projet PHP, même si certaines distributions et certains fournisseurs de versions à support prolongé proposent des correctifs rétroportés. PHP précise que les mesures de configuration temporaires peuvent réduire des voies d’attaque particulières, mais que seule l’installation d’une version corrigée constitue une remédiation complète. Pour les anciennes branches, le projet recommande de vérifier auprès de sa distribution ou de son hébergeur si un correctif rétroporté est disponible, ou de migrer vers une branche maintenue.
