PHP2Shell : ce qu'il faut savoir et faire maintenant

Le 21 octobre 2026, le projet PHP a publié en urgence les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Elles corrigent deux vulnérabilités critiques du moteur lui-même, CVE-2026-109618 et CVE-2026-109619, regroupées sous le nom PHP2Shell. Chacune est notée 9,2 en CVSS v4.0 et permet une exécution de code à distance sans authentification (annonce php.net). Des tentatives d'exploitation ont été observées dès le 17 octobre, quatre jours avant la divulgation (AWS).

Cet article rassemble uniquement des informations publiées par le projet PHP, les chercheurs à l'origine de la découverte, des autorités (CERT-FR, CERT-EU, Cybermalveillance.gouv.fr) et des fournisseurs d'infrastructure. Chaque affirmation renvoie à sa source.

En bref

• Qui est concerné : toute installation PHP qui sert des requêtes web, que ce soit PHP-FPM, Apache avec mod _php, php-cgi, FrankenPHP ou LiteSpeed. Le projet PHP juge le risque le plus élevé pour mod _php : un exploit démontré y déclenche l'attaque avant toute exécution de code applicatif (php.net).

• Action 1, mettre à jour : passer en 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou appliquer le paquet corrigé de votre distribution. Ensuite, redémarrer tous les workers PHP et vérifier que le correctif est bien chargé.

• Action 2, traiter les versions en fin de vie : PHP 8.1 et antérieures ne reçoivent pas de version officielle. Il faut un backport de votre fournisseur, une migration, ou à défaut une isolation du service.

• Action 3, rechercher les traces d’une compromission : les investigations doivent remonter au 17 octobre, pas au 21.

• Nouveau au 23 octobre : php.net recommande de désactiver session.upload_progress.enabled jusqu'à la prochaine version de maintenance, même sur une installation corrigée (voir plus bas).

Les mesures de configuration réduisent l'exposition mais ne protègent pas : le projet PHP répète que la mise à jour est la seule solution complète (php.net).

Chronologie

Le défaut de fond était connu depuis 2024, mais l'exploitation a commencé avant la divulgation, après une fuite de l'embargo. Les heures sont en UTC (heure de Paris = UTC+2).

AWS qualifie désormais PHP2Shell d'exploité largement dans la nature. Le fournisseur Cloud précise aussi que l'on ignore si les tentatives observées sur ses honypots auraient réussi sur des systèmes réels (AWS).

Les deux vulnérabilités

Les deux failles touchent la gestion mémoire et le traitement d'erreurs du moteur, que presque chaque requête traverse. Elles ne dépendent d'aucune application en particulier (PHP Foundation).

Le vecteur CVSS indique une complexité d'attaque élevée (AC:H) et des prérequis de déploiement (AT:P). Cela décrit les conditions techniques à réunir, pas une protection : les chercheurs de Calif ont confirmé une exécution de code avant authentification sur WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony et WHMCS (Calif).

CVE-2026-109618 : corruption lors d'un manque de mémoire

Quand une requête atteint memory_limit, PHP abandonne son traitement avec longjmp(). Si cela arrive pendant qu'une structure interne n'est que partiellement initialisée, la procédure de fin de requête relit ensuite cet état invalide (GHSA-w8hw).

L'avis décrit plusieurs façons d'atteindre ce manque de mémoire sans dépasser les limites apparentes, toutes dans l'analyse des requêtes multipart :

• un corps sans longueur déclarée exploitable, qui passe le contrôle de post_max_size;
• un nombre illimité d'en-têtes par partie ;
• des champs de fichier vides, non comptés dans max_file_uploads, combinés à des noms de champs imbriqués.

Tout cela se produit pendant l'initialisation de la requête, avant l'exécution du code applicatif. Sous mod_php, la procédure de fin de requête s'exécute même si l'initialisation a échoué : c'est ce qui rend l'attaque indépendante de l'application. PHP-FPM, lui, termine le processus fils dans ce cas. L'avis juge néanmoins FPM vulnérable par analyse du code, sans exploit complet démontré pour ce chemin. La PHP Foundation indique de son côté une exécution de code confirmée sur FPM via des chemins applicatifs (PHP Foundation). FrankenPHP est jugé probablement vulnérable au même titre que mod_php, et LSAPI se comporte comme FPM.

Le correctif supprime longjmp() pour ce cas. Il le remplace par un arrêt différé au prochain point sûr de la machine virtuelle, et par un arrêt immédiat via _exit() au-delà d'un second seuil plus élevé.

CVE-2026-109619 : état global périmé

Un worker PHP conserve des états globaux (erreurs, session, objets, extensions) qui pointent vers la mémoire d'une requête. Si une erreur fatale interrompt une opération avant sa remise à zéro, la requête suivante traitée par le même worker peut utiliser cette mémoire déjà libérée (GHSA-6wmf).

L'exploitation demande deux requêtes sur le même worker : l'une laisse l'état périmé, l'autre le consomme avant l'initialisation normale. L'avis confirme deux consommateurs :

• les avertissements de configuration émis avant l'initialisation : directives INI invalides ou dépréciées appliquées par requête (.htaccess, php_value sous Apache, PHP_VALUE/PHP_ADMIN_VALUE transmis par le frontal à FPM). Masquer les erreurs avec error_reporting, display_errors ou @ ne protège pas ;
• la progression d'upload des sessions (session.upload_progress), activée par défaut et utilisable sans que l'application appelle session_start().

Deux cas sont confirmés. Le premier concerne PHP 8.5 avec fatal_error_backtraces activé, exploité sur mod_php. Le second concerne le cycle de vie de l'upload progress, exploité sur mod_php et sur FPM, ce dernier via une opération applicative adaptée.

Les failles remontent à loin : Calif fait remonter le chemin le plus ancien qu'il a trouvé à PHP 5.4.0 (Calif).

Suis-je concerné ?

Oui, si vous exécutez une version antérieure aux versions corrigées derrière un serveur web, quel que soit le mode d'exécution. Le projet PHP vise explicitement toutes les installations qui servent des requêtes web (php.net).

Par branche

Par mode d'exécution

• Apache + mod_php : risque le plus élevé. L'attaque fonctionne avec une seule requête non authentifiée, avant tout code applicatif (php.net).
• PHP-FPM : vulnérable. L'exécution de code y a été validée via le chemin des sessions, avec une opération applicative adaptée (GHSA-6wmf).
• FrankenPHP, LiteSpeed/LSAPI, php-cgi : concernés selon l'annonce officielle. Pour FrankenPHP, l'avis juge une attaque indépendante de l'application probable (GHSA-w8hw).

Le PHP que l'on oublie

De nombreux produits commerciaux et open source embarquent PHP sans l'afficher. Le CERT-EU recommande de consulter l'inventaire tenu par le NCSC néerlandais (CERT-EU, NCSC-NL). L'assureur Coalition cite notamment les consoles d'administration de bases de données, de pare-feu, de sauvegarde, de supervision et de téléphonie, ainsi que les panneaux cPanel et Plesk (Coalition). Ces interfaces détiennent souvent des identifiants vers d'autres systèmes : elles sont à traiter en priorité.

Pour les services gérés AWS, le bulletin 2026-143-AWS précise trois points :

• Elastic Beanstalk : mise à jour de la version de plateforme si les mises à jour gérées ne sont pas activées ;
• Lightsail : recréation des instances à partir des blueprints corrigés, AWS ne pouvant pas mettre à jour les instances en place ;
• Amazon Linux : application des paquets corrigés.

Plan d'action

La seule correction complète est la mise à jour, suivie du redémarrage de chaque processus PHP. Pour les incidents critiques sur des systèmes exposés, AWS recommande de mesurer les délais de correction en heures, et non plus en jours (AWS).

1. Inventorier

Listez chaque hôte, conteneur et appliance qui exécute PHP, avec sa version et son mode d'exécution. La version du binaire CLI (php -v) ne dit rien de celle réellement chargée par PHP-FPM ou par mod_php. Interrogez chaque composant et le gestionnaire de paquets :

Commencez par les systèmes exposés à Internet et par les interfaces d'administration.

2. Mettre à jour

• Paquets de distribution : les distributions et fournisseurs LTS ont reçu les correctifs avant la publication (CERT-EU). Leurs numéros de version ne correspondent pas forcément à ceux du projet PHP : vérifiez auprès du fournisseur que le correctif est inclus (Coalition).
• Dépôt d'Ondřej Surý (deb.sury.org) : le mainteneur a annoncé des paquets corrigés pour toutes les versions de PHP du dépôt, y compris les branches en fin de vie. Les architectures ARM sont construites après amd64, avec un délai qu'il estimait à environ deux jours le 21 octobre. Si le PPA Launchpad ne répond pas, il recommande de basculer sur packages.sury.org (issue #145).
• Compilation depuis les sources et Windows : sources et binaires sont sur la page de téléchargement de php.net.
• Images de conteneurs : reconstruisez l'image et redéployez. Une mise à jour dans un conteneur en cours d'exécution est perdue au prochain redémarrage.
• Services gérés et hébergement mutualisé : suivez le bulletin de votre fournisseur, par exemple le bulletin AWS.

3. Redémarrer et vérifier

Un paquet installé ne protège pas tant que les processus qui tournent utilisent l'ancien code. Redémarrez PHP-FPM ou Apache, puis contrôlez à la fois la version installée et la présence des CVE dans le journal des modifications du paquet :

Si le journal ne cite pas les CVE, la version n'est pas pour autant forcément vulnérable : certains mainteneurs les mentionnent autrement. Dans ce cas, comparez la version du paquet et sa date de construction avec l'annonce de votre fournisseur.

Sur ARM ou avec un dépôt tiers, vérifiez que le paquet installé est bien la version corrigée et non la précédente.

4. Versions en fin de vie (8.1 et antérieures)

Le projet PHP ne publie pas de version pour ces branches (php.net). Dans l'ordre :

1. Demandez un backport à votre distribution ou à votre fournisseur LTS.
2. Si vous compilez vous-même, utilisez les backports source publiés par l'équipe sécurité pour 7.4, 8.0 et 8.1.
3. Sans correctif disponible, isolez le service d'Internet le temps de migrer vers une branche maintenue. C'est la recommandation du CERT-FR, du CERT-EU et de Cybermalveillance.gouv.fr.

AWS indique qu'aucun correctif n'existe pour CVE-2026-109618 sur les branches en fin de vie (AWS), alors que les backports source ci-dessus couvrent les deux CVE. Faites confirmer par votre fournisseur ce que couvre précisément le paquet que vous installez.

Si vous ne pouvez pas mettre à jour immédiatement

Ces mesures réduisent l'exposition à des chemins d'attaque précis, mais aucune ne rend une installation sûre (php.net). Elles servent à tenir quelques heures, pas à remplacer la mise à jour.

Configuration

Appliquez ces réglages là où ils sont lus avant l'analyse de la requête : php.ini, pool FPM ou configuration du serveur. ini_set() et .user.ini ne conviennent pas (GHSA-6wmf). Redémarrez ensuite tous les workers.

Pour post_max_size, le projet PHP recommande 8M si l'application n'accepte pas de fichiers et 32M sinon, avec upload_max_filesize inférieur à post_max_size. Vérifiez qu'aucun pool, répertoire ou réglage applicatif ne réintroduit une limite mémoire finie (php.net).

Trois points méritent une attention particulière :

• memory_limit=-1 est à double tranchant. Il supprime le plafond mémoire de PHP et augmente le risque d'épuisement de la mémoire (Calif). Bornez la mémoire avec une limite cgroup ou conteneur, de préférence qui ne tue que le worker concerné. N'utilisez jamais RLIMIT_AS ni RLIMIT_DATA : ils provoquent justement l'échec d'allocation vulnérable (GHSA-w8hw).
• Les limites au frontal doivent couvrir les requêtes sans Content-Length exploitable, par exemple en chunked ou en HTTP/2. Limitez aussi la taille décodée, le nombre de champs, de parties et d'en-têtes, et la profondeur d'imbrication (php.net).
• Les directives INI par requête (.htaccess, php_value, PHP_VALUE transmis par le frontal) qui produisent des avertissements doivent être supprimées ou corrigées. Les masquer ne suffit pas (GHSA-6wmf).

Au niveau du WAF

AWS publie des règles AWS WAF à déployer d'abord en mode comptage, puis en blocage une fois validées. Elles bloquent les POST contenant PHP_SESSION_UPLOAD_PROGRESS, les requêtes multipart quand l'application n'en a pas besoin, les corps trop volumineux et les rafales de POST. AWS rappelle qu'un WAF ne voit ni les en-têtes internes de chaque partie, ni la mémoire du worker : c'est un complément, pas une correction (AWS). Le CERT-FR recommande aussi de bloquer les requêtes multipart ou, à défaut, de les surveiller (CERT-FR).

À garder même après la mise à jour

Le 23 octobre, php.net a publié un avis informatif sur une variante distincte, CVE-2026-115560. Il recommande de laisser session.upload_progress.enabled=0 jusqu'à la prochaine version de maintenance (php.net). Le risque est jugé peu probable : il suppose une application qui définit session.serialize_handler à php_binary ou php_serialize, puis le change en php avec ini_set() avant session_start(). Les applications qui ne changent jamais ce réglage à l'exécution peuvent garder la fonctionnalité. Si vous l'aviez déjà désactivée le 21 octobre, rien à faire de plus.

Détecter une tentative ou une compromission

Une installation mise à jour aujourd'hui a pu être compromise avant. AWS recommande de faire partir les investigations au moins du 17 octobre, date de la première tentative connue, et non de la date de divulgation (AWS).

Avant de corriger un hôte suspect

L'état exploité par CVE-2026-109619 vit dans la mémoire des workers (GHSA-6wmf), et un redémarrage l'efface. Si un hôte non corrigé présente des signes suspects, isolez-le et préservez les éléments (mémoire des processus, arborescence des processus, connexions réseau, journaux) avant de mettre à jour et de redémarrer.

Signaux à rechercher

AWS recommande de :

• chercher les requêtes POST contenant la chaîne PHP_SESSION_UPLOAD_PROGRESS dans des envois de formulaire. Cette chaîne est dans le corps de la requête, donc absente des journaux d'accès classiques : il faut des journaux WAF ou une capture des corps ;
• examiner les journaux du serveur web ;
• rechercher des exécutions de processus ou des modifications de fichiers inattendues sur les serveurs applicatifs (AWS).

Coalition, reprenant les recommandations de Wiz, ajoute plusieurs signaux (Coalition) :

• des processus PHP qui lancent un shell, curl ou wget ;
• des fichiers nouveaux ou modifiés dans la racine web, de nouvelles tâches cron ou de nouveaux comptes ;
• des envois de fichiers suivis d'erreurs de manque de mémoire ou d'une série d'erreurs HTTP 500 ;
• des cookies PHPSESSID anormalement longs ou illisibles dans les réponses du serveur ;
• des workers PHP qui plantent ou redémarrent sans explication.

L'attaque se déroule sous l'application, si bien que les journaux applicatifs peuvent ne presque rien montrer. Quelques points de départ :

Adaptez chemins et noms d'utilisateur à votre environnement. L'absence de trace n'est pas une preuve d'innocuité : les journaux ont pu être collectés sans les niveaux de gravité utiles, et une défaillance peut survenir avant que PHP n'écrive son message (GHSA-6wmf).

Indicateurs publiés par AWS

Ces adresses appartiennent en partie à des infrastructures d'anonymisation partagées. AWS recommande d'enquêter sur toute occurrence plutôt que de les bloquer (AWS).

Méfiance envers les « exploits » qui circulent

Ne testez pas vos serveurs avec une preuve de concept trouvée en ligne. Le mainteneur du dépôt deb.sury.org a analysé une archive diffusée comme exploit fonctionnel. Selon lui, ce n'est pas un exploit validé, elle provoque au mieux un plantage, et elle ne doit pas être exécutée (issue #145).

En cas de compromission

• Signalez l'incident au CERT-FR, ou faites-vous accompagner via Cybermalveillance.gouv.fr.
• Si des données personnelles ont été exposées, le RGPD impose de notifier la CNIL dans les meilleurs délais et, si possible, sous 72 heures (CNIL).
• Considérez comme exposés tous les secrets accessibles au worker (identifiants de base de données, clés d'API, jetons) et renouvelez-les. CVE-2026-109619 permet notamment une divulgation de mémoire (GHSA-6wmf).

Ressources

Historique de l'article

La situation évolue vite, notamment l'état de l'exploitation et la disponibilité des paquets selon les architectures. Nous mettrons cet article à jour ; en cas de doute, les avis du projet PHP et du CERT-FR font foi.