MtoM Mag - Le journal de l'MtoM.

Le projet PHP a corrigé deux vulnérabilités critiques (CVE-2026-109618 et CVE-2026-109619), toutes deux notées 9,2 sur 10 selon le standard de notation CVSS 4.0. Elles peuvent permettre à un attaquant de prendre la main sur un serveur web pour y exécuter du code, sans avoir besoin d’identifiants.

L’enjeu est de taille : PHP est le langage qui fait tourner une grande partie des sites web, soit environ 75 % de l’Internet public selon Checkmarx Zero. Une faille critique dans PHP expose donc potentiellement un très grand nombre de serveurs.

24 heures de confusion

Dans une analyse publiée le même jour, l’équipe de recherche Checkmarx Zero retrace la chronologie de l’alerte et fait le tri entre informations confirmées et fausses informations.

Le 20 octobre, le projet PHP avait prévenu ses utilisateurs qu’une mise à jour de sécurité urgente arrivait. Dans les heures qui ont suivi, avant même la publication du correctif, des codes présentés comme des exploits (programmes conçus pour tirer parti d’une faille) et des solutions de contournement ont circulé en ligne. Selon les mainteneurs de PHP, ces solutions de contournement ne fonctionnent pas, et les exploits publics repérés jusqu’ici étaient incomplets ou défectueux.

Trois enseignements pour les équipes IT et sécurité

 Prévenir à l’avance peut profiter aux attaquants. Annoncer un correctif quelques heures avant sa sortie vise à laisser aux défenseurs le temps de se préparer. Mais avec les outils d’IA générative, qui accélèrent l’écriture d’exploits, cette annonce pourrait aussi donner une longueur d’avance aux attaquants.
 Les fausses informations vont plus vite que les défenseurs. En quelques heures, de fausses parades et des preuves de concept (PoC, codes de démonstration d’une faille) défectueuses se sont répandues en ligne.
 Les faux exploits sont un danger en soi. Un code présenté comme une preuve de concept peut en réalité contenir un logiciel malveillant. Le tester sans vérification revient à prendre un risque supplémentaire.

Une exposition difficile à repérer

Autre difficulté soulignée par l’analyse : les outils qui recensent habituellement les composants d’une application (analyse de composition logicielle, ou SCA, et nomenclatures logicielles, ou SBOM) ne détectent pas cette exposition, car PHP est ici installé comme un composant du système d’exploitation. Pour savoir quelles versions tournent sur leurs serveurs, les équipes doivent passer par des scanners d’hôtes, des inventaires de paquets ou la commande php -v.

Que faire ?

Le seul correctif complet, selon le projet PHP, est de passer à l’une des versions publiées le 21 octobre 2026 : PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35.

Les versions antérieures à PHP 8.2 ne sont plus maintenues et ne recevront pas de correctif officiel. Certains fournisseurs peuvent toutefois proposer leurs propres correctifs adaptés à ces anciennes versions (backports).

À ce stade, l’analyse de Checkmarx Zero ne fait état d’aucune exploitation active de ces failles.

Le rôle de Checkmarx Zero

Checkmarx Zero n’a pas découvert ces vulnérabilités. Son analyse porte sur la façon dont l’écosystème a réagi : ce qui est confirmé, ce qui ne l’est pas, et pourquoi les annonces anticipées de correctifs pourraient désormais aider les attaquants autant que les défenseurs, à l’heure où l’IA accélère le développement d’exploits.