PHP2Shell pour exécuter du code arbitraire, Fragnesia pour le faire avec les privilèges root.

Une opération possiblement d’origine chinoise a exploité ce tandem pour cibler des firewalls. L’un d’entre eux a permis de remonter jusqu’à un annuaire Active Directory dans un environnement appartenant vraisemblablement à une organisation affiliée au gouvernement américain.

La faille Fragnesia, utilisée pour détourner un module d’authentification

Révélée en mai, Fragnesia (CVE-2026-46300) est une faille locale d’élévation de privilèges dans le noyau Linux. Elle découle d’un bug dans un sous-système qui encapsule le trafic IPsec à l’intérieur de flux TCP. Dans les grandes lignes, le kernel « oublie » qu’un fragment mémoire est partagé avec d’autres structures système et le traite comme une zone tampon réinscriptible sans lever les protections d’accès habituelles. On peut ainsi écrire des octets arbitraires dans le page cache et d’obtenir un shell root.

L’opération en question a ciblé le fichier qui configure le module d’authentification PAM utilisé par la commande su. L’attaquant a fait en sorte que les règles d’authentification pointent vers un autre module, conçu pour renvoyer systématiquement un code de succès sans jamais solliciter ni vérifier de mot de passe. En basculant ainsi depuis l’espace utilisateur, l’attaquant est sorti de la sandbox dans laquelle SELinux le contenait – l’exploitation de PHP2Shell lui avait donné une empreinte locale, mais sous l’identité nobody.

PHP2Shell exploité à travers les sessions de téléversement

L’attaque a ciblé une marque de firewalls dont l’interface d’administration utilise PHP.

La première étape a consisté à conditionner la mémoire pour rendre déterministes les futures allocations d’objets. Vecteur : le mécanisme de suivi des téléversements, qui a l’avantage d’initialiser une session avant toute exécution de code applicatif. L’attaquant a bombardé le serveur de requêtes POST massives jusqu’à saturer la mémoire. Le tas était alors dans un état structuré, prévisible.

La deuxième étape a impliqué une lecture hors limites pour contourner l’ASLR.

Lorsque Zend – le moteur de PHP – manipule une chaîne telle qu’un identifiant de session, il se fie à un champ len pour savoir combien d’octets lire ou copier. En cas d’interruption d’une session, les structures internes ne sont que partiellement nettoyées.

L’attaquant en a profité pour envoyer une requête contenant un identifiant de session conçu pour réutiliser l’emplacement mémoire précédent. En raison de la gestion d’erreur incomplète lors d’un épuisement de mémoire, le champ len conserve une valeur artificielle plus grande que la taille réelle du contenu du tampon.

Lorsque le serveur traite la requête en question, il doit renvoyer l’identifiant de session via l’en-tête Set-Cookie. Comme len dépasse la fin réelle du tampon, le pointeur de lecture continue d’avancer et lit les octets bruts situés dans la mémoire adjacente sur le tas. L’attaquant peut convertir ces octets en une adresse. Sachant quelle structure résidait à cet endroit, il connaît son décalage par rapport au début de libphp.so (déterminé au préalable par rétro-ingénierie sur le binaire de PHP). Il peut ainsi calculer l’adresse de base de cette bibliothèque et neutraliser l’ASLR.

Une référence orpheline pour une fausse table de hachage

Un deuxième épuisement de mémoire laisse la variable globale http_session_vars active, mais vide les métadonnées internes associées. Cela crée un pointeur rémanent. Le système pense que la structure existe encore, alors que la mémoire sous-jacente est libérée.

Une ultime requête, dont les données viennent occuper cet espace mémoire, fabrique une fausse table de hachage interne.

Dans Zend, chaque table de hachage possède un pointeur de fonction qui nettoie les éléments quand la table est détruite. L’attaquant le configure pour qu’il pointe directement sur le symbole C interne de la fonction native system(). Et fait pointer la charge de données sur une commande shell. Lorsque PHP termine la requête et nettoie sa mémoire, il exécute automatiquement le destructeur sur le système hôte, avec les privilèges du processus serveur web (nobody, donc).

240 firewalls ciblés, 24 rootés

L’exploit exige des agencements mémoire précis qui diffèrent entre versions d’OS. Dans les traces de l’opération, on a trouvé 11 profils. Des « provisoires » (offsets calculés par rétro-ingénierie statique) et « calibrés » (validés en laboratoire).

La phase de découverte globale a reposé sur FOFA, un moteur chinois similaire à Shodan. Elle a permis d’identifier environ 19 000 firewalls dont l’interface d’administration était exposée à Internet. Environ 5000 ont renvoyé des infos de version. L’attaquant en a conservé 240, localisés aux États-Unis, au Japon, à Taïwan et en Corée du Sud, et qui correspondaient à leurs profils.

L’exploitation a été automatisée par lots de 5 firewalls, avec un timeout de 30 minutes par cible. Elle a permis d’implanter un webshell dans un dossier publiquement accessible, sur 24 firewalls.

Un annuaire Active Directory généreusement consulté

Sur 22 de ces firewalls, l’attaquant n’a réalisé aucune autre action. Les deux autres étaient semble-t-il associés à la même organisation, affiliée, donc, au gouvernement américain. Le fichier de configuration du premier paraît en témoigner, notamment au vu de l’authentification (Common Access Card) et de la convention de nommage des assets.

Ce fichier contenait toute la topologie du réseau. Il a convaincu l’attaquant de lancer une campagne distincte, centrée sur l’autre firewall compromis. Ayant créé un tunnel SSH persistant, ils est remonté vers le serveur central de gestion des firewalls. Puis vers l’Active Directory, qui y était connecté (nécessaire pour authentifier les utilisateurs du VPN). Ayant l’accès root, il a pu déchiffrer le mot de passe du compte de service LDAP. Il a également énuméré les utilisateurs et les groupes. Puis tenté la force brute, le domaine ne limitant pas les tentatives de saisie de mot de passe.

Les résultats de cette tentative sont restés sur le système de fichiers local du serveur de gestion des firewalls. La réussite n’est donc pas certaine. Même chose pour les actions ayant visé à créer des comptes backdoor (humain et machine), à extraire la clé de signature SAML depuis la configuration Keycloak (sécurité faible : validate-idp-certificate: no) et à analyser les chaînes ACL pour détecter des chemins d’escalade de privilèges.

La « nationalité » des firewalls ciblés laisse penser à une opération d’origine chinoise. Comme les outils exploités (au-delà de FOFA, il y a l’utilitaire de tunneling iox). Autre indice : l’utilisation de la plate-forme de sécurité offensive aiscan configurée avec des modèles Kimi et DeepSeek. L’horloge de l’infrastructure d’attaque était par ailleurs réglée sur UTC+8 (heure de Pékin). Et les logs d’aiscan contiennent des messages utilisateur en chinois.

Illustration générée par IA

The post Combiné à d’autres failles, PHP2Shell devient plus concret appeared first on Silicon.fr.

Malgré les revendications, il n’existe toujours pas de preuve publique d’un exploit générique pour PHP2Shell.

Un ingénieur de HubSpot a compilé – avec l’aide de l’IA et sans vérification intégrale, admet-il – une chronologie récapitulative. Elle donne un aperçu de l’enchaînement des annonces… et des rétractations.

Une divulgation pas si coordonnée

Avant d’en arriver là, il y eut la procédure de divulgation coordonnée des deux vulnérabilités. Et la mauvaise gestion de l’embargo associé. Chainguard l’a effectivement rompu. Une dizaine d’heures avant l’échéance convenue, il a publié des versions patchées de sa distro Wolfi. Son patron présente ce choix comme une réaction à des signalements d’exploitation active sur les canaux de coordination. Une décision renforcée, ajoute-t-il, par la « facilité » que l’entreprise avait eue à développer elle-même un PoC.

Une foule de PoC… « de laboratoire »

VulnCheck fait partie des entreprises de la cyber qui ont revendiqué un PoC « de laboratoire ». Il l’a d’abord dit fonctionnel contre PHP 8.4.26 (mod_php) sur x86-64 avec ASLR activé et display_errors = off. Depuis, le rayon s’est étendu à l’essentiel des versions non patchées sur les branches 8.2 à 8.5. Et, pour certaines, à l’architecture ARM.

Trail of Bits y est aussi allé progressivement. Jusqu’à affirmer disposer d’un exploit « de production », en particulier parce que opérationnel en multiworker avec la configuration php.ini de base. Il en a présenté une démo contre MediaWiki, WordPress, Symfony, phpBB et Laravel.

Des annonces de compromissions suivies de rétractations

Dans une alerte relative à PHP2Shell, le CERT indien indique que « plusieurs rapports confirment une exploitation à grande échelle ». Il ne les source cependant pas.

Sophos est allé jusqu’à parler de preuve de compromission, mais s’est rétracté quelques heures après. Même situation chez Palo Alto Networks. Son équipe Unit 42 avait rapporté une attaque contre une agence gouvernementale européenne ayant mené au vol de hashs de mots de passe et de secrets MFA « dans les deux heures après exploitation ». Elle s’est finalement dédite : l’attaque s’est inscrite dans le contexte d’une application PHP vulnérable, mais il n’est pas certain que PHP2Shell ait constitué le vecteur d’accès initial…

Chez Perplexity, une preuve limitée d’exploitation « hors labo »

La trace la plus crédible d’une exploitation réussie de PHP2Shell « hors laboratoire » provient peut-être du directeur détection et réponse de Perplexity.

L’intéressé a observé, sur un réseau de pots de miel, une chaîne d’exploitation en quatre étapes avec exécution de code arbitraire. Elle reproduit une famille de PoC publics.

La première requête épuise la mémoire et laisse le tas dans un état invalide. La deuxième force le renvoi d’un cookie anormalement volumineux qui expose une partie de la mémoire du processus. L’attaquant peut ainsi cartographier l’agencement et calculer les décalages nécessaires pour contourner l’ASLR.

La troisième requête stabilise le tas PHP dans un état prévisible afin que la structure qui sera corrompue lors de la dernière étape se positionne exactement à l’endroit calculé.
Le contenu de l’ultime requête est dynamique. En plus de la commande shell à injecter, il intègre les adresses mémoire recalculées d’après les pointeurs extraits. Le worker détourne son flux d’instructions et engendre un processus enfant qui exécute la charge utile.

La corruption mémoire fait crasher le worker avant toute exécution de code applicatif. L’audit eBPF permet toutefois de journaliser le lancement des processus shell. Logs qu’on peut corréler à la requête via les captures de paquets.

La configuration des honeypots était favorable aux attaquants, tempère le directeur détection et réponse de Perplexity. Elle n’était en tout cas pas représentative de déploiements typiques (instances PHP 8.24.6 exécutées via mod_php en mode monoworker, avec memory_limit = 128M).

Lundi, la CISA a en tout cas ajouté PHP2Shell dans son catalogue KEV (Known Exploited Vulnerabilities).

Illustration générée par IA

The post PHP2Shell tourne à la course à l’échalote appeared first on Silicon.fr.

Une surface d’attaque en apparence vaste*, un risque théorique d’exécution de code arbitraire, des PoC, mais pas d’exploitation massive : aux dernières nouvelles, on en est à peu près là avec P2P2Shell.

La situation est comparable pour une autre vulnérabilité nouvellement rendue publique. On l’a successivement appelée Node2Shell, HTTP2Shell… et finalement Brotli2Shell. Et pour cause : elle affecte la bibliothèque de décompression Brotli.

Un code d’erreur pas assez granulaire

Le problème se trouve dans le décodeur. Pour maximiser le taux de compression, Brotli découpe le flux de données décompressées en trois catégories. Chacune peut basculer entre plusieurs sous-modèles statistiques (« types de blocs ») optimisés pour un contexte donné. Dès qu’un bloc arrive à expiration, le décodeur doit appeler cette fonction pour savoir comment interpréter les symboles suivants.

La fonction qui gère ce changement de contexte retourne un simple booléen qui ne permet pas de distinguer les flux incomplets des flux corrompus. Face à un flux sollicitant un changement de type bloc impossible, le décodeur, constatant l’échec sans code d’erreur granulaire, suppose être en présence d’un flux incomplet. Le moteur continue donc à écrire les octets dans un petit tampon fixe. Une écriture hors limites finit par survenir. Elle écrase les métadonnées et structures internes adjacentes qui maintiennent l’état du décodeur. L’attaquant peut alors modifier des pointeurs internes, créer une primitive de lecture arbitraire (utile pour faire fuiter des adresses mémoire) et détourner le flux d’exécution.

Le correctif ajoute un code d’erreur explicite et bloquant. Google – qui maintient Brotli – l’avait ajouté au code source fin février, sans mention explicite de criticité. Surtout, il n’avait pas publié de nouvelle version taguée de la bibliothèque (la dernière release est restée datée d’octobre 2025). À moins de compiler depuis la branche principale, les applications en aval restaient vulnérables.

De Node2Shell à Brotli2Shell, plusieurs stades de compréhension

Au début, on a pensé que la vulnérabilité touchait Node.js ; d’où le nom Node2Shell. Puis on a compris qu’elle n’y était pas circonscrite. Elle affecte en l’occurrence l’implémentation C de référence de Brotli. D’où le nom Brotli2Shell (on trouve aussi Broccoli2Shell). Entre les deux, il y a eu HTTP2Shell, sur le fondement que la faille concernait toutes les applications utilisant HTTP.

Le menace n’est pas tant du côté des serveurs web, qui décompressent rarement les requêtes entrantes. Elle est surtout côté client. Sur le papier, toute application qui consomme des URL (aperçu de liens, webhooks, import de fichiers…) s’expose à recevoir une réponse piégée.

Mettre à jour les paquets système ou les images de base ne suffit pas toujours. Illustration avec Node.js, qui embarque son propre binaire statique de Brotli, auquel il fait appel notamment via son API fetch.

À ce stade, il n’y a pas de preuve d’exploitation active, malgré des démos partielles. Manque plus globalement un PoC complet. Il en circule, mais qui visent des configurations spécifiques volontairement affaiblies.

Un (r)appel à la transition vers Rust

Pour qui ne peut pas peut patcher, les deux mesures principales consistent à désactiver la décompression Brotli automatique dans les clients HTTP et à rejeter, au niveau du frontal, les requêtes qui incluent l’en-tête Content-Encoding: br.

7-zip, Bun, ClickHouse, Envoy, Firefox, Istio et Mozilla, entre autres, ont été patchés. C’est en cours de déploiement dans Apache Arrow et DuckDB.

Conjuguée à PHP2Shell, cette vulnérabilité de mémoire alimente le débat sur la transition de C vers Rust. Dropbox a développé un portage dans ce langage, mais son implémentation implique un compromis en matière de performance.

* W3Techs, qui analyse les parts de marché des technologies web, estime que 38,4 % des sites utilisent la compression Brotli. À comparer aux quelque 70 % qui utilisent PHP.

Illustration générée par IA

The post Dans l’ombre de PHP2Shell, une autre faille mémoire fait parler appeared first on Silicon.fr.

« 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.

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.

Il est complexe de généraliser l’exploitation des vulnérabilités de mémoire… mais les LLM peuvent aider.

Wiz fait la remarque dans son tour d’horizon de PHP2Shell.

La filiale de Google n’a pas découvert à elle seule cette famille de failles critiques qui touchent le cœur de PHP. Elle a toutefois pris le lead sur la narration, allant jusqu’à créer le site web php2shell.com – et vantant, au passage, la contribution « inestimable » du modèle Gemini 4 Argon.

Le projet PHP propose un point de vue plus neutre dans son bulletin de sécurité. Il ne minimise cependant pas l’urgence de la situation : toutes les installations qui servent des requêtes web sont exposées à des exécutions de code arbitraire sans authentification. Wiz parle de 70 % des sites web. L’équipe Unit42 de Palo Alto Networks, de 22,6 millions d’instances potentiellement vulnérables.

L’équipe sécurité de PHP a patché toutes les versions mineures encore prises en charge (8.5, 8.4, 8.3 et 8.2). Vu la gravité, elle fournit des rétroportages minimaux du code source pour PHP 8.1, 8.0 et 7.4.

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

1. Épuiser la mémoire (CVE-2026-109618)

Lorsqu’un dépassement de mémoire survient, un saut longjmp() interrompt le traitement. Seulement, si cette saturation se produit pendant la phase d’initialisation de la requête, PHP ne gère pas correctement la sortie anticipée : il laisse la mémoire dans un état corrompu. La procédure d’arrêt de la requête peut ensuite lire ces données invalides, ouvrant la voie à l’exécution de code arbitraire.

Plusieurs stratégies permettent de déclencher cette condition, en jouant entre autres sur les en-têtes, la longueur de contenu ou les métadonnées. Apache mod_php et FrankenPHP sont particulièrement vulnérables, car ils exécutent inconditionnellement la procédure d’arrêt, avant que le moindre code propre à l’application ne s’exécute.

La fiabilité de l’exploit dépend de la compilation de PHP, des extensions activées, du comportement du serveur front-end et de l’agencement de l’allocateur mémoire.

Le correctif supprime l’usage de longjmp() en cas de dépassement de mémoire. Il lui substitue un arrêt différé, déclenché au prochain point de contrôle sécurisé de la VM. Ou bien, si la consommation mémoire franchit un seuil plus élevé, un arrêt d’urgence immédiat utiliant _exit().

Les principales méthodes de contournement

Dans l’impossibilité d’installer une version patchée, la principale mesure consiste à définir la valeur memory_limit = -1. Cela neutralise certains chemins d’attaque. En contrepartie, on délègue au système d’exploitation la gestion de l’épuisement de mémoire. Aussi, on utilisera volontiers la directive memory.max des cgroups (ou un mécanisme équivalent disponible) pour contenir la consommation de ressources et circonscrire l’impact sur la disponibilité aux seuls processus PHP. Dans tous les cas, on s’assurera qu’aucun paramétrage de pool, de répertoire ou d’application ne rétablit une limite finie de mémoire.

Cette mesure ne résout pas tout. Si mmap() ou une autre allocation sous-jacente échoue, PHP peut encore utiliser longjmp() tandis que la mémoire incomplète de la requête reste accessible.

Autre méthode d’atténuation : conserver une valeur prudente pour post_max_size. Pour les applications qui ne nécessitent pas de téléverser des fichiers, on peut régler à 8M. Sinon, à 32 M. En parallèle, on peut envisager de réduire le niveau d’imbrication (max_input_nesting_level). Et de plafonner le nombre de variables d’entrée, de parties multipart, d’en-têtes par partie et de fichiers téléversés.

2. Détourner les états globaux (CVE-2026-109619)

Dans PHP, un worker persistant conserve des structures d’état globales (sessions, objets, extensions…), mais qui pointent vers des zones mémoire allouées pour la requête en cours.

Cette mémoire est libérée sans que les états globaux soient correctement remis à zéro au préalable. Lorsque le même worker prend en charge une nouvelle requête, des opérations précoces (traitement d’entrées, application de configurations, levée d’erreurs…) s’exécutent avant l’initialisation standard. Elles accèdent alors à ces pointeurs résiduels.

En contrôlant l’agencement du tas mémoire, on peut manipuler les données réallouées à cet emplacement. Et ainsi détourner le flux d’instructions pour exécuter du code arbitraire.

Deux RCE confirmées

Il y a là aussi plusieurs stratégies de déclenchement. Au moins deux RCE ont été confirmées. L’une repose sur la directive fatal_error_backtraces. Lorsqu’elle est activée, le signalement des erreurs fatales stocke un état de traces d’appels appartenant à la requête. La réinitialisation de cet état global est systématiquement omise lors de la phase d’arrêt. Ce scénario, que le projet PHP considère comme le plus solide, est le fondement de l’exploitation confirmée sur mod_php.

L’autre chemin de RCE, validé sur mod_php et sur FPM, passe par le suivi de progression des téléversements. Le traitement peut initialiser l’état de session à un stade précoce et publier un identifiant de session dans PS(id). Si une erreur fatale survient pas après, PHP peut détruire le tas mémoire de la requête alors PS(id) continue d’y faire référence.

Les principales méthodes de contournement

Principale mesure de contournement, que le CERT-FR met d’ailleurs en avant : régler à 0 la valeur session.upload_progress.enabled. Ce en utilisant le fichier .ini, la configuration d’un pool FPM oou une configuration serveur s’appliquant avant l’analyse des requêtes. Le réglage a pour effet de désactiver le suivi de la progression des uploads.

Sous PHP 8.5 spécifiquement, on peut désactiver fatal_error_backtraces. Autre possibilité, applicable à toutes les versions : paramétrer display_errors=0 pour empêcher l’exposition des messages d’erreur PHP aux utilisateurs distants.

En aval, des correctifs diversement mis en œuvre

Le CERT néerlandais (NCSC-NL) tient une liste des logiciels tiers potentiellement concernés.

Les fournisseurs de PaaS se sont révélés particulièrement réactifs. Scalingo en fait partie. En complément à l’annonce du déploiement des versions corrigées, il revient sur sa démarche de remédiation, amorcée pour la désactivation du suivi des uploads puis le blocage des requêtes multipart pour toutes les applications.

Heroku a également fait le nécessaire, en utilisant les correctifs rétroportés… mais uniquement pour PHP 8.1. Upsun (ex-Platform.sh) est remonté jusqu’à PHP 7.4. Au contraire de Scalingo et d’Heroku, il a automatiquement redéployé les environnements concernés.

Chez Netgate, le correctif est disponible pour les passerelles de sécurité pfSense. Il faut toutefois passer par la ligne de commande pour l’appliquer. L’entreprise rappelle que par défaut, le GUI n’est accessible que sur le LAN, tandis que le portail captif (destiné aux utilisateurs externes) est désactivé.

Palo Alto Networks classe PHP2Shell comme une urgence modérée pour ses produits. Les vulnérabilités touchent toutes les versions de PAN-OS et de Panorama actuellement prises en charge. Dans le même esprit que Netgate, l’entreprise signale que le risque est plus élevé si des adresses IP externes peuvent accéder à l’interface de gestion. Aussi recommande-t-elle d’intercaler une jump box.

En attendant des versions corrigées de PAN-OS et de Panorama, Palo Alto Networks recommande des atténuations… dont le virtual patching restreint à ses clients ATP Plus.

Les CMS, cobayes de PHP2Shell

Parmi les logiciels confirmés vulnérables figurent beaucoup de CMS. À commencer par Drupal, Joomla et WordPress. C’est sur eux que Wiz a concentré sa démonstration des exploits.

La vulnérabilité CVE-2026-109618 touche les trois CMS. La CVE-2026-109619 affecte Drupal via les backtraces et WordPress à travers une corruption d’état PHP partagé (confusion de type sur OPcache).

La filiale de Google affirme avoir été la première à découvrir PHP2Shell, le 19 août et l’avoir signalée au projet PHP le 24. Parmi les quelques chercheurs externes qu’elle remercie pour leur contribution, il en est un qui avance une autre chronologie. Pas forcément en conflit, mais qui témoigne d’une convergence de travaux.

Le chercheur en question travaille chez Calif, société spécialisée dans la sécurité offensive. Il replace ses découvertes dans le contexte du programme Daybreak d’OpenAI. Et plus précisément de l’initiative Patch the Planet, qu’on l’avait invité à rejoindre fin juillet. PHP faisait alors partie des cibles d’intérêt. Il a signalé un premier bug au projet le 11 août, lui transmettant le 14 un PoC confirmé fonctionnel le lendemain.

Illustration générée par IA

The post PHP2Shell : les correctifs arrivent, mais pas au même rythme appeared first on Silicon.fr.