Le projet PHP a publié le 21 octobre 2026 les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35, qui corrigent deux vulnérabilités critiques du moteur. Selon l’avis de sécurité de php.net, elles peuvent permettre à un attaquant non authentifié d’exécuter du code sur un serveur. Les chercheurs qui les ont exploitées disent avoir utilisé des modèles d’IA de pointe pour transformer en attaque fonctionnelle un défaut présent depuis plus de dix ans. La publication a en outre été avancée d’une journée après une fuite.
Deux CVE, une même racine : la gestion des erreurs fatales
Les deux failles portent les identifiants CVE-2026-109618 et CVE-2026-109619, avec un score CVSS de 9,2. La première tient à la gestion du manque de mémoire : si une requête atteint la limite memory_limit au mauvais moment, PHP peut laisser derrière lui des données internes à moitié initialisées et les traiter ensuite comme valides. La seconde concerne un état global qui survit à la libération de la mémoire qui le portait : une requête suivante traitée par le même processus peut alors réutiliser cette mémoire libérée.
Le billet de la PHP Foundation souligne que les deux défauts se trouvent dans des parties du moteur que presque chaque requête traverse, la gestion de la mémoire et celle des erreurs. Sur Apache avec mod_php, une requête non authentifiée peut déclencher la première faille avant même l’exécution du code applicatif, et une exécution de code complète a été démontrée avec la configuration par défaut. L’avis de php.net cite comme exposées toutes les installations qui servent des requêtes web : PHP-FPM, mod_php, php-cgi, FrankenPHP et LiteSpeed. Il précise qu’il n’existe pas de mesure d’atténuation complète et que la mise à jour reste la seule option sûre.
Les branches 8.1 et antérieures ne reçoivent plus de correctifs du projet PHP. Certains distributeurs et éditeurs de support long terme proposent des correctifs rétroportés, que le projet invite à vérifier auprès de chacun.
Ce que les modèles d’IA ont changé, selon Wiz
Dans son compte rendu technique, l’équipe Wiz Research regroupe ses découvertes sous le nom PHP2Shell et décrit quatre bugs exploitables rattachés aux deux CVE. Elle affirme que toutes les versions de PHP publiées depuis dix ans sont touchées par au moins l’un d’eux, jusqu’à PHP 5.4. Wiz dit avoir obtenu une exécution de code sans authentification sur les images de conteneur officielles de WordPress, Drupal et Joomla, et avoir lu à distance des zones de mémoire du processus PHP pouvant contenir mots de passe, jetons et clés d’API. L’entreprise insiste sur le fait que le défaut se situe dans PHP lui-même : une application dont le code est sain peut être vulnérable.
Le point mis en avant par Wiz porte moins sur la découverte que sur l’exploitation. Construire l’attaque supposait d’enchaîner plusieurs défauts et de l’adapter à la disposition mémoire de chaque cible, au prix de longues séries d’essais et de débogage. Wiz indique avoir utilisé son outil Wiz Atlas, Gemini 4 Argon et GPT-5.6 Sol tout au long des recherches, et estime qu’un seul chercheur a accompli en une semaine ce qui aurait demandé des mois à une équipe de haut niveau. Ce chiffrage est celui de l’entreprise, qui commercialise par ailleurs des outils de détection pour cette faille. Wiz compare PHP2Shell à Heartbleed et Log4Shell ; la comparaison relève de son analyse, pas d’un constat établi.
Trois signalements indépendants et un problème connu depuis 2024
La chronologie publiée par la PHP Foundation montre que la cause racine n’était pas inconnue. En 2024, un audit externe financé par la Sovereign Tech Agency allemande et réalisé par Quarkslab a conduit un développeur du cœur de PHP à repérer les premiers signes du problème de mémoire. Faute de vecteur d’exploitation concret, et face à plusieurs correctifs possibles qui cassaient tous quelque chose (compatibilité, performances, extensions tierces), le travail a calé puis redémarré pendant des mois. La fondation qualifie ce retard d’« échec structurel », lié au mode de décision par consensus de l’équipe de sécurité et au manque de moyens.
Tout s’accélère en 2026. Inscrit au programme Patch the Planet par la fondation, PHP est audité à partir du 30 juillet par la société Calif. Le 11 août, le chercheur Ryan A, chez Calif, signale une exécution de code à distance inconditionnelle issue de la même cause ; OpenAI signale indépendamment la même cause le même jour, puis d’autres vecteurs le 18 septembre. Wiz, de son côté, découvre sa première faille le 19 août et la transmet le 24. La fondation remercie nommément l’équipe Codex Security d’OpenAI et signale avoir utilisé, plus tôt dans l’année, Claude Mythos d’Anthropic via Alpha-Omega pour analyser le code, puis Daybreak Red d’OpenAI pour valider des rapports et des exploits.
L’afflux d’outils a aussi un coût. La fondation indique que l’équipe de sécurité a publié 15 CVE depuis le 1er juillet et traité plus de 100 signalements qui se sont révélés invalides, en double ou impossibles à reproduire. Elle précise que l’IA aide à vérifier les rapports et à regrouper ceux qui partagent une même cause, mais qu’une personne prend chaque décision et écrit chaque correctif.
Une divulgation coordonnée qui a déraillé à deux jours de l’échéance
La publication était prévue le 22 octobre à 14 h UTC. Le 20 octobre vers 15 h UTC, les deux identifiants de CVE ont commencé à circuler sur des forums et des réseaux sociaux, avec une heure de publication erronée et un score CVSS faux de 10,0, sans détail technique. Le projet a avancé sa préannonce à 19 h 30 UTC et la sortie au 21 octobre à 14 h UTC, pour laisser aux distributions le temps d’empaqueter le correctif.
Deux autres incidents ont suivi, selon la fondation. Vers 20 h UTC, Calif a publié par erreur une vidéo montrant sa preuve de concept contre plusieurs cibles ; supprimée, elle a continué de circuler en copies et a accéléré l’écriture de preuves de concept par des tiers. Le 21 octobre à 7 h 41 UTC, plus de six heures avant la sortie coordonnée, Chainguard a publié des images contenant le correctif, ce qui permettait à n’importe qui d’étudier la modification sous forme binaire. L’équipe de sécurité de PHP indique n’avoir identifié aucun exploit fonctionnel parmi les preuves de concept apparues au moment de la publication. Simon Willison, qui relaie l’annonce, fait état d’exploits en circulation dès la nuit précédente.
Un appel au financement
La PHP Foundation conclut sur les moyens. Le langage fait tourner des services publics, des boutiques en ligne, des banques et des médias, alors que le travail de sécurité sur le moteur repose sur un petit groupe de développeurs rémunérés par la fondation et quelques bénévoles. Elle note que les outils trouvent désormais des bugs plus vite, pour les défenseurs comme pour les attaquants, mais qu’ils ne savent pas choisir le bon correctif d’une décision de conception ancienne ni en peser les compromis de compatibilité. La fondation appelle les entreprises, les hébergeurs, les plateformes cloud et les institutions publiques qui dépendent de PHP à la financer de façon durable.
La page Services décrit les automatisations IA proposées par DjeremIA.