Que s’est-il passé ? La timeline en quelques dates

L’histoire de ces vulnérabilités ne commence pas le 21 octobre.

2024 : les premiers signes apparaissent

En 2024, PHP fait l’objet d’un audit de sécurité externe réalisé par Quarkslab.

En travaillant sur l’un des problèmes identifiés pendant cet audit, un développeur du cœur de PHP détecte les premiers signes du problème de gestion mémoire qui sera plus tard associé à CVE-2026-109618.

À ce moment-là, un scénario d’exploitation est envisagé, mais aucun chemin concret permettant une exécution de code à distance n’est identifié. Le problème reste donc connu, mais son impact réel n’est pas encore démontré.

30 juillet 2026 : un nouvel audit de PHP commence

Dans le cadre du programme Patch the Planet, la société de sécurité Calif commence un nouvel audit du moteur PHP.

11 août 2026 : l’impact devient critique

Le 11 août, un chercheur de Calif signale une possibilité d’exécution de code à distance reposant sur la même cause racine que le problème identifié en 2024.

Selon la PHP Foundation, OpenAI signale indépendamment le même problème le même jour. À partir de cette date, la correction devient une priorité pour les équipes travaillant sur la sécurité de PHP. D’autres chemins d’attaque seront ensuite remontés, notamment par Wiz le 24 août et par OpenAI le 18 septembre.

20 octobre 2026 : les CVE fuitent avant la publication

La divulgation était initialement prévue pour le 22 octobre à 14:00 UTC.

Mais le 20 octobre vers 15 h UTC, les identifiants des deux CVE commencent à circuler sur des forums et les réseaux sociaux, avant la divulgation prévue. À ce stade, les informations relayées restent toutefois partielles, puisque aucun détail technique complet n’a encore été publié et que le score CVSS de 10/10 annoncé initialement est erroné. Le niveau de sévérité officiellement retenu sera finalement de 9,2/10, ce qui conduit PHP à revoir son calendrier et à avancer la publication des correctifs.

À 19:30 UTC, le projet publie un avertissement annonçant une mise à jour critique pour le lendemain.

21 octobre 2026 : publication des correctifs

La publication officielle est finalement avancée au 21 octobre à 14:00 UTC.

PHP publie :

La consigne officielle est particulièrement claire : les utilisateurs de PHP doivent mettre à jour immédiatement.

La PHP Foundation précise également que plusieurs PoC ont commencé à circuler autour de la divulgation. En revanche, elle indique qu’au moment de la publication officielle, l’équipe PHP n’avait pas identifié d’exploit fonctionnel parmi ceux qu’elle surveillait.

Une nuance importante lorsque l’on distingue les faits établis des spéculations entourant une vulnérabilité critique.

Pourquoi ces failles PHP sont-elles particulièrement importantes ?

Une vulnérabilité permettant une Remote Code Execution, ou RCE, fait partie des scénarios les plus sérieux pour un serveur web. Au lieu de simplement provoquer une erreur ou de consulter une information, un attaquant peut potentiellement parvenir à faire exécuter ses propres instructions par le serveur vulnérable.

Selon les droits du service compromis et l’architecture du système, les conséquences peuvent aller bien plus loin que la simple indisponibilité du site. C’est ce potentiel qui explique le niveau de criticité de ces deux vulnérabilités.

Imaginez votre serveur comme un immeuble. Une vulnérabilité classique pourrait permettre à quelqu’un de regarder par une fenêtre qui aurait dû rester fermée. Une RCE revient plutôt à lui permettre d’entrer dans le bâtiment et d’agir à l’intérieur.

Mon site WordPress ou mon application Symfony sont-ils concernés ?

C’est probablement la première question que beaucoup d’entreprises vont se poser. Mais WordPress, Symfony, Drupal ou Joomla ne sont pas directement à l’origine du problème. La vulnérabilité se situe plus bas à savoir dans PHP lui-même.

Il faut donc plutôt se demander « Quelle version de PHP exécute réellement mon application ? »

PHP demande d’examiner toutes les installations servant des requêtes web, notamment :

• PHP-FPM ;
• Apache avec mod_php ;
• php-cgi ;
• FrankenPHP ;
• LiteSpeed.

Le projet PHP considère le risque comme particulièrement élevé avec Apache et mod_php, car une exploitation sans authentification a été démontrée avant même que le code de l’application ne commence à s’exécuter.

Une exécution de code a également été confirmée avec PHP-FPM via des chemins dépendant de l’application. Utiliser PHP-FPM ne signifie donc pas que l’on peut ignorer le problème.

Quelles versions de PHP faut-il utiliser ?

Les versions publiées le 21 octobre 2026 corrigent les vulnérabilités :

Pour les entreprises encore sous PHP 8.1 ou une version antérieure, le sujet est plus large : ces versions ne sont plus maintenues directement par le projet PHP.

Certains fournisseurs Linux ou services LTS peuvent proposer leurs propres correctifs rétroportés. Il faut donc vérifier auprès du fournisseur concerné ou migrer vers une branche maintenue.

Enfin, PHP 8.2 atteindra sa fin de vie le 31 décembre 2026. Une entreprise mettant aujourd’hui PHP 8.2 à jour vers 8.2.35 devrait donc déjà anticiper sa prochaine migration.

Un WAF peut-il nous protéger ?

Un WAF peut bloquer certains scénarios d’attaque et réduire l’exposition le temps de déployer. Il ne remplace pas le correctif, et le projet PHP est clair là-dessus.

Le bon réflexe reste donc d’identifier → mettre à jour → redéployer → vérifier. Cette dernière étape est souvent négligée.

Dans une infrastructure moderne, PHP peut se trouver dans un serveur historique, une VM, un conteneur Docker, plusieurs pools PHP-FPM ou encore chez un hébergeur externe. Mettre à jour « le serveur PHP » ne signifie donc pas forcément que toutes les instances réellement utilisées ont été corrigées.

Que faire dès maintenant ?

Pour une entreprise utilisant PHP, quatre actions sont prioritaires.

1. Identifier les applications PHP

Commencez par les applications et services exposés sur Internet, puis élargissez l’inventaire aux systèmes internes.

2. Vérifier la version réellement exécutée

La documentation et la CMDB ne suffisent pas : regardez ce qui s’exécute en production, conteneurs compris.

3. Appliquer les correctifs

Passez par la préproduction pour éviter les régressions, puis assurez-vous que les services et workers ont bien été redémarrés. Pour les conteneurs, il faut reconstruire les images.

4. Conserver une trace de votre exposition

Pour les systèmes sensibles exposés avec une version vulnérable, conservez les journaux utiles à une éventuelle investigation. Être vulnérable ne veut pas dire avoir été compromis, mais vous devez pouvoir dire où tournait cette version au moment de la divulgation.

Aller plus loin : que se passe-t-il réellement dans PHP ?

Les deux vulnérabilités touchent des mécanismes internes différents, mais ont un point commun : la gestion de la mémoire et de l’état d’une requête PHP.

CVE-2026-109618 concerne une situation dans laquelle PHP rencontre un problème d’allocation mémoire alors que certaines données internes ne sont pas encore complètement initialisées. PHP peut ensuite manipuler ces données comme si elles étaient valides.

CVE-2026-109619 concerne un état interne pouvant continuer à pointer vers une zone mémoire appartenant à une requête précédente alors que cette mémoire a déjà été libérée.

Dans certaines conditions, ces deux vulnérabilités peuvent mener à une exécution de code à distance. L’enjeu est donc d’identifier les environnements PHP exposés, d’évaluer leur niveau de risque et de prioriser l’application des correctifs.

PHP2Shell : un rappel sur l’importance de connaître ses dépendances

Ces deux vulnérabilités racontent finalement une histoire assez classique en cybersécurité.

Une entreprise peut avoir sécurisé son développement, réalisé des pentests et correctement maintenu son CMS tout en restant exposée à une vulnérabilité située dans une brique logicielle fondamentale. Le vrai problème devient alors la visibilité :

• Savez-vous quelles versions de PHP sont réellement utilisées ?
• Dans quels conteneurs ?
• Sur quels serveurs ?
• Pour quelles applications ?
• Et surtout : combien de temps faut-il à votre organisation pour obtenir ces réponses lorsqu’une vulnérabilité critique est publiée ?

On ne peut pas corriger rapidement une technologie que l’on ne savait pas utiliser.