Identifiées dès 2024, mais corrigées seulement le 21 octobre 2026, deux vulnérabilités majeures du moteur PHP exposent potentiellement de nombreuses applications web. Leur histoire révèle les difficultés de maintenance d’un composant open source largement utilisé. Pour les DSI, l’urgence est désormais d’identifier les systèmes concernés, y compris ceux qui échappent à leur contrôle direct.
Tout commence en 2024, à l’occasion d’un audit de sécurité du moteur PHP, réalisé par Quarkslab sous la coordination de l’Open Source Technology Improvement Fund (OSTIF). Un développeur du projet découvre une anomalie dans la gestion de la mémoire de PHP : dans certaines circonstances, une erreur d’allocation peut laisser des structures internes dans un état incohérent.
Les conséquences restent alors incertaines. Une exploitation malveillante paraît envisageable, mais aucune preuve concrète n’est apportée. Les développeurs étudient plusieurs solutions, sans parvenir à un correctif satisfaisant.
Deux ans plus tard, ce problème est à l’origine de deux vulnérabilités critiques, CVE-2026-109618 et CVE-2026-109619, regroupées sous le nom PHP2Shell. Corrigées le 21 octobre 2026 et évaluées chacune à 9,2 sur 10 selon CVSS v4.0, elles peuvent permettre l’exécution de code à distance sans authentification préalable, sous certaines conditions.
La menace est d’envergure. En effet, PHP est au cœur de nombreux sites WordPress, Drupal et Joomla, mais aussi d’applications métiers, d’intranets et de portails développés spécifiquement pour les entreprises.
Pourquoi a-t-il fallu deux ans pour corriger ces failles ?
Dans un communiqué publié le 21 octobre, la PHP Foundation reconnaît les difficultés rencontrées par ses équipes depuis 2024. Plusieurs solutions avaient été envisagées, mais chacune présentait des risques : incompatibilités avec des applications existantes, modifications importantes des extensions tierces ou apparition de nouvelles possibilités de déni de service.
À ces obstacles techniques s’ajoutaient des problèmes organisationnels. Les décisions de sécurité étaient prises par consensus, ce qui compliquait les arbitrages. Surtout, peu de développeurs disposaient de l’expertise nécessaire pour intervenir sur les mécanismes internes de PHP.
Les travaux ont ainsi été interrompus, puis relancés à plusieurs reprises, sans aboutir. La PHP Foundation reconnaît aujourd’hui une « défaillance structurelle » liée à ses processus de décision et à l’insuffisance de ses ressources.
La situation change à l’été 2026. Le 11 août, un chercheur de la société Calif, dans le cadre du programme Patch the Planet auquel participe OpenAI, démontre une possibilité d’exécution de code à distance fondée sur le problème identifié en 2024. Quelques jours plus tard, Wiz Research démontrent une exécution de code sans authentification sur Drupal puis sur WordPress. Les résultats sont transmis à l’équipe de sécurité PHP le 24 août. OpenAI complète avec de nouveaux scénarios d’attaque en septembre.
Deux failles critiques dans le moteur PHP
Les deux vulnérabilités concernent des mécanismes distincts du moteur PHP. La première, CVE-2026-109618, intervient lorsqu’une erreur d’épuisement de mémoire laisse certaines structures partiellement initialisées. Leur traitement ultérieur peut entraîner une corruption mémoire. La seconde, CVE-2026-109619, repose sur la réutilisation de références vers des zones mémoire déjà libérées, un mécanisme connu sous le nom de use-after-free.
Dans certaines configurations, ces défauts peuvent être exploités pour exécuter du code à distance avec les droits du processus PHP. Wiz a également démontré la possibilité de lire des informations présentes dans la mémoire des processus, comme des mots de passe, des jetons d’authentification ou des clés d’API.
Les recherches ont bénéficié de l’apport de modèles d’intelligence artificielle, utilisés notamment pour analyser les mécanismes mémoire et élaborer des chaînes d’exploitation. Sans remplacer l’expertise humaine, ces outils ont facilité des investigations particulièrement complexes.
Une publication précipitée des correctifs
La publication des correctifs était initialement prévue le 22 octobre 2026. Mais, dès le 20 octobre, les références des vulnérabilités commencent à circuler sur Internet. Une vidéo de démonstration est également publiée par erreur par Calif, avant d’être retirée. Face à ces fuites, les responsables de PHP avancent de 24 heures la publication des correctifs.
Le 21 octobre, les nouvelles versions sont diffusées. Mais certaines tentatives d’exploitation ont déjà commencé. Amazon Threat Intelligence indique avoir détecté, grâce à son réseau de honeypots MadPot, une première tentative dès le 17 octobre, quatre jours avant la divulgation officielle. D’autres requêtes suspectes ont été observées avant et après la sortie des correctifs.
Ces observations ne prouvent pas que des serveurs de production ont effectivement été compromis. Elles montrent néanmoins que des attaquants disposaient d’informations exploitables avant la publication officielle.
Pour les équipes de sécurité, la conséquence est importante : les investigations doivent pouvoir remonter à une période antérieure à la diffusion des correctifs.
Pour les DSI, une exposition difficile à mesurer
Pour les DSI, la première difficulté consiste à identifier l’ensemble des systèmes s’appuyant PHP. Au-delà des sites internet, le langage peut être présent dans des intranets, des extranets, des applications internes, des outils d’administration ou des logiciels fournis par des éditeurs tiers.
Les entreprises doivent non seulement appliquer les correctifs à des systèmes qu’elles administrent directement, mais également vérifier que leurs hébergeurs, intégrateurs et fournisseurs de logiciels prennent les mesures nécessaires.
L’exemple de Plesk illustre cette difficulté. L’éditeur a dû publier des correctifs pour plusieurs versions de PHP distribuées avec sa plateforme, ainsi que pour le moteur PHP de sa propre interface d’administration.
Des correctifs à déployer sans attendre
Les responsables du projet PHP ont publié les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35 pour corriger les vulnérabilités. Des correctifs spécifiques ont également été préparés pour certaines branches anciennes, notamment PHP 7.4, 8.0 et 8.1. Pour les DSI, la priorité est de traiter en premier les systèmes accessibles depuis Internet.
Les entreprises qui utilisent des versions en fin de support doivent vérifier la disponibilité de correctifs, et leur déploiement effectif, ou envisager une migration vers une version maintenue.
Autre impératif : elles doivent rechercher d’éventuelles compromissions antérieures. L’application d’un correctif empêche de nouvelles exploitations de la faille, mais ne supprime pas les conséquences d’une attaque déjà réussie. L’analyse des journaux des serveurs web, des erreurs des processus PHP et des comportements inhabituels sur les systèmes concernés doit donc accompagner la campagne de mise à jour.
Enfin, PHP2Shell pose la question des délais de réaction. Lorsque des tentatives d’exploitation précèdent la publication officielle des correctifs, les procédures classiques de gestion des vulnérabilités, parfois organisées sur plusieurs jours ou semaines, montrent leurs limites.
Une affaire révélatrice des fragilités de l’open source
Au-delà de l’urgence opérationnelle, PHP2Shell soulève une question de fond : comment garantir la sécurité de composants logiciels utilisés à grande échelle lorsque leur maintenance repose sur un nombre limité de spécialistes ?
La PHP Foundation a annoncé plusieurs évolutions de son organisation, notamment le renforcement des ressources consacrées à la sécurité et la modification de ses processus de décision.
Mais l’affaire met aussi en évidence un décalage croissant. Les outils d’analyse qui reposent sur l’intelligence artificielle accélèrent la découverte des vulnérabilités. La conception de correctifs robustes, en revanche, exige toujours du temps, des compétences parfois rares et des arbitrages complexes entre sécurité et compatibilité.
Ces vulnérabilités rappellent qu’une partie de la sécurité des systèmes d’information dépend de composants que les DSI ne développent pas, ne maîtrisent pas toujours et dont ils connaissent parfois mal la présence dans leurs infrastructures.
La capacité à identifier ces dépendances et à déployer rapidement les correctifs devient importante pour assurer la sécurité des applications.
