if ( !emtpy($headline_subheadline ) ) : ?>
La Fondation PHP affirme que Chainguard a brisé un embargo convenu sur deux failles critiques, tandis que les fournisseurs signalent les tentatives d’exploitation avant leur divulgation publique. Le différend met en évidence la manière dont le développement d’exploits assisté par l’IA compresse les fenêtres de mise à jour des correctifs.
endif; ?>
Deux vulnérabilités critiques découvertes dans le langage de programmation PHP largement utilisé ont secoué les entreprises, et il faudra un certain temps pour en comprendre réellement les conséquences. Mais l’une des histoires les moins connues concerne la divulgation.
Selon la Fondation PHP, plusieurs organisations avaient accepté une publication coordonnée détaillant les failles critiques et les mesures d’atténuation, mais la société de cybersécurité Chainguard a rompu « unilatéralement » cet embargo. Cela a incité le projet PHP à publier ses correctifs plus tôt, mais a également permis aux attaquants d’étudier le correctif sous forme binaire et d’élaborer des preuves de concept (PoC) pour les exploits avant que les défenseurs n’aient la possibilité de mettre à jour leurs systèmes.
Mais certains, notamment AWS et Cloudflare, affirment que les exploits actifs ont commencé des heures, voire des jours, avant leur divulgation.
Selon certaines estimations, il y a eu depuis des millions de tentatives pour abuser des bogues de gravité 9,2, collectivement connus sous le nom de PHP2Shell. De nombreuses organisations, y compris des organismes gouvernementaux, ont réagi en mettant complètement leurs sites Web hors ligne.
« Franchement, l’histoire de la divulgation est plus intéressante que les bugs eux-mêmes », a déclaré Frank Dickson de Dickson Research. « Les embargos comptent. Celui-ci était presque impossible à respecter. »
La divulgation désordonnée
CVE-2026-109618 et CVE-2026-109619 pourraient permettre aux attaquants de lancer des attaques d’exécution de code à distance (RCE).
La Fondation PHP a reconnu que l’un de ses sous-traitants avait découvert les premiers signes du problème de manque de mémoire (MOO) derrière CVE-2026-109618 dès 2024, mais « aucun vecteur concret » n’a été trouvé, et d’autres problèmes ayant un « impact évident » ont éclipsé ses inquiétudes concernant la faille.
Des recherches approfondies sur le problème n’ont eu lieu que le 30 juillet 2026, après que la Fondation a intégré le projet PHP dans le programme Patch the Planet d’OpenAI. Des chercheurs de Californie, d’OpenAI et de Wiz de Google Cloud « ont clairement montré tout l’impact du problème du MOO » et le résoudre est devenu la priorité absolue.
Une fois que les chercheurs ont développé les correctifs, les distributeurs, y compris Chainguard, les ont reçus à l’avance afin que leurs utilisateurs puissent les mettre à jour « dès que les vulnérabilités étaient divulguées », a déclaré la Fondation. Il a fixé un embargo pour le 22 octobre à 14h00 UTC.
Cette divulgation coordonnée semblait bien fonctionner jusqu’à deux jours avant la levée de l’embargo, a expliqué la Fondation. Le 20 octobre, vers 15h00 UTC, les deux identifiants CVE ont commencé à circuler en ligne, même si aucun détail technique n’a été divulgué. Le projet PHP a avancé sa pré-annonce et l’a publiée à 19h30 UTC. Il a également déplacé la publication des correctifs du 22 octobre à 14h00 UTC au 21 octobre à 14h00 UTC.
L’avancement du calendrier de l’annonce préalable a conduit la société de cybersécurité Calif à publier « par erreur » une vidéo montrant un exploit PoC contre de nombreuses cibles. Il a également révélé des détails « limités » sur les failles. La vidéo a ensuite été supprimée, mais elle avait déjà commencé à circuler sur les réseaux sociaux.
Puis, le 21 octobre à 07h41 UTC, Chainguard a publié des images construites contenant le correctif. C’était environ six heures avant l’heure de publication convenue et « cela n’a pas tenu compte des semaines de travail de nombreuses parties en vue d’une divulgation coordonnée », a affirmé la Fondation PHP.
Dix-huit heures après la pré-version, le 21 octobre à 14h00 UTC, le projet PHP a rendu les correctifs publics. C’était 24 heures plus tôt que prévu initialement.
La Fondation a expliqué que les distributeurs étaient encore en train de conditionner le correctif, donc le publier plus tôt aurait laissé de nombreux utilisateurs sans moyen simple de mise à jour. « Avancer la publication d’un jour était le meilleur compromis entre agir rapidement, donner aux gens le temps de se préparer et s’assurer que tout le monde disposait d’un chemin de mise à jour simple lorsque les vulnérabilités étaient révélées. »
Le PDG de Chainguard, Dan Lorenc, a riposté aux critiques de la Fondation, affirmant qu’il avait suivi les directives du processus de divulgation pour publier après avoir découvert des preuves d’exploits actifs. « Cette décision était basée sur la facilité avec laquelle nous avons pu découvrir indépendamment la vulnérabilité et créer un exploit, sur la quantité d’informations déjà disponibles sur les vulnérabilités et les correctifs à venir, et sur les preuves partagées sur les exploits actifs dans la nature », a-t-il écrit dans un article sur LinkedIn.
En effet, le PDG de Cloudflare, Matthew Prince, a déclaré que son entreprise avait vu « des milliers » de tentatives d’exploitation de PHP2Shell 10 heures avant l’annonce publique. Cela est passé à « des dizaines de milliers dans les 45 minutes qui ont suivi l’annonce, des centaines de milliers dans les deux heures et des millions maintenant », a-t-il déclaré.
Et AWS affirme qu’au moins une tentative d’exploitation a eu lieu quatre jours avant la divulgation publique, le 17 octobre. Cette tentative provenait d’une adresse IP associée à un réseau d’anonymisation commercial, selon AWS CISO CJ Moses, indiquant qu’elle a été menée par un acteur menaçant, « bien qu’il reste difficile de savoir comment l’acteur a acquis les informations d’exploitation avant leur divulgation ».
Garder des secrets est difficile, mais ça reste le bon modèle
Bien qu’il semble y avoir eu diverses fuites, cela n’excuse pas Chainguard, a déclaré Dickson. La société a reçu le correctif tôt pour une raison, et sa publication précoce a donné aux attaquants un correctif à étudier pendant que tous les autres utilisateurs PHP attendaient.
« Un embargo protège les défenseurs uniquement jusqu’à ce que quelqu’un d’autre trouve le même bug », a-t-il déclaré, ajoutant que plus un correctif reste longtemps dans la file d’attente, plus la fenêtre de protection est courte. « Chaque groupe qui reçoit le patch plus tôt est un moyen supplémentaire pour que le secret s’échappe. »
Cela dit, la divulgation coordonnée reste le bon modèle ; il faut juste qu’il soit plus serré, a-t-il dit. Cela signifie des fenêtres plus courtes, moins de premiers destinataires et une compréhension claire que le correctif lui-même est le secret. « Un patch est une carte au trésor », a-t-il souligné.
En fin de compte, « garder des secrets est difficile », a déclaré David Shipley, PDG de Beauceron Security. « Plus il y a de gens qui le savent, plus le délai est long, plus il y a de chances que quelque chose fuit. »
C’est un énorme problème maintenant, a-t-il noté, car avec des agents IA et un peu de connaissance du fonctionnement d’une faille, « vous pouvez pointer un outil vers un logiciel et le comprendre ».
La responsabilité à l’ère de l’IA
L’effet de PHP2Shell se fera sentir pendant des années, tout comme celui de Log4J, a déclaré Shipley. Après être apparu dans les plus grandes présences en ligne, il se frayera un chemin jusqu’aux appareils IoT et autres.
Les défenseurs doivent connaître leur parc logiciel et leurs dépendances ; une nomenclature logicielle (SBOM) peut vous y aider. « Ce n’est pas une solution facile, mais c’est le simple travail de l’informatique et de la cybersécurité qui peut faire ou défaire la réponse », a déclaré Shipley.
Les entreprises ont également besoin de la responsabilité du fabricant de produits et de la responsabilité du fournisseur d’outils d’IA. « La vulnérabilité n’est pas due à l’IA », a-t-il déclaré. Depuis des décennies, les incitations du marché consistent à expédier les produits, à les réparer, à agir rapidement et à les casser.
Les entreprises qui ont donné la priorité au transport maritime plus lentement mais de manière plus sûre ont été frappées sur le marché par des entreprises qui ne l’ont pas fait et « ont lancé de nouvelles et brillantes choses tout en créant une dette technologique et de sécurité », a déclaré Shipley. Les incitations doivent changer, surtout à l’ère de l’IA.
Et, selon Dickson, les équipes de sécurité doivent comprendre où se trouve chaque environnement d’exécution, y compris ceux des fournisseurs internes. Décidez à l’avance qui a le pouvoir de mettre un service hors ligne, afin que cet appel soit « passé dans le calme plutôt que débattu en cas de crise ». Investissez dans des détections basées sur un comportement, comme l’exécution inattendue d’un processus ou l’ajout de nouveaux fichiers sur un serveur Web, car la signature d’un CVE spécifique n’existera pas au jour zéro.
« Chainguard a sauté le pas, mais la course avait déjà commencé », a déclaré Dickson. « Les embargos valent toujours la peine d’être respectés. Mais les RSSI devraient planifier le début de l’exploitation avant l’avis, car c’est désormais le cas. »
