« L’information de sécurité météorologique sera diffusée sur nos réseaux sociaux en attendant le rétablissement de nos […] services. »

Mercredi 21 octobre, Météo France faisait cette annonce. Il venait de mettre hors ligne son site de prévision et son site de Vigilance. Motif : la présence de deux vulnérabilités « critiques » touchant PHP.

Les sites des préfectures ont subi le même traitement. La Ville de Paris, entre autres, a également dû en débrancher provisoirement. Comme la CNIL.

L’incident ne s’est évidemment pas limité aux organismes publics. Orange, par exemple, a déconnecté « quelques sites web, services et applications au sein de plusieurs filiales et entités ».

PHP signale une troisième vulnérabilité

Aux Pays-Bas, la Tweede Kamer, chambre basse du Parlement, a elle aussi dû couper temporairement son site web. Le CERT national a fait de même. Il dit désormais enquêter sur « de premiers signaux d’exploitation réussie » des deux vulnérabilités. La situation pourrait, ajoute-t-il, s’aggraver rapidement, car des PoC sont publics.

Eye Security le reconnaît, mais ne pense pas qu’un exploit générique soit possible. Cela n’écarte pas, précise-t-il, le risque d’attaques ciblées. Mais, à l’en croire, pas d’apocalypse à prévoir.

L’ANSSI allemande (BSI) est moins affirmative. Elle assure cependant ne pas avoir connaissance d’une exploitation « généralisée et réussie ». Malgré les rumeurs, précise-t-elle, les correctifs sont efficaces.

Le projet PHP vient de mettre un bémol : même avec les versions patchées, un cas de RCE peut se présenter. Un identifiant spécifique lui a été attribué (CVE-2026-115560). Il exige toutefois une combinaison « inhabituelle » de configuration et de code applicatif engendrant une discordance du gestionnaire de session. Dans ce contexte, il n’est pas prévu de correctif hors du cycle régulier de release.

Les correctifs PHP ont ruisselé dans les distributions Linux

Les correctifs actuels comprennent des versions patchées de PHP 8.2, 8.3, 8.4 et 8.5, ainsi qu’un rétroportage minimal pour trois versions plus anciennes (7.4, 8.0 et 8.1).

Canonical a patché la version actuelle d’Ubuntu (26.10), qui utilise PHP 8.5. Il a fait de même avec les trois dernières LTS (26.04, 24.04 et 22.04, qui utilisent respectivement PHP 8.5, 8.3 et 8.1). Pour les abonnés Ubuntu Pro, il a remonté quatre versions de plus : 20.04 (PHP 7.4), 18.04 (7.2), 16.04 (7.0) et 14.04 (PHP 5).

Le projet Debian a intégré les correctifs pour PHP 8.2 et 8.4, respectivement dans les dépôts de Bookworm et de Trixie. Freexian a rétroporté sur Sketch (PHP 7.0), Buster (7.3) et Bullseye (7.4).

Chez Red Hat, hors support étendu, c’est corrigé sur RHEL 8 (PHP 8.2 & 7.4), RHEL 9 (8.3 & 8.2) et RHEL 10 (8.4).

SUSE est remonté jusqu’à PHP 7.4, pour openSUSE 15.6/15.7 et SLES 12/15.

70 % du web menacé ? La surface d’attaque en chiffres

Les deux failles résident dans le cœur de PHP : le moteur Zend, qui compile le code source en bytecode, l’exécute et administre tout ce dont le langage a besoin. Leur positionnement dans la pile d’exécution renforce leur criticité. Il y a en effet possibilité de les enclencher avant même l’initialisation des extensions et la compilation de la moindre ligne de code applicatif.

Dans ces conditions, on voit beaucoup circuler une statistique : 70 % du web serait concerné. La source, quand elle est donnée, pointe souvent vers W3Techs. Cette plate-forme analyse les parts de marché des technologies web. Parmi les sites dont elle connaît le langage de programmation serveur, près de 70 % utilisent effectivement PHP.

Branche

Version

Part

Répartition

PHP 8

Total : 45,3 %

PHP 8.6

< 0,1 %

PHP 8.5

2,0 %

PHP 8.4

5,5 %

PHP 8.3

15,8 %

PHP 8.2

12,5 %

PHP 8.1

6,8 %

PHP 8.0

2,6 %

PHP 7

Total : 18,6 %

PHP 7.9

< 0,1 %

PHP 7.5

< 0,1 %

PHP 7.4

13,7 %

PHP 7.3

2,0 %

PHP 7.2

1,6 %

PHP 7.1

0,7 %

PHP 7.0

0,7 %

PHP 5

Total : 5,3 %

PHP 5.6

2,9 %

PHP 5.5

0,4 %

PHP 5.4

0,8 %

PHP 5.3

0,8 %

PHP 5.2

0,4 %

PHP 5.1

< 0,1 %

PHP 5.0

< 0,1 %

PHP 4

Total : < 0,1 %

Toutes versions confondues

< 0,1 %

Total des serveurs sous PHP

≈ 69,2 %

PHP 8, 7, 5 et 4

Serveurs n’utilisant pas PHP

≈ 30,8 %

Autres technologies / langages

Où l’on reparle du botnet Mirai

Le 20 octobre, soit la veille de la publication des correctifs, un PoC a fuité. En conséquence, le projet PHP a émis une alerte anticipée.

AWS a identifié des tentatives d’attaque après cette fuite. Il déclare cependant en avoir repéré une dès le 17 octobre. Elle provenait d’une adresse IP associée à un « réseau commercial d’anonymisation ».

Ellio a aussi observé des attaques avant la publication des correctifs. La première s’est manifestement appuyée sur le PoC ayant filtré. Dans son user-agent figuraient la chaîne « php2shell » et l’identifiant de la première CVE (109618). Elle contenait aussi le champ de suivi de session de téléchargement propre à l’autre vulnérabilité (109619).

Peu après la publication des correctifs, des tentatives d’attaque ont réutilisé les informations du bulletin de sécurité associé. Elles se sont ainsi concentrées sur un autre vecteur que les sessions d’upload. En l’occurrence, celui qui exploite l’épuisement de mémoire. Ellio a ainsi retrouvé des requêtes caractérisées par des dizaines de niveaux d’imbrication et des corps relativement massifs (plusieurs centaines de kilo-octets). Il a vu passer diverses charges utiles, allant d’un RAT écrit en Go à un webshell IIS, en passant par… une version du botnet IoT Mirai compilée pour les serveurs 64 bits. Celle-ci pouvait, entre autres, ouvrir un shell interactif sur un pseudo-terminal.

Deux vulnérabilités, beaucoup de chemins d’attaque

Pour mémoire, la première faille, introduite avec PHP 7.3 (décembre 2018), cible l’implémentation de la table de hachage. L’idée est de transmettre une requête POST suffisamment surdimensionnée – mais restant en apparence dans les limites de PHP – pour provoquer un dépassement de mémoire (OOM, out-of-memory). Lorsque cette condition survient, Zend lève une erreur fatale. L’exécution s’arrête… et laisse des octets résiduels. Des données partiellement initialisées que le nettoyage de la requête peut ensuite traiter comme si elles étaient valides, ouvrant la voir à l’exécution de code arbitraire.

Tout cela ne nécessite qu’une requête : celle-ci corrompt les données et la charge utile s’exécute lors du nettoyage. La deuxième faille implique le même mécanisme de réutilisation de données corrompues, mais elle est moins « autonome ». Il lui faut une étape d’empoisonnement, puis une étape de déclenchement ciblant le même worker. En contrepartie, elle atteint un plus grand ensemble d’états internes. Les deux chemins d’attaque reconnus se trouvent dans des lignes de code respectivement introduites avec PHP 7.1 et 5.4. Les données malveillantes sont désérialisées avant l’exécution du moindre code applicatif. Aucune logique d’application ne peut donc s’opposer et chaque point de terminaison PHP (formulaires statiques, routes d’authentification, sondes de disponibilité…) constitue une surface d’attaque.

En cas d’impossibilité de déployer les correctifs, la principale mesure d’atténuation de la première vulnérabilité consiste à définir la valeur memory_limit = -1. Au niveau du WAF ou de la périphérie, on peut bloquer les requêtes qui dépassent un certain seuil de taille.

Cela n’est pas possible pour la deuxième vulnérabilité, où les requêtes pèsent typiquement quelques centaines d’octets. Ici, la meilleure parade à défaut de correctif est de désactiver le suivi des sessions d’upload. De nombreux CERT européens – exemple en Estonie – le confirment.

Les mesures d’atténuation valables pour la deuxième vulnérabilité le sont aussi pour la CVE-2026-115560.

De la skill Codex aux règles Zeek, la défense s’organise

Cloudflare n’a pas attendu la publication des correctifs pour déployer des règles sur son WAF, ayant détecté des attaques sur ses clients. Selon son CEO, elles se sont comptées « en milliers » dans les heures ayant précédé l’annonce et « en dizaines de milliers » dans les dernières minutes.

OpenAI a pour sa part publié un vérificateur de version PHP sous forme de skill Codex. Tandis que Corelight a mis à disposition des packs de détection pour Zeek et Suricata.

Le pack Suricata contient trois règles. L’une cible « un marqueur unique et rare » dans les corps des requêtes HTTP POST. Les autres détectent les versions de PHP en examinant la bannière dans les en-têtes de réponse ainsi que dans le contenu HTML standard produit par phpinfo().

Le pack Zeek regroupe 9 types d’alertes parmi lesquelles :

Nom de champ anormalement long

Répétition excessive d’un pattern d’en-tête MIME dans une requête multipart

Représentation anormalement volumineuse d’un jeton d’entier sérialisé

Transactions HTTP suspectes corrélées et associées à une même session au sein d’une fenêtre temporelle délimitée

À qui le « killer PoC » ?

Le CERT du Luxembourg recommande de porter une attention particulière à :

Sites, API et applications exposés à Internet

Environnements d’hébergement mutualisé et multilocataire s’appuyant sur des workers persistants

CMS, plates-formes e-commerce et interfaces d’administration

Conteneurs, images de VM, appliances et panneaux de contrôle d’hébergement web qui embarquent leur propre runtime PHP

Son homologue tchèque liste quelques signaux à surveiller sur les serveurs affectés. Parmi eux :

Requêtes multipart inhabituelles suivies d’erreurs liées à une limite de mémoire ou de réponses HTTP 500 à répétition

Cookies PHPSESSID anormalement volumineux dans les réponses

Redémarrages inexpliqués des processus PHP

En miroir, AWS suggère d’interdire les requêtes multipart au niveau du front-end pour les applications qui ne nécessitent pas de téléverser des fichiers.

Abstract donne le même conseil. Et communique lui aussi des indicateurs à suivre. Dont les erreurs fatales contenant la mention Unknown on line 0 – cela indique un épuisement de mémoire survenu en amont de l’exécution. Il annonce par ailleurs avoir aussi reproduit une RCE, en deux requêtes, à partir de la CVE-2026-109619, sur un hôte PHP 8.2 « entièrement corrigé ». D’après lui, le patch a résolu le problème des consommateurs d’état obsolète… mais pas du producteur. Le mécanisme de suivi des uploads écrit toujours le nom de fichier sans assainissement, sous un identifiant que l’attaquant fixe via un simple champ de formulaire. Cela plaide d’autant plus pour une désactivation de ce mécanisme.

watchTower déclare quant à lui avoir pu reproduire la faille CVE-2026-109618. CrowdStrike revendique également un PoC fonctionnel qui demeure fiable malgré les redémarrages de workers. Et qui, sur Arm, contourne l’ASLR (randomisation de l’espace d’adressage) uniquement à l’aide de requêtes HTTP.

Même revendication de PoC fonctionnels chez JFrog. Lequel signale toutefois qu’il en circule des faux, « à visée de canular […], diffusés par des acteurs malveillants qui profitent de la confusion ».

ESET a observé des tentatives d’exploitation, mais « encore limitées ». Il évoque des activités de balayage, mais « aucune compromission généralisée ou significative à ce stade ».

Des vulnérabilités de plus pour les équipements de bordure

De nombreux CERT le soulignent : attention aux passerelles et autres équipements de bordure.

Chez F5, le BIG-IP est affecté, à deux niveaux : l’utilitaire de configuration du plan de contrôle et le data plane APM/SSLO. Pas de correctif pour le moment.

Chez Citrix, le portail de gestion NetScaler utilise PHP sur plusieurs interfaces. L’entreprise prévoit des correctifs pour le 27 octobre.

Cisco liste pour le moment deux familles de produits vulnérables. Pour les équipements URWB (Ultra-Reliable Wireless Backhaul), un fix est prévu en février 2027. Pour les passerelles Expressway et Expressway Select, la date reste à déterminer.

Sophos recense un composant vulnérable : le portail MyUTM. Il s’agit d’un service hébergé de gestion des licences destiné aux pare-feu SG UTM, arrivés en fin de vie en juin 2026. En attendant un correctif, MyUTM a été débranché.

Pour son système d’exploitation DSM, Synology a patché jusqu’à PHP 7.4. Il a fourni des mises à jour pour deux autres paquets touchés : Mail Station et Synology Calendar.

Chez QNAP, on compte une demi-douzaine de produits touchés, à commencer par QTS. Pas de correctifs pour le moment. Mais un appel à désactiver le serveur PHP si on n’en a pas l’usage.

Illustration générée par IA

The post Failles PHP : après l’électrochoc, la crainte du « killer PoC » appeared first on Silicon.fr.