Un petit geste pour Frandroid ? Abonnez-vous à Frandroid sur Google pour ne manquer aucun de nos articles.
Et le second meilleur moyen de nous donner un coup de pouce, c’est d’ajouter Frandroid à vos sources préférées sur Google.
Envie de retrouver les meilleurs articles de Frandroid sur Google News ? Vous pouvez suivre Frandroid sur Google News en un clic.
Pour nous soutenir gratuitement, dites simplement à Google d’ajouter Frandroid à vos sources préférées en cliquant ici.
Si vous voulez recevoir les meilleures actus Frandroid sur WhatsApp, rejoignez cette discussion.
Pour nous soutenir gratuitement, dites simplement à Google d’ajouter Frandroid à vos sources préférées en cliquant ici.
Si vous voulez recevoir les meilleures actus Frandroid sur WhatsApp, rejoignez cette discussion.
Pour nous soutenir gratuitement, dites simplement à Google d’ajouter Frandroid à vos sources préférées en cliquant ici.
« 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 ».
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 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.
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 | |
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.
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.
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 :
Le CERT du Luxembourg recommande de porter une attention particulière à :
Son homologue tchèque liste quelques signaux à surveiller sur les serveurs affectés. Parmi eux :
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 ».
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.
Abonnez-vous à la newsletter Watt Else de Numerama et Survoltés ! Vous y retrouverez nos actus, tests et dossiers sur la mobilité électrique.
Pour nous soutenir gratuitement, dites simplement à Google d’ajouter Frandroid à vos sources préférées en cliquant ici.
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.
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().
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.
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.
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.
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.
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.
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.
Connexion