← tous les articles
phpphp2shelldivulgation-responsablegouvernancesécurité-logiciellecve-2026-109618cve-2026-109619· 7 min de lecture

php2shell-contexte

PHP2Shell, l'autre histoire : comment une faille vieille de deux ans a fini en urgence mondiale

Lux

PHP2Shell, l'autre histoire : comment une faille vieille de deux ans a fini en urgence mondiale

En bref

  • Le défaut à l'origine de PHP2Shell (CVE-2026-109618 / -109619) avait été entrevu dès 2024, lors d'un audit externe. Le correctif a mis des mois à sortir, faute de consensus et de moyens (PHP Foundation).
  • La divulgation coordonnée, prévue pour le 21 octobre 2026, a été devancée par des fuites et par la publication accidentelle d'une démonstration (PHP Foundation, CERT-FR).
  • Plusieurs entreprises — Wiz, OpenAI, Calif — ont communiqué au même moment, relançant un débat sur la place du privé et du marketing dans la recherche de failles.
  • Pour le mécanisme technique, voir l'article compagnon « PHP2Shell : comment une erreur de mémoire mène au RCE ».

Cet article ne décrit pas comment la faille fonctionne (c'est l'objet de l'article technique), mais comment on en est arrivé là : la trajectoire du bug, la gestion de la crise, et ce qu'elle révèle de l'écosystème.

Un bug qui dormait depuis 2024

L'histoire ne commence pas en octobre 2026. Selon la PHP Foundation, les premiers signes du problème d'« out of memory » (OOM) à l'origine de la faille remontent à un audit externe mené en 2024 par Quarkslab, organisé via l'OSTIF et financé par la Sovereign Tech Agency. Le défaut avait été repéré en marge de la correction d'un autre problème. À l'époque, un exploit avait été théorisé, mais aucun vecteur concret n'avait été trouvé (PHP Foundation).

Autrement dit : la pièce défectueuse était connue, sans qu'on sache encore qu'elle pouvait ouvrir la porte en grand.

Pourquoi le correctif a traîné

C'est le point le plus instructif pour qui s'intéresse à la sécurité logicielle. La PHP Foundation le reconnaît elle-même : le correctif a stagné pendant des mois. Plusieurs approches concurrentes étaient possibles, chacune avec ses compromis, et le processus de décision de l'équipe sécurité — fondé sur le consensus — n'a pas réussi à trancher. La Foundation parle d'un échec structurel, lié à la fois au mode de décision et à un manque de ressources (PHP Foundation).

PHP est un logiciel qui fait tourner une part majeure du web, maintenu par une équipe réduite et en grande partie bénévole. C'est le paradoxe classique de l'infrastructure open source critique : omniprésente, mais sous-financée.

Ce que PHP change en réponse

La crise a servi d'électrochoc. La Foundation annonce plusieurs mesures (PHP Foundation) :

  • une Ecosystem Security Team, créée en mai 2026, pour épauler l'équipe sécurité sur le tri, la coordination et le durcissement ;
  • des renforts humains : Volker Dusch comme « AI Security Engineer in Residence », Alexandre Daubois (juillet 2026) pour le traitement des rapports, Daniel Scherzer (septembre 2026) pour le durcissement ;
  • un passage vers des décisions à la majorité plutôt qu'au consensus strict, et l'implication plus précoce de la direction sur les vulnérabilités à arbitrages difficiles ;
  • un recours accru à l'outillage, notamment des builds avec sanitizers et des environnements de reproduction alignés sur l'intégration continue.

Depuis le 1er juillet 2026, l'équipe a publié 15 CVE et traité plus de 100 rapports invalides, en doublon ou non reproductibles (PHP Foundation) — un ordre de grandeur qui illustre la charge.

L'IA entre dans la boucle

Fait marquant : plusieurs des signalements qui ont fait de ce bug une priorité absolue sont venus d'outils de recherche assistés par IA.

  • Wiz indique avoir découvert la première vulnérabilité le 19 août 2026 à l'aide d'outils assistés par IA (Wiz).
  • La PHP Foundation mentionne l'usage de l'outil « Daybreak Red » d'OpenAI pour valider rapports et exploits, après un scan antérieur mené avec Alpha-Omega (PHP Foundation).
  • Le 11 août 2026, l'entreprise Calif a signalé un RCE au même point de départ ; le 18 septembre, OpenAI a remonté d'autres vecteurs, ayant aussi identifié indépendamment la même cause racine (PHP Foundation).

Trois acteurs différents convergeant sur la même faille en quelques semaines, c'est à la fois rassurant (la recherche s'industrialise) et vertigineux (la fenêtre d'exposition se referme vite, mais la pression monte d'autant).

La divulgation qui a déraillé

La divulgation coordonnée visait le 21 octobre 2026, 14:00 UTC. Elle ne s'est pas passée comme prévu (PHP Foundation, CERT-FR) :

  • 20 octobre, ~15:00 UTC : les deux identifiants CVE circulent déjà sur forums et réseaux sociaux, avec une heure de publication erronée et un score gonflé à 10,0 (le vrai score est 9,2). Aucun détail technique ne fuite à ce stade.
  • 20 octobre, 19:30 UTC : PHP publie sa pré-annonce en avance pour reprendre la main. La date de sortie est avancée du 22 au 21 octobre, les distributeurs étant encore en train d'empaqueter le correctif.
  • 20 octobre, ~20:00 UTC : Calif publie par erreur une vidéo montrant sa démonstration contre plusieurs cibles. Des copies se diffusent et accélèrent le développement de preuves de concept.
  • 21 octobre, 07:41 UTC : Chainguard rompt l'embargo en publiant des images déjà corrigées, plus de six heures avant la sortie coordonnée.
  • 21 octobre, 13:52 UTC : PHP publie les correctifs, un peu avant l'heure annoncée.

Dès avant le correctif, Patchstack recevait de ses hébergeurs partenaires des signalements d'exploitation active (07:34 UTC), et Cloudflare déployait des règles WAF d'urgence (Patchstack).

timeline
    title Fenêtre critique du 20-21 octobre 2026 (UTC)
    20 oct ~15h : Fuite des CVE (score erroné 10,0)
    20 oct 19h30 : Pre-annonce avancee par PHP
    20 oct ~20h : Video PoC publiee par erreur (Calif)
    21 oct 07h34 : Exploitation active signalee (Patchstack)
    21 oct 07h41 : Embargo rompu (Chainguard)
    21 oct 13h52 : Correctifs publies par PHP

Branle-bas de combat mondial

La criticité annoncée a déclenché une réaction en chaîne des autorités et des grands sites :

  • Le CERT-UE (avis 2026-018) recommande de « se préparer à la mise à jour immédiate des systèmes affectés » et, à défaut, « d'isoler les applications exposées à Internet des réseaux publics jusqu'à la disponibilité d'un correctif » (CERT-UE).
  • Le CERT-FR (CERTFR-2026-ALE-014) recommande d'« isoler les équipements affectés puis de procéder à la migration vers une version maintenue » dès publication du correctif, et rappelle que « seule l'application de la mise à jour permet de vous prémunir » (CERT-FR).
  • Cloudflare, souvent placé en frontal des sites, ajoute en urgence des règles WAF contre des « schémas de requêtes anormales » ; son directeur technique Dane Knecht évoque des vecteurs d'attaque précoces déjà observés (Cloudflare, Ars Technica).
  • Plusieurs grands sites se mettent hors ligne par précaution pendant l'embargo, selon le média Next : 4chan, DeviantArt, la CNIL française, la Seconde Chambre des États généraux des Pays-Bas, ou encore des services publics finlandais (Next).

Une vidéo non confirmée présentait un outil nommé « PHP2Shell » exploitant les deux failles contre des logiciels majeurs reposant sur PHP (WordPress, MediaWiki, phpBB, Magento, Joomla, Laravel, Symfony, Drupal, Nextcloud) (Ars Technica). C'est de là que vient le nom.

Le débat : recherche de sécurité ou vitrine commerciale ?

Un point mérite d'être posé honnêtement, en séparant les faits de l'interprétation.

Les faits. Trois entreprises privées — Wiz, Calif et OpenAI — ont publié leurs analyses au même moment que la divulgation. Wiz a forgé le nom accrocheur « PHP2Shell » et met en avant une statistique marquante (« 70 % d'Internet ») ainsi que son propre capteur de détection (Wiz). OpenAI a profité de l'occasion pour présenter son programme Patch the Planet (OpenAI). Calif a mené un audit de PHP sous ce même programme à partir du 30 juillet 2026 (PHP Foundation).

L'interprétation. Certains y voient une stratégie de communication coordonnée à visée commerciale, chaque acteur mettant en avant ses solutions. C'est une lecture défendable, mais c'est une opinion, pas un fait établi — la version française de Wikipédia la signale d'ailleurs comme une interprétation personnelle à sourcer.

L'autre lecture. Une divulgation coordonnée implique par nature que tout le monde publie en même temps, à la levée de l'embargo. Et ces mêmes entreprises ont fourni un travail de recherche réel, financé des audits et aidé à colmater une faille critique d'un commun bénévole. Les deux choses peuvent être vraies à la fois : contribution utile et opération de visibilité.

Ce qui est sûr, c'est que PHP2Shell illustre un basculement : la sécurité des infrastructures open source dépend de plus en plus d'acteurs privés bien dotés et d'outils d'IA, là où le mainteneur historique peinait, faute de moyens, à corriger un bug connu depuis deux ans. La vraie question de fond n'est pas « qui en a profité », mais « comment financer durablement la maintenance de ce dont dépend tout le web ».

Sources

Discussion

Markdown supporté · Ctrl+Entrée pour publierSe connecter pour publier

chargement de la discussion…