PHP2Shell : une faille RCE dans PHP déclenche des millions de tentatives d'exploitation (CVE-2026-109618)

En bref

PHP2Shell est le nom utilisé par les chercheurs et les éditeurs pour deux failles d'exécution de code à distance au niveau du moteur, dans le cycle de vie des requêtes PHP.

• Deux failles de sûreté mémoire dans le moteur PHP lui-même, CVE-2026-109618 (la gestion du manque de mémoire corrompt l'état de la requête) et CVE-2026-109619 (un état global périmé subsiste jusqu'à la requête suivante), permettent à un attaquant distant non authentifié d'exécuter du code sous l'identité du worker web. Ces failles se situent sous les applications : une installation saine de WordPress, Drupal ou Joomla est exposée de la même manière.
• Toute installation PHP non corrigée qui traite des requêtes web est affectée : PHP-FPM, Apache mod_php, php-cgi, FrankenPHP et LiteSpeed. L'équipe de sécurité PHP classe les deux failles comme critiques, CVSS v4.0 9.2, et a confirmé une exécution complète de code à distance via HTTP contre mod_php avec les limites par défaut.
• Les tentatives d'exploitation ont bondi dans les heures suivant la divulgation et atteint des millions le 22 octobre (Cloudflare). Les leurres MadPot d'Amazon ont observé une première tentative le 17 octobre, quatre jours avant la divulgation.
• La CISA a ajouté les deux failles à son catalogue Known Exploited Vulnerabilities (KEV) le 26 octobre, avec une échéance fédérale de correction au 29 octobre.
• Le 24 octobre, Adel Karimi a confirmé l'exécution de code à distance contre des leurres : « Il s'agit désormais d'une RCE confirmée avec une divulgation mémoire exploitable, pas simplement d'un plantage suivi d'un processus suspect. » Un exploit public a remporté le défi StealMyBitcoin le 25 octobre. Au 27 octobre, aucune compromission d'une victime réelle n'est publiquement confirmée (Sophos, Previdian, Wordfence).
• Installez immédiatement PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 ; l'inscription au KEV impose une échéance. PAN-OS 10.2, 11.1, 11.2, 12.1 et 12.2 embarquent un PHP affecté ; Palo Alto Networks a publié 11 branches de correctifs et prévoit le reste d'ici le 30 octobre. Si vous ne pouvez pas mettre à jour aujourd'hui, les atténuations ci-dessous ne font que gagner du temps.

Suis-je concerné ?

Vous êtes concerné si ces deux conditions sont réunies :

• L'installation utilise PHP 5.4 ou ultérieur et traite des requêtes web via PHP-FPM, Apache mod_php, php-cgi, FrankenPHP ou LiteSpeed. Les installations uniquement en ligne de commande qui n'analysent jamais de corps de requête se trouvent hors des chemins démontrés.
• Pour PHP 8.2 à 8.5, la version est antérieure à la publication de sécurité du 21 octobre 2026 pour sa branche. PHP 7.4, 8.0 et 8.1 sont en fin de vie et affectés en principe ; l'équipe de sécurité a publié des rétroportages minimaux du code source pour ces versions. PHP 5.4 à 7.3 sont également affectés en principe, selon Sysdig, sans rétroportage du projet PHP.

Même si votre application n'appelle jamais les API de corps de requête, ne vous croyez pas à l'abri : l'exploit mod_php confirmé se déclenche au démarrage de la requête, avant toute exécution de code propre à l'application.

Vérifiez les versions utilisées sur l'hôte ainsi que dans chaque conteneur et image CI :

php -v
php -i | grep -E '^(memory_limit|post_max_size|session.upload_progress.enabled)'
apachectl -M 2>/dev/null | grep -i php      # Apache mod_php loaded?
php-fpm -v                                  # FPM pool version
docker ps --format '{{.Image}}' | sort -u   # images behind running containers
docker exec <container-name> php -v         # PHP inside a running container
docker images | grep php                    # locally pulled PHP image tags

Pour la CI, vérifiez l'image réellement construite par le pipeline, par exemple docker run --rm <registry>/<image>:<tag> php -v.

Palo Alto Networks indique que PAN-OS 10.2, 11.1, 11.2, 12.1 et 12.2 sont affectés via leur PHP embarqué. L'exposition concerne uniquement le plan de gestion : l'interface web HTTPS et l'API XML. PAN-OS les sert sur l'interface de gestion ou sur toute interface du plan de données associée à un profil de gestion. Les portails et passerelles GlobalProtect, Clientless VPN et le portail captif ne sont pas affectés.

Onze branches de correctifs sont publiées au 27 octobre ; la liste complète figure dans le tableau de l'avis et dans la chronologie ci-dessous. Les neuf branches restantes ont des dates prévues du 27 au 30 octobre 2026. Palo Alto classe l'impact sur ses propres produits comme élevé, CVSS 8.7. Son SaaS Cortex XCORE était affecté et a été corrigé le 21 octobre.

L'exposition est mesurée, pas estimée. Qualys a analysé les données anonymisées de 12 000 clients :

• Seules 199 000 instances PHP avaient été corrigées dans les 12 heures suivant la divulgation.
• Environ 110 millions d'instances, soit 71 pour cent des instances PHP mesurées par Qualys, utilisent PHP 5.4 à 8.1 en fin de vie, qui ne recevront jamais de correctif de l'éditeur.
• 44 millions supplémentaires utilisent des branches prises en charge dont les correctifs n'avaient pas encore été appliqués.

Censys suit la partie exposée sur Internet de ce retard dans un tableau de bord public et comptait plus de 32.51 millions de services PHP utilisant encore une version affectée au 27 octobre.

Comment corriger le problème ?

Installez la version corrigée de votre branche. Privilégiez les paquets de votre distribution pour maintenir la cohérence des intégrations SAPI :

# Debian and Ubuntu (upgrades every installed php* package and Apache's mod_php)
sudo apt update
sudo apt install --only-upgrade $(dpkg -l 'php*' 'libapache2-mod-php*' | awk '/^ii/ {print $2}')
# RHEL, CentOS Stream, Rocky, Alma, Fedora
sudo dnf update 'php*'
# Containers: rebuild on a fixed tag and recreate the service
docker pull php:8.4.27
docker compose build --pull && docker compose up -d

Redémarrez chaque worker PHP et le serveur web après la mise à jour. Si vous compilez depuis les sources ou utilisez une branche en fin de vie, appliquez les rétroportages 7.4, 8.0 et 8.1 de l'équipe de sécurité, ou migrez vers une branche prise en charge.

Si vous ne pouvez pas encore effectuer la mise à jour, ces mesures issues de l'avis PHP réduisent des chemins d'attaque précis. Aucune ne rend l'installation sûre, et l'avis le précise explicitement.

Pour CVE-2026-109618, supprimez la limite mémoire contrôlable et réduisez la surface d'entrée :

; PHP-FPM pool (for example www.conf); php_admin_value stops apps from overriding it
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M   ; use 32M if you need file uploads

Avec Apache mod_php, définissez les mêmes valeurs dans la configuration Apache :

php_admin_value memory_limit -1
php_admin_value post_max_size 8M

Également :

• Maintenez upload_max_filesize sous post_max_size.
• Imposez au niveau du serveur web ou du proxy des limites sur la taille décodée des requêtes, le nombre de champs d'entrée, de parties multipart et d'en-têtes, ainsi que la profondeur d'imbrication, y compris pour les requêtes sans Content-Length exploitable.

N'utilisez pas RLIMIT_AS ou RLIMIT_DATA : forcer l'échec de mmap() atteint directement le chemin d'abandon vulnérable.

Pour CVE-2026-109619, dans php.ini :

session.upload_progress.enabled = 0
; PHP 8.5 only:
fatal_error_backtraces = 0

Dans un pool PHP-FPM, utilisez plutôt la syntaxe du pool, puis redémarrez les workers :

php_admin_value[session.upload_progress.enabled] = 0
; PHP 8.5 only:
php_admin_value[fatal_error_backtraces] = 0

Trois étapes supplémentaires :

• Ne vous fiez pas à ini_set(), .user.ini, error_reporting, @ ou display_errors=Off ; l'avis indique que le consommateur s'exécute avant leur prise d'effet.
• Supprimez les paramètres INI invalides ou obsolètes appliqués par requête, et corrigez les erreurs fatales et dépassements de temps d'exécution accessibles à l'attaquant.
• Envisagez pm.max_requests = 1 si les performances le permettent.

Ce paramètre FPM n'aide que contre CVE-2026-109619, car il empêche une seconde requête d'atteindre le même worker ; il ne protège pas contre CVE-2026-109618, qui est déclenchée et consommée dans une seule requête.

Quelle est la cause profonde ?

Les deux failles résultent du mécanisme d'abandon de PHP, un longjmp() qui interrompt une requête depuis les profondeurs du moteur, combiné à un état conservé entre les requêtes par un worker de longue durée.

CVE-2026-109618 : PHP interrompt la requête avec longjmp() lors d'une erreur de manque de mémoire (OOM). La mémoire de la requête est parfois accessible avant d'être entièrement initialisée. Si une allocation échoue à ce moment, l'avis précise : « PHP ne tient pas correctement compte de la sortie anticipée et laisse la mémoire de la requête dans un état invalide. L'allocation échouée n'a pas besoin d'être liée à la mémoire invalide. La procédure de fermeture de la requête peut alors la lire ou effectuer un branchement en fonction de celle-ci. »

L'attaquant n'a pas besoin d'une véritable pénurie de mémoire. Plusieurs particularités de l'analyse multipart permettent à une seule requête HTTP d'épuiser memory_limit à la demande :

• Un corps multipart sans Content-Length exploitable passe le contrôle initial de post_max_size tout en continuant à fournir des données.
• Une seule partie peut contenir un nombre illimité d'en-têtes dont la représentation en mémoire est bien plus volumineuse que le format transmis.
• Des champs de fichier vides créent des tableaux de métadonnées sans être comptabilisés dans max_file_uploads.

CVE-2026-109619 : le worker conserve un état global (erreurs, sessions, objets et extensions) qui pointe temporairement vers de la mémoire appartenant à la requête et doit être réinitialisé avant la libération du tas de la requête. Deux modes de défaillance empêchent cette réinitialisation :

• Une erreur fatale, y compris l'épuisement de mémoire ou Maximum execution time exceeded, peut abandonner une opération avant sa réinitialisation.
• Un diagnostic non fatal tardif peut repeupler un état d'erreur déjà effacé.

Le tas est ensuite libéré alors que la variable globale du worker y fait toujours référence.

Deux consommateurs confirmés lisent cet état périmé avant l'initialisation de la requête suivante :

• Les avertissements émis lors de l'application des paramètres INI. Avec mod_php, .htaccess et les directives Apache php_value s'exécutent avant php_request_startup().
• Le traitement de la progression de téléversement de session, qui atteint l'état de session avant son initialisation normale. Il est activé par défaut et ne nécessite aucun appel à session_start().

Comment les failles sont-elles exploitées ?

L'attaque CVE-2026-109618 est une requête multipart spécialement conçue qui épuise memory_limit au démarrage. Une allocation échouée déclenche un abandon alors que la mémoire de la requête est à moitié initialisée, puis la fermeture mod_php lit cet état invalide avant toute exécution de code applicatif.

Une preuve de concept publique existe, mais elle est calibrée pour le build Alpine du défi StealMyBitcoin et s'arrête sur les autres builds. Aucun exploit publié ne fonctionne tel quel contre des builds de production. VulnCheck documente sa propre chaîne qui fonctionne sur des systèmes x86-64 configurés pour la production, décrite ci-dessous. Des outils fonctionnels existent aussi sur l'infrastructure d'attaquants. Le chemin mod_php confirmé, étape par étape :

1. L'attaquant envoie une requête multipart conçue pour épuiser memory_limit au démarrage de la requête : aucun Content-Length exploitable, et une partie avec un très grand nombre d'en-têtes, ou des champs de fichier vides créant des tableaux de métadonnées sans compter dans max_file_uploads.
2. Une allocation échoue et PHP abandonne avec longjmp() alors que la mémoire de la requête est à moitié initialisée.
3. mod_php exécute inconditionnellement la procédure de fermeture de la requête malgré l'échec du démarrage : la fermeture traite donc l'état invalide avant toute exécution de code applicatif.
4. Un tas agencé stratégiquement transforme les lectures et branchements sur l'état invalide en détournement du flux de contrôle, et l'attaquant exécute du code sous le compte du worker web.

Pour CVE-2026-109619, l'attaque nécessite deux requêtes sur le même worker :

• Producteur et consommateur : une requête productrice publie un état appartenant à la requête, puis se termine fatalement (OOM, expiration, échec d'analyse). Une requête consommatrice atteint l'état périmé avant que l'initialisation ne le réinitialise.
• Cas démontré le plus puissant : une erreur fatale avec fatal_error_backtraces activé stocke un état de trace de pile que la fermeture ne réinitialise jamais.
• Chemin de session : un téléversement initialise précocement l'état de session et du décodeur, un OOM abandonne la réinitialisation, et le traitement de progression de téléversement de la requête suivante consomme les pointeurs pendants.

Deux éditeurs ont documenté des outils fonctionnels :

• SOCRadar : un exploit présenté comme utilisable en un clic pour PHP 8.4.26 sous mod_php, trouvé sur un serveur d'attaquant exposé. Il recycle le worker, divulgue des adresses via le cookie de session pour contourner l'ASLR et utilise la progression de téléversement de session pour exécuter une commande shell. Le serveur contenait aussi des scripts de reconnaissance visant environ 20 sites, dont aucun ne satisfaisait les préconditions de l'exploit au 22 octobre.
• VulnCheck : une chaîne des deux CVE qui divulgue de la mémoire pour contourner l'ASLR et obtient l'exécution de code sur PHP 8.4.26 sous x86-64 avec l'ASLR activé et display_errors=off, le paramètre recommandé en production. VulnCheck indique ne connaître aucun autre exploit public ou commercial faisant de même.

Comment se déroule la chaîne d'exploitation de CVE-2026-109618 ?

La séquence allant du manque de mémoire à l'exécution de code sur mod_php, de bout en bout :

Que peut faire un attaquant ?

Une exploitation réussie permet une exécution de code à distance non authentifiée avec les privilèges du worker web : lecture des clés API, identifiants de base de données, variables d'environnement et fichiers accessibles au worker, ainsi qu'un point d'appui pour progresser, comme le décrit VulnCheck. Conditions requises :

• Un accès réseau au point de terminaison PHP, rien d'autre. Aucune authentification ni interaction utilisateur.
• Les conditions qui élèvent la complexité d'attaque CVSS au niveau élevé : un worker qui reste actif entre les requêtes et, pour le chemin OOM, soit une valeur finie de memory_limit que l'attaquant peut atteindre, soit une allocation dont il peut provoquer l'échec.
• L'appariement des requêtes sur le même worker pour CVE-2026-109619 ; des workers supplémentaires et leur recyclage réduisent la fiabilité mais ne suppriment pas la condition, selon l'avis.

Quels éditeurs sont affectés ?

Les produits embarquant PHP héritent de l'exposition, et la liste des avis d'éditeurs s'est fortement élargie. Palo Alto Networks a confirmé que PAN-OS 10.2, 11.1, 11.2, 12.1 et 12.2 sont affectés via PHP embarqué. Il classe l'impact sur ses produits comme élevé, CVSS 8.7, avec 11 branches de correctifs publiées au 27 octobre et le reste prévu du 27 au 30 octobre 2026.

Au-delà de PAN-OS, les avis mentionnant l'impact de PHP2Shell couvrent désormais des dizaines d'éditeurs, notamment :

• Réseau et sécurité : Arista Networks, F5, Huawei, NETGEAR, SonicWall
• Infrastructure et stockage : Broadcom, Dell, HPE, IBM, QNAP, Synology, Veeam
• Logiciels et SaaS : Citrix, Ivanti, Okta, Salesforce, Splunk

Des projets CMS comme Drupal, Craft CMS et WordPress ont aussi publié des avis.

Côté industriel, SecurityWeek rapporte les états suivants :

• Schneider Electric a corrigé EcoStruxure Security Expert 1.48.4.0 ainsi que ses produits ProLeiT LINEoptimize et EcoStruxure Control Engineering.
• Siemens a indiqué que Ruggedcom APE1808 était affecté via son PAN-OS embarqué et publié une liste de produits non affectés.
• Un système d'exécution de fabrication ABB intégrant DokuWiki a été signalé.
• B&R a indiqué que les versions APROL jusqu'à R4.4-65 étaient affectées.
• Rockwell Automation et Johnson Controls poursuivaient leur évaluation.

Si vous exploitez des équipements de ces éditeurs, vérifier les correctifs exige désormais de consulter leurs avis, pas seulement vos versions PHP.

Pourquoi le correctif fonctionne-t-il ?

Un seul commit, 3584a98bda (« Éviter la corruption d'état par abandon », écrit le 18 octobre 2026, fusionné le 21 octobre), corrige les deux CVE. Son message nomme précisément les deux changements :

- Replace bailout on OOM with UnwindExit
- Properly reset various globals that may be accessed during startup

Pour le chemin OOM, le correctif supprime l'abandon par longjmp() comme réponse au manque de mémoire. Un OOM léger est désormais enregistré et différé jusqu'au prochain point sûr de la machine virtuelle :

EG(delayed_oom).message = zend_string_init(buf, strlen(buf), /* persistent */ true);
GC_MAKE_PERSISTENT_LOCAL(EG(delayed_oom).message);
zend_string_addref(script_filename);
EG(delayed_oom).filename = script_filename;
EG(delayed_oom).lineno = script_lineno;
EG(delayed_oom).state = ZEND_OOM_STATE_PENDING;
zend_atomic_bool_store_ex(&EG(vm_interrupt), true);

La procédure de fermeture ne peut plus observer un état partiellement initialisé, car l'OOM est traité à un point où l'exécuteur est cohérent. Le correctif ajoute également une limite mémoire stricte au-dessus de memory_limit : par défaut deux fois memory_limit, ou memory_limit plus 1 Gio lorsque la limite dépasse 1 Gio. Une allocation qui la dépasserait termine immédiatement le processus avec _exit() au lieu de dérouler la pile.

Pour le chemin de l'état périmé, le correctif réinitialise les variables globales appartenant à la requête à la fin de chaque requête. Aucun élément lu par la requête suivante avant son initialisation normale ne pointe encore vers de la mémoire libérée. Par exemple, la fermeture de l'exécuteur efface désormais l'état d'erreur et d'exception :

/* may be used by zend_error_zstr_at before init_executor */
EG(record_errors) = false;
EG(num_errors) = 0;
EG(errors) = NULL;
EG(error_handling) = EH_NORMAL;
EG(exception) = NULL;

Le correctif couvre entièrement les chemins démontrés, et l'avis précise que la réinitialisation plus large de l'état est préventive : d'autres familles d'états d'erreurs, d'exceptions, d'objets et d'extensions sont couvertes, mais leur accessibilité dépendait des producteurs et consommateurs de chaque application.

Comment vérifier si j'ai été compromis ?

Surveillez ces cinq signaux dans les journaux et fichiers de session. Chacun justifie une enquête, et aucun ne nécessite l'accès au code applicatif.

• Dans les journaux du serveur web et de PHP-FPM : rafales de requêtes multipart sans Content-Length ou avec une valeur inutilisable, erreurs de segmentation répétées des workers ou arrêts OOM sur des requêtes n'ayant jamais atteint le code applicatif, et Maximum execution time exceeded sur des routes accessibles à l'attaquant.
• Des fichiers de session PHP contenant du code inattendu : VulnCheck a observé une adresse IP située en Chine tentant de déposer un web shell via des fichiers de session côté serveur.
• Des champs de progression de téléversement de session dans les requêtes multipart : la preuve de concept gagnante de StealMyBitcoin déclenche son étape OOM dans l'analyse de cette progression, et les sondes observées utilisent aussi ces champs. Cela fait de session.upload_progress.enabled = 0 une atténuation dont la pertinence est démontrée.
• Un trafic ultérieur de la famille Mirai : Sophos a relié des tentatives à la variante de botnet Potassium, avec des connexions vers 134.199.154.64 sur le port TCP 50792 et des résolutions DNS pour thunder.godofthunder.st ; Wordfence a publié les adresses IP sources suivies.
• L'énumération de variables d'environnement et d'identifiants depuis les workers web, décrite par plusieurs éditeurs comme l'objectif de la vague de scans.

Au 27 octobre, aucune compromission d'une victime réelle n'est publiquement confirmée. Les preuves d'exploitation se sont consolidées les 24 et 26 octobre, mais les démonstrations confirmées visaient des cibles configurées pour être exploitables, pas des victimes.

Adel Karimi a vérifié une exécution complète de code à distance contre ses leurres mod_php à worker unique le 24 octobre. Il a rapporté « un dump de cookie décodé de 800 Kio, et une adresse de fonction dérivée de ce dump à l'aide des décalages de l'exploit public apparaît dans la charge utile d'exécution suivante ».

Le défi StealMyBitcoin, une cible PHP 8.4.26 délibérément vulnérable assortie d'un prix de 0.0251 BTC, a été remporté le 25 octobre après 19.28 heures. La preuve de concept publique divulgue des adresses du tas et du code, contourne l'ASLR et forge une HashTable pour atteindre zif_system en au plus 20 requêtes. Ses décalages sont calibrés pour le build Alpine du défi, et l'exploit s'arrête à l'étape de divulgation du code sur les autres builds.

Unit 42 de Palo Alto Networks a rapporté le 25 octobre qu'une entité gouvernementale européenne avait été compromise via ces failles, puis a retiré cette attribution le même jour. L'entreprise avait observé « une attaque contre une agence gouvernementale européenne exécutée dans le contexte d'une application PHP vulnérable », mais n'était « pas en mesure de confirmer que l'accès initial était associé aux CVE PHP2Shell précises », a-t-elle déclaré à The Hacker News.

Chronologie

• Depuis 2012 : les chemins de code vulnérables existent à partir de PHP 5.4, selon l'analyse de Sysdig.
• 2026-10-17 : première tentative d'exploitation observée rétrospectivement par le réseau de leurres MadPot d'Amazon, quatre jours avant la divulgation.
• 2026-10-20 : PHP publie un préavis de version critique prévue pour le 21 octobre à 14:00 UTC, les deux failles étant notées CVSS v4.0 9.2.
• 2026-10-21 : PHP publie 8.5.12, 8.4.27, 8.3.36 et 8.2.35 avec les avis GHSA-w8hw-w9fx-j79w et GHSA-6wmf-4rv5-p3rp. Previdian enregistre sa première tentative d'exploitation à 13:05 UTC ; Cloudflare compte des dizaines de milliers de tentatives dans les 45 minutes suivant la publication, puis des millions au début du 22 octobre. Palo Alto Networks publie son avis PAN-OS.
• 2026-10-22 : le Royaume-Uni confirme la mise hors ligne préventive de 32 services numériques et le NCSC émet environ 50 000 avertissements ; Sophos documente une preuve de concept publique et les tentatives Potassium.
• 2026-10-23 : SOCRadar documente un outil d'exploitation en un clic sur un serveur d'attaquant ; Censys compte plus de 34.4 millions de services PHP encore vulnérables ; PHP publie un avis informatif sur CVE-2026-115560, apparentée et toujours non corrigée, recommandant session.upload_progress.enabled=0 jusqu'à la prochaine version régulière.
• 2026-10-24 : Palo Alto Networks met à jour son avis avec des dates prévues de correctifs par branche du 27 au 30 octobre ; Adel Karimi confirme une exécution complète de code à distance contre des leurres mod_php à worker unique, avec une divulgation mémoire exploitable et une charge utile exécutée dérivée des adresses divulguées.
• 2026-10-25 : première publication de cet article. Palo Alto Networks publie les trois premiers correctifs PAN-OS (10.2.18-h13, 11.1.16-h4, 11.2.10-h16) ; Unit 42 signale, puis retire le même jour, l'attribution d'une compromission gouvernementale présumée à ces failles ; le défi StealMyBitcoin, une cible PHP 8.4.26 délibérément vulnérable, est remporté après 19.28 heures par une preuve de concept publique contournant l'ASLR.
• 2026-10-26 : quatre correctifs PAN-OS supplémentaires sont publiés (11.1.4-h38, 11.1.6-h40, 11.1.10-h36, 11.1.13-h16) ; la CISA ajoute CVE-2026-109618 et CVE-2026-109619 à son catalogue KEV avec une échéance fédérale au 29 octobre.
• 2026-10-27 : Palo Alto Networks publie 10.2.13-h27, 10.2.16-h12, 12.1.7-h11 et 12.2.4-h1, portant le nombre de branches publiées à onze ; une discussion oss-security montre des opérateurs de builds PHP 5.4 à 5.6 personnalisés rétroportant le correctif en privé ; cet article est mis à jour avec l'inscription au KEV et la liste des avis d'éditeurs.

FAQ

PHP-FPM est-il aussi exposé que mod_php ?

Les deux sont affectés, mais différemment. mod_php est la cible confirmée sans prérequis propres à l'application, car il exécute la fermeture de requête même après un échec de démarrage. FPM termine un processus enfant lorsque le démarrage échoue, ce qui bloque cette séquence précise, mais l'avis valide un chemin FPM distinct qui publie un état pendant l'exécution de l'application et le consomme lors d'une requête ultérieure de progression de téléversement. L'analyse du code source laisse également FPM vulnérable au chemin OOM.

Désactiver l'affichage ou la journalisation des erreurs me protège-t-il ?

Non. L'avis précise que l'état global est accédé avant que PHP décide de signaler, afficher ou journaliser un avertissement, et avant la prise d'effet de error_reporting, @ ou display_errors. Ces paramètres ne changent que ce que vous voyez, pas ce que le moteur fait de l'état périmé.

Mon site utilise un code applicatif sain et à jour. Suis-je protégé ?

Non. Les failles se trouvent dans le moteur, donc la qualité du code applicatif ne change pas l'exposition. Sysdig souligne que tout site WordPress, Drupal ou Joomla est exposé quelle que soit la qualité de son code, et Censys comptait plus de 34.4 millions de services PHP encore vulnérables le 23 octobre.

Qu'en est-il de la troisième faille, CVE-2026-115560 ?

Elle est réelle mais limitée, et non corrigée au 27 octobre. L'exploitation nécessite une application qui définit session.serialize_handler sur php_binary ou php_serialize dans sa configuration, puis le remet à php à l'exécution avec ini_set() avant d'appeler session_start(), tout en conservant la progression de téléversement de session activée. PHP la corrige dans la prochaine version régulière ; d'ici là, conservez session.upload_progress.enabled=0, déjà recommandé par l'avis du 21 octobre pour CVE-2026-109619.

Existe-t-il un exploit fonctionnel dans la nature ?

Traitez ces failles comme exploitées. La CISA a ajouté les deux à son catalogue KEV le 26 octobre, confirmant une exploitation active, et les leurres de Karimi ont enregistré une RCE complète le 24 octobre. Aucune compromission d'une victime réelle n'est encore confirmée.

La chaîne de VulnCheck fonctionne contre des systèmes x86-64 configurés pour la production. Le gagnant de StealMyBitcoin ciblait un build délibérément vulnérable avec des décalages calibrés. Interprétez chaque résultat selon ce qu'il démontre, pas comme un nombre de victimes, et appliquez les correctifs avant l'échéance KEV.

Dois-je corriger si PHP ne sert qu'à des scripts en ligne de commande ?

Les chemins d'attaque démontrés nécessitent l'analyse de corps de requête : une installation exclusivement en ligne de commande se trouve donc hors de leur périmètre. Mettez quand même à jour : les versions corrigées apportent le durcissement de réinitialisation d'état, et les hôtes en ligne de commande acquièrent souvent un point de terminaison web par la suite.

Inventoriez votre exposition PHP

Utilisez Ostorlab Attack Surface Discovery pour inventorier les domaines et hôtes exposés sur Internet qui vous appartiennent. Comparez leurs versions PHP et les avis des équipements aux plages affectées ci-dessus, y compris les branches en fin de vie et PHP embarqué, puis vérifiez les correctifs sur chaque instance.

Références

• Avis de sécurité PHP, « Avis de sécurité : vulnérabilités critiques d'exécution de code à distance, mettez à jour maintenant », 21 octobre 2026, avec les descriptions des deux CVE et la liste de contournements incomplets : https://www.php.net/archive/2026.php#2026-10-21-5 (consulté le 25 octobre 2026)
• GHSA-w8hw-w9fx-j79w, « RCE par corruption OOM », stratégies OOM complètes, vulnérabilité des SAPI et description du correctif : https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w (consulté le 25 octobre 2026)
• GHSA-6wmf-4rv5-p3rp, « RCE par état global périmé », modèle producteur-consommateur, cas confirmés et atténuations : https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp (consulté le 25 octobre 2026)
• Fiche CVE-2026-109618 avec le vecteur CVSS v4.0 9.2 et les crédits (Ryan chez Calif.io, Wiz et OpenAI pour les signalements ; Arnaud Le Blanc, Ilija Tovilo et Jakub Zelenka pour le développement de la correction) : https://cveawg.mitre.org/api/cve/CVE-2026-109618 (consulté le 25 octobre 2026)
• Fiche CVE-2026-109619 avec le vecteur CVSS v4.0 9.2 : https://cveawg.mitre.org/api/cve/CVE-2026-109619 (consulté le 25 octobre 2026)
• Commit de correction 3584a98bda, « Éviter la corruption d'état par abandon », remplaçant l'abandon OOM et réinitialisant les variables globales accédées au démarrage : https://github.com/php/php-src/commit/3584a98bda (consulté le 25 octobre 2026)
• Avis informatif PHP sur la progression de téléversement de session et CVE-2026-115560, 23 octobre 2026 : https://www.php.net/archive/2026.php#2026-10-23-1 (consulté le 25 octobre 2026)
• Catalogue KEV de la CISA : CVE-2026-109618 et CVE-2026-109619 ajoutées le 26 octobre 2026, échéance au 29 octobre 2026, avec l'action fédérale requise et la référence BOD 26-04 : https://www.cisa.gov/known-exploited-vulnerabilities-catalog (consulté le 27 octobre 2026 via le flux JSON du catalogue)
• The Hacker News, « La CISA confirme l'exploitation active de deux failles PHP2Shell permettant l'exécution de code à distance », 27 octobre 2026, reprenant les citations de Karimi sur la RCE dans ses leurres, le chiffre Censys de 32.51 millions et la liste élargie d'avis d'éditeurs : https://thehackernews.com/2026/10/cisa-confirms-active-exploitation-of.html (consulté le 27 octobre 2026)
• Rapports de preuves des leurres PHP2Shell d'Adel Karimi, dont le jeu de données du 24 octobre confirmant la RCE : https://github.com/0x4D31/honeypot-data (référencé via The Hacker News et SecurityWeek, consulté le 27 octobre 2026)
• Site du défi StealMyBitcoin, documentant la victoire du 25 octobre après 19.28 heures et le prix de 0.0251 BTC, et preuve de concept publique gagnante avec son tableau d'étapes et ses réserves sur le calibrage du build : https://stealmybitcoin.com/ et https://github.com/KillaBoi/StealMyBitcoin-PoC (consulté le 27 octobre 2026)
• SecurityWeek sur les industriels vérifiant leurs produits face à PHP2Shell, 26 octobre 2026, avec les états Schneider, ProLeiT, Siemens Ruggedcom, ABB, B&R, Rockwell et Johnson Controls : https://www.securityweek.com/industrial-vendors-check-their-products-for-php2shell-vulnerabilities/ (référencé via The Hacker News, consulté le 27 octobre 2026)
• Discussion oss-security sur les correctifs PHP 5.4 à 5.6 rétroportés en privé pour CVE-2026-109618, 27 octobre 2026 : https://www.openwall.com/lists/oss-security/2026/10/27/1 (consulté le 27 octobre 2026)
• Avis Palo Alto Networks sur l'impact de CVE-2026-109618 et CVE-2026-109619 sur PAN-OS, avec onze branches de correctifs publiées selon le journal du 27 octobre et le reste prévu du 27 au 30 octobre : https://security.paloaltonetworks.com/CVE-2026-109618 (consulté le 27 octobre 2026)
• The Hacker News rapportant le retrait par Unit 42, le 25 octobre, de l'attribution de la compromission gouvernementale, avec la déclaration du porte-parole : https://thehackernews.com/2026/10/php2shell-exploitation-hits-government.html (consulté le 26 octobre 2026)
• Sophos sur la preuve de concept publique et les tentatives infructueuses de la variante Mirai Potassium : https://www.sophos.com/en-us/blog/proof-of-concept-exploit-released-for-php-vulnerabilities-109618-109619 (via The Hacker News, 23 octobre 2026 : https://thehackernews.com/2026/10/php2shell-exploit-attempts-hit-millions.html, consulté le 25 octobre 2026)
• VulnCheck sur la chaîne d'exploitation contournant l'ASLR et la tentative de web shell dans un fichier de session : https://www.vulncheck.com/blog/php2shell-vulnerabilities (consulté le 25 octobre 2026)
• SOCRadar sur l'outil mod_php en un clic trouvé sur un serveur d'attaquant : https://socradar.io/blog/php2shell-exploit-tooling-attacker-server/ (consulté le 25 octobre 2026)
• Télémétrie Previdian pour les deux CVE, premier événement le 21 octobre à 13:05 UTC, aucune RCE réussie observée : https://previdian.com/CVE-2026-109618#telemetry (consulté le 25 octobre 2026)
• Compte rendu du Parlement britannique confirmant l'indisponibilité de 32 services numériques et les quelque 50 000 avertissements du NCSC : https://hansard.parliament.uk/Lords/2026-10-22/debates/14CB4C6D-4E16-4377-8FCF-C2CF77BB5CC0/details (consulté le 25 octobre 2026)
• Décompte Censys de plus de 34.4 millions de services PHP vulnérables au 23 octobre 2026 : https://php2shell.censys.com/ (consulté le 25 octobre 2026)
• SecurityWeek, « Les opérateurs de botnets Mirai rejoignent les attaques PHP2Shell alors que des exploits contournant l'ASLR émergent », 23 octobre 2026, reprenant l'analyse Qualys des correctifs chez 12 000 clients (199 000 instances corrigées en 12 heures ; environ 110 millions d'instances, soit 71 pour cent, sous PHP 5.4 à 8.1 en fin de vie ; 44 millions supplémentaires sur des branches prises en charge mais non corrigées) : https://www.securityweek.com/mirai-botnet-operators-join-php2shell-attacks-as-aslr-bypass-exploits-emerge/ (consulté le 26 octobre 2026)
• Analyse Qualys de la version critique d'octobre 2026 : https://blog.qualys.com/vulnerabilities-threat-research/2026/10/20/php-announces-critical-security-release-for-two-vulnerabilities (via SecurityWeek, 23 octobre 2026)
• Amazon sur les tentatives d'exploitation dès le 17 octobre contre ses leurres MadPot : https://thehackernews.com/2026/10/someone-tried-to-exploit-php2shell-4.html (consulté le 25 octobre 2026)
• Sysdig sur le code vulnérable remontant à PHP 5.4 (2012) : https://www.sysdig.com/blog/php2shell-cve-2026-109618-and-cve-2026-109619-detecting-unauthenticated-remote-code-execution-in-php-core (consulté le 25 octobre 2026)