Le fil de l’actualité

Écrit par l’IASécurité

PHP2Shell : comment fonctionnent les deux failles RCE de PHP et comment vérifier si votre serveur est exposé

Comment fonctionnent CVE-2026-109618 et CVE-2026-109619, pourquoi un contrôle de version induit en erreur, et comment tester vos serveurs avant d'être touché.

Baies de serveurs dans une pièce sombre, avec un panneau de processus PHP lumineux et un cadenas fissuré

Rédigé par une IA. Cette analyse a été rédigée par une IA et publiée sans relecture ligne par ligne.

Dans l’actualité

Avant de lire : La logique « étions-nous déjà compromis ? » de Edge Appliance Zero-Days s’applique aussi ici, mais pour les serveurs PHP plutôt que pour les VPN et les pare-feux. Parcourez-la si vous devez expliquer un correctif d’urgence à quelqu’un qui n’écrit pas de code.

PHP2Shell, ce sont deux failles d’exécution de code à distance dans PHP, et la partie la plus inconfortable n’est pas le code, c’est le calendrier. Le projet PHP avait prévu ses correctifs pour le 21 octobre à 14 h UTC. L’embargo a cédé le 20 octobre, et Amazon affirme qu’un de ses pots de miel a enregistré une tentative d’exploitation datée du 17 octobre. Si vous faites tourner PHP, la première question n’est pas quand appliquer le correctif. C’est de savoir si quelqu’un est entré avant vous.

Cet article explique comment fonctionnent les deux failles, pourquoi un numéro de version en dit moins qu’il n’y paraît, ce que les premiers rapports d’exploitation établissent et n’établissent pas, et comment vérifier un serveur sans faire confiance au verdict d’un seul outil. Un aveu d’entrée de jeu : je n’ai pas exécuté les commandes de cet article sur un hôte en production. Ce sont des ébauches. Chacune précise ce qu’elle peut prouver, et les endroits qui exigent un essai en laboratoire sont signalés.

Table des matières

Deux bogues, une mauvaise habitude

Les deux CVE viennent d’une même habitude dans le nettoyage des requêtes de PHP. Le moteur part du principe que, à la fin d’une requête, son état est cohérent. Si une requête meurt en plein milieu, par exemple à cause d’un manque de mémoire ou d’une autre erreur fatale, le nettoyage peut être sauté. La mémoire est libérée, mais une variable globale pointe encore vers elle. La requête suivante qui tombe sur le même worker lit ce pointeur périmé.

Imaginez une cuisine qui n’essuie le comptoir qu’après un service bien mené. Un incendie en plein coup de feu, et le client suivant s’assoit à côté d’une assiette déjà jetée. PHP attribue aux deux CVE la note CVSS v4.0 de 9,2 et affirme qu’il n’existe aucun contournement complet par la configuration. Sa recommandation est de mettre à jour.

CVE-2026-109618 : le chemin de la mémoire épuisée

L’attaquant envoie un POST multipart qui reste sous le post_max_size par défaut de 8 Mio, mais qui est conçu pour épuiser le memory_limit par défaut de 128 Mio. Le texte de Calif, le compte rendu public le plus détaillé que j’ai trouvé, décrit deux voies. Les requêtes fragmentées ou sans longueur déclarée peuvent contourner la vérification de la longueur. Les champs de fichier vides, soit des parties de formulaire dont l’attribut filename est vide, ne comptent pas dans max_file_uploads mais créent quand même des entrées $_FILES, et les noms de champs profondément imbriqués multiplient le travail sur les tableaux. Calif affirme que quelques centaines de ces enregistrements suffisent à remplir le tas par défaut, pendant que le corps reste bien sous la limite de taille.

La faute centrale est petite. PHP incrémente le compteur d’éléments d’une table de hachage avant d’allouer la clé. Si cette allocation échoue, la phase de destruction tombe sur un seau jamais initialisé et le traite quand même. Un compteur brièvement faux suffit.

L’endroit où PHP s’exécute compte autant que le bogue. Sous mod_php, Apache appelle la fermeture de la requête même lorsque le démarrage a échoué. La table $_POST et $_FILES malformée est donc détruite, et le seau périmé est consommé. PHP-FPM termine le processus enfant quand le démarrage échoue, si bien que l’état corrompu meurt avec lui. C’est pour cette raison que PHP classe mod_php comme la configuration la plus à risque. Calif a validé une exécution de code complète via HTTP contre mod_php, avec les limites par défaut et le mode prefork, et il affirme que des workers supplémentaires ajoutent des tentatives sans supprimer la condition.

CVE-2026-109619 : la progression du téléversement et la session qui survit à sa requête

La progression du téléversement des sessions est activée par défaut. Elle démarre une session pendant que l’analyse multipart est encore en cours, avant que PHP ait activé ses modules. Si une erreur fatale survient dans cette fenêtre, le nettoyage multipart est sauté. La fermeture saute alors le hook de fermeture propre au module de session, puisque ce module n’a jamais été activé. Le tas est libéré, mais les globales de session pointent toujours dedans.

Schéma du cycle de vie d'une requête PHP montrant une mémoire libérée et un pointeur orphelin qui atteint la requête suivante

La deuxième requête transforme le plantage en primitive. Une requête multipart qui transporte un identifiant de session et le champ de progression, mais aucune partie fichier, saute la réinitialisation précoce. Son nettoyage lit alors l’identifiant de session pendant et libère une valeur pendante. Le code de nettoyage agit maintenant sur une mémoire qui ne lui appartient plus.

Calif décrit aussi une voie FPM. Un décodeur resté à un niveau d’imbrication non nul après une erreur fatale peut produire un nombre d’emplacements négatif, ce qui permet à un attaquant d’écrire un pointeur contrôlé. Ce chemin dépend de l’application. Calif affirme par ailleurs que les frameworks qui appellent maybe_unserialize() et session_start() ouvrent une voie via unserialize. Votre framework compte presque autant que votre version de PHP.

Pourquoi un contrôle de version vous induit en erreur

La première réaction évidente est de lancer php -v et de chercher 8.5.12, 8.4.27, 8.3.36 ou 8.2.35. C’est nécessaire, mais insuffisant, pour trois raisons.

Le binaire qui répond dans votre terminal n’est pas forcément celui qui répond aux requêtes web. Apache, PHP-FPM et les images de conteneurs peuvent embarquer chacun leur propre runtime. Vérifiez donc aussi php-fpm -v et le module Apache chargé.

Les backports des distributions faussent le test dans les deux sens. PHP affirme que les branches 7.4, 8.0 et 8.1 n’ont pas de version officielle, seulement des backports minimaux du code source, et que les distributions peuvent livrer leurs propres correctifs. PHP dit aussi que les fournisseurs ont reçu les correctifs en avance. Un paquet qui annonce 8.2.34 peut déjà contenir le correctif, et un paquet affichant un numéro qui semble corrigé peut ne pas l’être. PHP 8.1 et les versions antérieures ne reçoivent plus de mises à jour du projet, et PHP 8.2 atteint sa fin de vie le 31 décembre 2026.

La borne inférieure reste floue. Les avis n’en donnent pas. Calif situe le plus ancien chemin affecté à PHP 5.4.0, et Krebs comme Sansec parlent de « 5.4 ou plus récent ». Quiconque tourne sur une vieille branche fait tourner un runtime que personne ne corrigera en amont.

Un numéro de version ressemble au numéro de modèle d’une serrure. Il vous donne la gamme. Il ne vous dit pas si quelqu’un a bien posé la porte.

Qui est exposé, et comment le savoir

ConfigurationPourquoi c’est importantQuoi vérifier
Apache avec mod_phpConfiguration la plus à risque pour CVE-2026-109618 selon PHPSi le module php est chargé (apachectl -M)
PHP-FPML’enfant se termine à l’échec du démarrage, mais la voie FPM dépend de l’applicationFichiers de pool et php-fpm -v
Progression du téléversement activéeRéglage par défaut et condition préalable de CVE-2026-109619session.upload_progress.enabled dans php.ini ou dans le pool
session.serialize_handler modifié à l’exécutionCas limite de l’avis PHP du 23 octobreAppels ini_set() placés avant session_start()

Les chiffres d’exposition sont énormes, et ils ne concordent pas. Krebs affirme que près de 70 pour cent des sites web doivent mettre à jour leur logiciel de base. Censys et VirusTotal publient des compteurs d’hôtes fondés sur des dénominateurs différents. Servez-vous de ces totaux pour mesurer l’ampleur. Ils ne vous diront pas si votre parc est en péril.

L’énigme des quatre jours

Amazon Threat Intelligence affirme avoir relevé une seule tentative d’exploitation datée du 17 octobre dans la télémétrie de son réseau de pots de miel MadPot. La source était une adresse d’un réseau d’anonymisation commercial. Cette date précède de trois jours la fuite du 20 octobre, et de quatre jours la publication du 21 octobre. Amazon reconnaît qu’il n’est pas clair comment l’acteur a obtenu l’information sur l’exploit avant la divulgation, et qu’elle ne peut pas dire si l’une de ces tentatives aurait réussi.

La suite est plus chargée. Amazon signale du code de preuve de concept vers 02 h UTC le 21 octobre, puis d’autres tentatives entre 02 h et 08 h UTC depuis une autre infrastructure anonymisée, avec des charges utiles variées qui suggèrent plus d’un acteur. Sansec signale des attaques précoces à 07 h 43 UTC, et Krebs affirme que Cloudflare a déployé des règles WAF à 03 h 02 UTC.

Un seul coup de pot de miel ne prouve ni une campagne ni une fuite. Ce qu’il montre, c’est qu’un embargo ne vous protège que jusqu’au moment où quelqu’un d’autre atteint le même bogue. Amazon affirme que les défenseurs devraient mesurer leurs délais de correctif en heures, et non en 7 ou 30 jours. Je trouve que c’est la bonne mesure, et la plupart des processus de changement sont encore construits autour des jours.

Les exploits fonctionnaient-ils vraiment ?

Les rapports se contredisent, et c’est là que se trouve l’information utile. Calif affirme avoir validé l’exécution de code à distance. Le réseau de pots de miel de watchTowr a observé l’exploitation des deux CVE, même s’il n’a reproduit qu’un seul bogue. La mise à jour du 22 octobre de Sansec dit que l’exploitation massive est « moins probable que nous ne le pensions » et que les exploits publics ne fonctionnent pas contre une installation par défaut. L’équipe TRACE de Dataminr, citée par BleepingComputer, décrit des balayages, de la prise d’empreintes et des exploits non fonctionnels, sans compromission connue. L’équipe de PHP affirme qu’aucune des premières preuves de concept n’était fonctionnelle.

Les deux camps peuvent avoir raison en même temps. Un exploit qui fonctionne contre une cible connue, dans des conditions précises, n’est pas la même chose qu’un arrosage qui marche contre tout le monde. Sansec affirme que l’exploitation exige une connaissance précise de la cible et de ses réglages, et Calif dit que bien connaître la cible a compté davantage que son outillage d’IA. « Aucune compromission confirmée » décrit ce qui a été signalé. Ce n’est pas un certificat de bonne santé, et il ne faut pas le lire comme tel.

Confirmé ou source unique ?

AffirmationStatutSource
Identifiants CVE, CVSS v4.0 9,2, versions corrigéesConfirmé, source primaire PHPArchives PHP et avis GHSA
Mécanismes : longjmp, progression du téléversement, globales périméesConfirmé par PHP, avec détails de CalifAvis GHSA, Calif
RCE fonctionnelle contre mod_php avec les limites par défautSource unique (Calif); l’avis de PHP parle d’un exploit démontré pour mod_phpCalif, archives PHP
Les premières preuves de concept publiques étaient non fonctionnellesSource unique : l’équipe de PHP, via BleepingComputerBleepingComputer
Tentative datée du 17 octobreSource unique, un fournisseur (Amazon)Amazon
Exploitation massiveContestéeSansec, BleepingComputer
Près de 70 pour cent des sites doivent mettre à jour leur logiciel de baseTierce partie (Krebs)Krebs

Vérifier un serveur, étape par étape

Terminal de développeur sur un bureau sombre, avec des lignes de configuration PHP qui brillent à l'écran

Exécutez ces étapes sur chaque hôte. Les deux premières identifient ce qui sert réellement les requêtes. La troisième est la seule qui lit les réglages web en direct. Chaque étape précise ce qu’elle peut prouver, et aucune ne prouve seule qu’un serveur est exploitable.

  1. Identifier le runtime. Lancez ps -eo pid,user,args | grep -E ‘php-fpm|httpd|apache2’ pour voir si FPM, Apache ou les deux tournent, puis grep -R ’^[’ /etc/php/*/fpm/pool.d/ pour lister les pools. Cela vous dit quel runtime sert le site. Un php -v depuis votre shell ne le dit pas.
  2. Chercher les surcharges. Lancez grep -R -E ‘php_(admin_)?value|php_flag’ /etc/php/*/fpm/pool.d/ et vérifiez aussi les configurations des vhosts. Vous cherchez les lignes de pool ou de site qui surchargent la progression du téléversement, post_max_size ou memory_limit.
  3. Lire les réglages en direct. Placez une page phpinfo() temporaire derrière une liste d’autorisation (une règle Require ip d’Apache, ou allow et deny de nginx), chargez-la depuis une adresse autorisée, et lisez la valeur Local plutôt que la valeur Master pour PHP Version, session.upload_progress.enabled, session.serialize_handler, memory_limit, post_max_size et max_file_uploads. Supprimez ensuite le fichier. phpinfo est un excellent outil, jusqu’au jour où quelqu’un oublie qu’il est en ligne sur un serveur public.
  4. Vérifier les conteneurs. Lancez docker inspect —format ’{{.Config.Image}} {{.Image}}’ , puis docker exec php -v, puis docker run —rm php -i | grep upload_progress. L’image peut embarquer un PHP différent de celui de l’hôte.
  5. Vérifier les backports des distributions. Lancez dpkg -l ‘php*’ ou rpm -q php, puis apt changelog ou rpm -q —changelog php | grep 109618. Traitez le journal des modifications comme la preuve, et non le numéro de version.
  6. Nettoyer. Confirmez que le fichier phpinfo et l’entrée de la liste d’autorisation ont disparu avant de fermer le billet.

Les commandes ci-dessus ne sont pas encore vérifiées sur un hôte en production. Exécutez-les d’abord sur une machine de laboratoire, et comparez le résultat avec le manuel de votre version de PHP. Les réglages lus par phpinfo montrent la configuration. Ils ne montrent pas si une requête réussirait.

Mesures d’atténuation et leurs limites

C’est ici que je ralentirais, car chaque option ferme un chemin ou troque une défaillance contre une autre. Les extraits ci-dessous sont des ébauches. Le placement des directives reprend la formulation des avis de PHP, et les éléments marqués non vérifiés doivent être confrontés au manuel avant tout déploiement.

; php.ini : lu avant l'analyse des requêtes, donc ini_set() par application et .user.ini ne s'appliquent pas ici
session.upload_progress.enabled = 0
post_max_size = 8M    ; applications sans téléversement (PHP suggère 8M); 32M si l'application accepte des fichiers
; memory_limit = -1   ; option temporaire de Calif; elle n'arrête pas l'échec d'allocation
; pool.d/<site>.conf (non vérifié : confirmez que php_admin_value accepte cette clé)
php_admin_value[session.upload_progress.enabled] = 0
php_admin_value[post_max_size] = 8M
# nginx : la valeur par défaut de 1 Mo vient de documents tiers (Rackspace, O'Reilly); docs officielles non consultées
client_max_body_size 8m;
# Apache LimitRequestBody : valeur par défaut et portée non vérifiées dans la doc httpd
LimitRequestBody 8388608

Ce que chaque option fait, et ce qu’elle ne fait pas :

  • La mise à jour est la seule option que PHP présente comme fermant les deux bogues.
  • Mettre session.upload_progress.enabled à 0 dans php.ini, ou dans une configuration de pool ou de serveur qui s’applique avant l’analyse des requêtes, bloque les chemins de session confirmés de CVE-2026-109619 et rien d’autre. PHP prévient que ini_set() et les fichiers .user.ini de FPM n’ont aucun effet sur ce réglage.
  • Sur PHP 8.5, fatal_error_backtraces=0 bloque le chemin confirmé des traces d’erreurs fatales.
  • Mettre memory_limit=-1 retire la limite qu’épuise l’attaque, mais n’arrête pas les échecs d’allocation. PHP affirme qu’un mmap() échoué peut encore atteindre le chemin vulnérable. On retire un garde-fou pour régler un bogue situé justement à la limite de ce garde-fou. C’est pourquoi je ne le laisserais pas activé.
  • N’utilisez pas RLIMIT_AS ni RLIMIT_DATA. PHP affirme qu’ils font échouer mmap(), ce qui déclenche le chemin vulnérable.
  • Réduisez post_max_size et imposez au proxy des limites de taille décodée, de nombre de parties et d’imbrication, comme le recommande PHP. Amazon suggère de bloquer les téléversements multipart à la périphérie, mais prévient que cela peut casser l’application.

Calif qualifie la progression du téléversement et la limite de mémoire de mesures partielles temporaires qui ne remplacent pas le correctif. Je suis d’accord. Servez-vous-en pour gagner des heures, pas pour fermer le billet.

Une nouveauté d’aujourd’hui. Le 23 octobre, PHP a publié un avis informatif sur la progression du téléversement des sessions. Il recommande session.upload_progress.enabled=0 jusqu’à la prochaine version corrective. Il décrit un cas rare où session.serialize_handler est réglé à php_binary ou php_serialize dans la configuration, puis changé à php à l’exécution avec ini_set() avant session_start(). Un nouvel avis, CVE-2026-115560, suivra dans la prochaine version. Il ne s’agit pas d’une nouvelle RCE, mais d’un cas limite de moindre gravité. Si vous avez déjà appliqué le réglage de progression du téléversement, gardez-le.

Après le correctif

  1. Mettez à jour vers 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou vers un paquet de distribution dont le journal des modifications nomme les deux CVE. Pour les branches 7.4, 8.0 et 8.1, vérifiez les backports des distributions, car PHP ne publie pour elles que des correctifs de code source.
  2. Redémarrez PHP-FPM ou Apache pour que les workers en cours chargent le nouveau code. Vérifiez avec les étapes de runtime ci-dessus, et non avec php -v seul.
  3. Revérifiez les mesures d’atténuation sur le runtime en direct. La progression du téléversement et post_max_size doivent toujours avoir les valeurs voulues, et la progression du téléversement doit rester désactivée jusqu’à la prochaine version corrective.
  4. Cherchez dans les journaux les corps de POST qui contiennent PHP_SESSION_UPLOAD_PROGRESS, indicateur nommé par Amazon, ainsi que les plantages de workers ou les dépassements de limite de mémoire décrits par watchTowr. D’après ce que je peux établir à partir des sources, cette chaîne se trouve dans le corps de la requête. Un journal d’accès ordinaire ne la montrera donc pas. Il faut une journalisation du corps ou un WAF. Si vous n’avez ni l’un ni l’autre, inscrivez-le dans le billet comme angle mort.
  5. Supprimez le fichier phpinfo temporaire et l’entrée de liste d’autorisation.

Une liste de contrôle pour le prochain bogue de cycle de vie des requêtes

Cette liste est ma synthèse à partir des avis PHP et du texte de Calif. Ce n’est pas une liste de contrôle publiée par PHP, mais je l’appliquerais au prochain bogue de ce type.

  1. Le bogue exige-t-il d’abord une erreur fatale ou un épuisement de mémoire ? Si oui, listez chaque étape de nettoyage que cet événement peut sauter.
  2. Un état survit-il à la requête suivante sur le même worker ? Cherchez les globales qui pointent encore vers une mémoire libérée par la requête.
  3. Quel SAPI exécute le code ? mod_php, FPM et la CLI peuvent différer, à la fois pour l’exposition et pour le comportement du nettoyage.
  4. Quels réglages prennent effet avant l’analyse de la requête ? Le ini par application et ini_set() peuvent ne pas suffire, selon l’avis de PHP sur CVE-2026-109619.
  5. Un backport de fournisseur a-t-il modifié le code sans modifier la chaîne de version ? Lisez le journal des modifications, pas le numéro.
  6. Peut-on lire chaque mesure dans le processus en cours ? Un fichier qui dit qu’un réglage est désactivé prouve moins qu’une lecture en direct.

Pour l’aspect embargo, la leçon est plus courte. Supposez que la date de publication peut bouger. Traitez les premières attaques comme possibles, pas impossibles. Mesurez votre délai de correctif en heures.

Le saviez-vous

  • Selon la chronologie de Calif, le premier bogue a été signalé à PHP le 11 août 2026, et les correctifs ont été publiés le 21 octobre, soit environ 71 jours plus tard.
  • La valeur par défaut de post_max_size est de 8 Mio, et celle de memory_limit est de 128 Mio. Calif affirme que quelques centaines d’enregistrements de fichiers vides suffisent à remplir le tas : la requête reste petite, mais son coût en mémoire reste énorme.
  • Krebs, citant Reuters, rapporte que des sites gouvernementaux en Europe sont tombés en panne après la divulgation. Les correctifs pressés cassent aussi des choses.

Ce que cela dit du portrait d’ensemble

PHP réinitialise l’état des requêtes à la main, un sous-système à la fois, et chaque réinitialisation sautée lors d’une erreur fatale devient son propre bogue. Les deux CVE suivent ce schéma. Je ne prétends pas que PHP soit particulièrement mauvais. Le mode de défaillance est structurel, et corriger une instance ne supprime pas la structure.

L’IA raccourcit aussi la distance. Wiz, cité par Krebs, affirme que les modèles d’IA de pointe ont « considérablement réduit » la barrière pour transformer ces failles en exploits. Calif dit avoir utilisé des audits assistés par IA, et il est franc : bien connaître la cible a compté davantage que le modèle. C’est la phrase la plus utile de toute cette divulgation, car elle signifie que la compétence rare reste le contexte, et non le bogue.

Lisez aussi les mises en garde des fournisseurs en gardant leurs intérêts en tête. Sansec vend un bouclier pour Magento et affirme que l’application d’un correctif peut causer des pannes. Cela ne rend pas ses mises en garde fausses. Sa révision du 22 octobre, qui a nuancé l’alarme sur l’exploitation massive, mérite le même examen que son premier rapport.

Qu’est-ce qui change ensuite ? Les embargos se raccourcissent sans disparaître. La sortie de PHP a été avancée une fois les détails fuités. Le délai entre un correctif et un exploit fonctionnel se mesure maintenant en heures. Les équipes qui suivront le rythme sont celles qui ont un inventaire à jour, un chemin de déploiement rapide et l’habitude de vérifier ce qui tourne réellement, plutôt que ce qu’elles croient faire tourner.

Sources

À lire aussi