Mehdi Assabbane
← Tous les articles

PHP2Shell : comprendre les failles critiques CVE-2026-109618 et CVE-2026-109619

Mehdi Assabbane ·

En bref (état au 23 octobre 2026)

  • Deux vulnérabilités critiques du moteur PHP, publiées le 21 octobre 2026, peuvent permettre une exécution de code à distance sans authentification.
  • Versions corrigées : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Les distributions Linux publient leurs propres paquets corrigés.
  • Seule la mise à jour corrige le problème. Les réglages de configuration proposés par le projet PHP réduisent l'exposition, sans rendre un serveur sûr.
  • Le risque est jugé le plus élevé pour Apache avec mod_php.

Introduction

Le 21 octobre 2026, le projet PHP a publié des versions de sécurité pour toutes ses branches maintenues, accompagnées d'un avis au titre sans ambiguïté : « Critical remote code execution vulnerabilities, update now ». Les deux failles corrigées, CVE-2026-109618 et CVE-2026-109619, ont été rapidement surnommées « PHP2Shell » par les chercheurs et éditeurs de sécurité.

Leur particularité : elles se situent dans le cœur de PHP, pas dans un framework ou un CMS. Une application WordPress, Laravel, Symfony ou PrestaShop parfaitement à jour peut donc être exposée si l'interpréteur qui l'exécute ne l'est pas. Et selon l'avis officiel, dans la configuration la plus à risque, la requête malveillante agit avant même que le code de l'application ne s'exécute.

Cet article explique ce que sont ces vulnérabilités, ce qui est confirmé à leur sujet, ce qui reste incertain, et surtout comment vérifier et protéger vos serveurs sans recourir à du code d'exploitation.

Qu'est-ce qu'une vulnérabilité RCE ?

Définition simple

Une vulnérabilité d'exécution de code à distance (Remote Code Execution, RCE) permet à un attaquant de faire exécuter ses propres instructions par un serveur, à distance, généralement via le réseau. Quand elle est exploitable sans authentification, il suffit que le service soit joignable : aucun compte, aucun mot de passe, aucune action d'un utilisateur ne sont nécessaires.

Pourquoi c'est la catégorie la plus grave

La plupart des failles web donnent un accès partiel : lire une donnée, contourner un contrôle, injecter un script dans une page. Une RCE donne un point d'appui sur le système lui-même, avec les droits du processus vulnérable. Pour PHP, ce sont les droits du compte qui exécute les workers web (souvent www-data, apache ou nginx). À partir de là, l'attaquant peut :

  • lire les fichiers de configuration de l'application (et les secrets qu'ils contiennent : mots de passe de base de données, clés d'API, clés de chiffrement des sessions) ;
  • interroger ou modifier la base de données avec les identifiants de l'application ;
  • déposer une porte dérobée (webshell) pour revenir plus tard ;
  • utiliser le serveur comme relais pour attaquer le réseau interne ou envoyer du spam ;
  • chercher une seconde faille pour élever ses privilèges vers root.

Les failles de corruption mémoire

Les deux CVE PHP2Shell appartiennent à la famille des corruptions mémoire. PHP est écrit en C ; lorsqu'il manipule une zone mémoire dans un état incohérent (non initialisée, ou déjà libérée — on parle alors d'use-after-free), un attaquant capable de contrôler le contenu de cette zone peut, dans certaines conditions, détourner l'exécution du programme. Ces exploits sont souvent délicats à rendre fiables, car ils dépendent de la version exacte, du système et de l'agencement de la mémoire. Mais la difficulté d'exploitation n'est pas une protection : elle ne fait que retarder l'industrialisation d'une attaque.

Les deux vulnérabilités en détail

Ce qui est confirmé

Les informations ci-dessous proviennent de l'avis officiel de php.net, des avis GitHub du dépôt php/php-src et des enregistrements CVE.org et NVD.

CVE-2026-109618 CVE-2026-109619
Intitulé officiel RCE via OOM corruption RCE via stale global state
Avis GitHub GHSA-w8hw-w9fx-j79w GHSA-6wmf-4rv5-p3rp
Nature Corruption mémoire lors de la gestion d'un manque de mémoire Use-after-free sur un état global conservé entre deux requêtes
Score CNA (PHP) CVSS v4.0 : 9,2 (critique) CVSS v4.0 : 9,2 (critique)
Score NVD CVSS v3.1 : 9,8 CVSS v3.1 : 8,1
Authentification requise Non Non
Versions corrigées 8.2.35, 8.3.36, 8.4.27, 8.5.12 8.2.35, 8.3.36, 8.4.27, 8.5.12
Publication 21 octobre 2026 21 octobre 2026

Les écarts de score sont normaux : chaque organisme évalue avec sa propre méthode. Red Hat, par exemple, retient 8,1 en CVSS v3.1 pour CVE-2026-109618 (importance « Important »), en considérant une complexité d'attaque élevée. Quel que soit le chiffre retenu, tous les acteurs classent ces failles parmi les priorités de correction.

CVE-2026-109618 : la corruption liée au manque de mémoire

Chaque requête PHP dispose d'une limite de mémoire (memory_limit). Lorsqu'elle est dépassée, PHP interrompt brutalement le traitement en cours grâce au mécanisme C longjmp(). Selon l'avis officiel, cette interruption peut survenir alors que certaines données internes de la requête ne sont que partiellement initialisées. Le nettoyage de fin de requête traite ensuite ces données incomplètes comme si elles étaient valides, ce qui corrompt la mémoire.

L'avis GitHub précise que le déclenchement passe notamment par l'analyse des requêtes multipart (le format des formulaires avec envoi de fichiers), d'une manière qui provoque un dépassement mémoire tout en restant apparemment dans les limites configurées.

Le correctif supprime l'usage de longjmp() pour ce cas : PHP signale désormais le manque de mémoire à un point sûr de l'exécution, et termine le processus proprement au-delà d'un seuil plus élevé.

CVE-2026-109619 : l'état global « périmé »

Un worker PHP (processus PHP-FPM ou processus Apache avec mod_php) traite de nombreuses requêtes successives. Certaines variables globales internes pointent temporairement vers la mémoire d'une requête. Si une erreur fatale (dépassement mémoire, temps d'exécution dépassé…) empêche leur remise à zéro, elles continuent de pointer vers une mémoire déjà libérée. Une requête suivante, traitée par le même worker, peut alors utiliser cet état périmé avant que l'initialisation normale ne le réinitialise.

L'avis GitHub décrit donc une attaque en deux temps : une requête « productrice » qui laisse l'état périmé, puis une requête « consommatrice » sur le même processus. Parmi les consommateurs identifiés : la fonction de suivi de progression des téléversements de session (session.upload_progress, activée par défaut) et certains messages de diagnostic émis très tôt dans le traitement. Sur PHP 8.5, la fonctionnalité de traces d'appel sur erreur fatale (fatal_error_backtraces) constitue un chemin d'exploitation confirmé.

Quelles configurations sont concernées ?

Selon l'avis officiel, toutes les installations PHP qui servent des requêtes web sont à risque : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Les avis GitHub détaillent le niveau de confirmation par mode d'exécution :

Mode d'exécution (SAPI) CVE-2026-109618 CVE-2026-109619
Apache mod_php RCE confirmée en HTTP, avec les limites par défaut RCE confirmée
PHP-FPM Susceptible selon l'analyse du code ; pas d'exploit complet démontré RCE validée via le cycle de vie des sessions avec un pool dynamique classique
FrankenPHP Probablement susceptible Pas de chemin établi en configuration par défaut, sans que cela garantisse l'immunité
LiteSpeed (LSAPI) Probablement susceptible, non validé Candidat conditionnel
CLI Non traité par les avis Non traité par les avis

La ligne CLI mérite une précision : les avis ne se prononcent pas sur l'interface en ligne de commande. Comme la seconde faille repose sur un worker qui enchaîne plusieurs requêtes réseau, un script CLI isolé n'est pas une cible évidente. Ce n'est toutefois pas une confirmation officielle : mettez à jour le binaire CLI en même temps que le reste, ce que font de toute façon les gestionnaires de paquets.

Red Hat souligne de son côté que ses distributions utilisent PHP-FPM plutôt que mod_php par défaut, et que l'exploitation y est « difficile en pratique » pour CVE-2026-109618. C'est une appréciation de l'éditeur pour ses produits, pas une raison de différer la mise à jour.

Les anciennes versions

  • PHP 8.2 : corrigé en 8.2.35. Le projet PHP rappelle que cette branche arrive en fin de vie le 31 décembre 2026.
  • PHP 8.1, 8.0 et 7.4 : plus de version officielle. Le projet PHP a exceptionnellement publié des rétroportages minimaux sous forme de code source pour ces trois branches, destinés à ceux qui compilent PHP eux-mêmes. Les distributions et fournisseurs de support étendu proposent leurs propres paquets.
  • PHP 7.3 et antérieurs (dont PHP 5) : aucun correctif amont. watchTowr indique avoir confirmé que PHP 5 est affecté.

Ce qui reste incertain

Il est important de distinguer les faits des affirmations non consolidées :

  • Exploitation active. watchTowr déclare observer des exploitations sur son réseau de pots de miel depuis le 21 octobre 2026. Rapid7, à la même période, indique ne pas avoir observé d'exploitation confirmée mais avoir reçu plusieurs signalements de tentatives. Au 23 octobre 2026, ces CVE ne figurent pas au catalogue KEV (Known Exploited Vulnerabilities) de la CISA.
  • Fiabilité des exploits publics. Des preuves de concept ont circulé dès le 22 octobre. Selon Rapid7, chacune ne fonctionne que pour une combinaison précise de système, de version de PHP et de serveur web, et aucune ne semble fiable de manière générale. Cette situation peut évoluer rapidement.
  • Fuite avant divulgation. Plusieurs éditeurs rapportent que des détails ont circulé publiquement avant la divulgation coordonnée. Le projet PHP a d'ailleurs publié une annonce anticipée le 20 octobre. Les circonstances exactes de cette fuite ne sont pas documentées par une source officielle.
  • Indicateurs de compromission. Aucune source officielle ne publie d'indicateurs (IOC) fiables à ce jour. Méfiez-vous des listes qui circulent sans source vérifiable.

Une vulnérabilité liée, mais distincte. Le 23 octobre 2026, le projet PHP a publié un avis informatif sur CVE-2026-115560, une variante peu probable liée elle aussi au suivi de progression des sessions. Elle ne concerne que des applications qui changent session.serialize_handler à l'exécution. Le projet recommande de garder session.upload_progress.enabled=0 jusqu'à la prochaine version corrective ; l'avis complet sera publié avec celle-ci.

Conséquences potentielles pour un site PHP

En cas d'exploitation réussie, le code de l'attaquant s'exécute avec les droits du compte du worker web. Concrètement :

  • Le serveur web : dépôt de fichiers dans tous les répertoires inscriptibles par ce compte, lancement de processus (minage de cryptomonnaie, relais réseau), persistance via une tâche planifiée du compte web.
  • L'application : modification du code si les fichiers PHP appartiennent au compte web (une erreur de permissions fréquente), injection de contenu malveillant dans les pages, vol des secrets de configuration.
  • La base de données : avec les identifiants de l'application, lecture et modification de toutes les tables auxquelles elle a accès — comptes clients, commandes, contenus.
  • Les données des utilisateurs : sessions actives (usurpation de comptes), données personnelles, ce qui peut constituer une violation de données au sens du RGPD, avec obligation de notification à la CNIL sous 72 heures lorsque les conditions sont réunies.

L'étendue réelle des dégâts dépend donc beaucoup de l'hygiène du serveur : un compte web qui ne peut pas modifier le code, des secrets limités au strict nécessaire et une base de données aux droits restreints réduisent fortement l'impact d'une RCE.

Comment vérifier si un serveur est concerné, sans code malveillant

Inutile — et risqué — de tester une preuve de concept trouvée en ligne : sur un serveur de production, une corruption mémoire peut faire planter des processus, et le code de ces outils n'est pas toujours celui qu'il prétend être. La vérification se fait par inventaire et lecture de configuration.

1. Identifier la version qui sert réellement les requêtes

php -v

Affiche la version du binaire CLI. C'est un premier indice, mais pas forcément la version utilisée par le serveur web : une machine peut héberger plusieurs versions de PHP.

ps -eo user,pid,cmd | grep -E '[p]hp-fpm|[a]pache2|[h]ttpd'

Liste les processus PHP-FPM et Apache en cours, avec leur compte d'exécution. Le nom du processus maître PHP-FPM indique généralement le fichier de configuration utilisé, donc la version (par exemple /etc/php/8.3/fpm/php-fpm.conf).

apache2ctl -M 2>/dev/null | grep -i php   # Debian/Ubuntu
httpd -M 2>/dev/null | grep -i php        # RHEL/Rocky/Alma

Si un module php_module apparaît, Apache exécute PHP via mod_php, la configuration jugée la plus exposée.

2. Vérifier le correctif dans les paquets de la distribution

Les distributions rétroportent les correctifs sans changer le numéro de version amont. Sur Ubuntu 24.04, par exemple, le paquet corrigé est en 8.3.6-0ubuntu0.24.04.13 : php -v affichera 8.3.6, alors que le serveur est protégé. Il faut donc interroger le journal des modifications du paquet :

apt changelog php8.3-fpm 2>/dev/null | grep -m2 -E 'CVE-2026-10961[89]'

Sur Debian/Ubuntu, recherche les deux identifiants dans le journal des modifications du paquet installé (adaptez le nom du paquet).

rpm -q --changelog php-fpm | grep -m2 -E 'CVE-2026-10961[89]'

Équivalent sur les systèmes RPM. Si rien n'apparaît, le correctif n'est pas installé (ou le paquet ne le mentionne pas : consultez alors le bulletin de votre éditeur).

3. Contrôler les réglages d'atténuation

grep -rnE 'memory_limit|post_max_size|upload_progress|fatal_error_backtraces' /etc/php/ 2>/dev/null

Affiche ces directives dans tous les fichiers de configuration PHP (chemin Debian/Ubuntu ; sur RHEL, utilisez /etc/php.ini /etc/php.d/ /etc/php-fpm.d/). Cela permet de voir si une configuration de pool ou de répertoire redéfinit une valeur.

4. Pour les conteneurs et hébergements mutualisés

  • Docker : docker exec <conteneur> php -v pour chaque conteneur exécutant PHP, puis reconstruisez les images à partir d'une image de base à jour.
  • Hébergement mutualisé ou géré : consultez les communications de votre hébergeur ; vous n'avez souvent pas la main sur le binaire PHP.
  • Scanners : des outils de gestion des vulnérabilités ont ajouté des contrôles dédiés (Rapid7 l'indique pour ses produits). Utilisez-les uniquement sur des systèmes que vous administrez.

Protéger ses serveurs : correctif d'abord

Le véritable correctif

Mettre à jour vers PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou vers le paquet corrigé de votre distribution, puis redémarrer tous les processus PHP (PHP-FPM, ou Apache si mod_php). Un paquet mis à jour sur disque ne protège rien tant que les anciens processus tournent en mémoire.

Exemples de paquets corrigés publiés par les distributions (vérifiez les bulletins pour votre version) :

Distribution Paquet corrigé Bulletin
Debian 13 (trixie) php8.4 8.4.27-1~deb13u1 DSA-6574-1
Debian 12 (bookworm) php8.2 8.2.35-1~deb12u1 DLA-4848-1
Ubuntu 24.04 LTS php8.3 8.3.6-0ubuntu0.24.04.13 USN-8948-1
Ubuntu 22.04 LTS php8.1 8.1.2-1ubuntu2.28 USN-8948-1
Ubuntu 20.04 et antérieures Correctifs via Ubuntu Pro (ESM) USN-8948-2

Les mesures temporaires (si la mise à jour doit attendre)

Le projet PHP est explicite : aucune mesure de configuration n'est une protection complète. Les réglages suivants réduisent certains chemins d'attaque connus, en attendant la mise à jour :

; À placer dans php.ini, la configuration du pool FPM (php_admin_value)
; ou la configuration Apache : jamais via ini_set() ni .user.ini

; CVE-2026-109619
session.upload_progress.enabled = 0
fatal_error_backtraces = 0          ; PHP 8.5 uniquement

; CVE-2026-109618
memory_limit = -1                   ; supprime la limite contrôlable par l'attaquant
post_max_size = 8M                  ; 32M si l'application accepte des téléversements
upload_max_filesize = 6M            ; toujours inférieur à post_max_size

Points d'attention :

  • memory_limit = -1 supprime la limite mémoire PHP : un script gourmand peut alors consommer toute la RAM. Le projet PHP recommande de compenser par une limite de conteneur ou de cgroup, et de ne pas utiliser RLIMIT_AS ou RLIMIT_DATA, qui peuvent justement provoquer l'échec d'allocation vulnérable.
  • Ces valeurs doivent être appliquées de façon non modifiable par l'application (php_admin_value dans le pool FPM), et il faut vérifier qu'aucun autre fichier ne les redéfinit.
  • Redémarrez tous les workers après modification.
  • Masquer les erreurs (display_errors, error_reporting, opérateur @) n'a aucun effet sur ces failles.
  • Si l'application n'utilise pas d'envoi de fichiers, bloquer les requêtes multipart au niveau du serveur web ou du proxy réduit la surface d'attaque de CVE-2026-109618.
  • pm.max_requests = 1 dans un pool FPM (un processus par requête) réduit les chances de CVE-2026-109619, au prix d'une forte baisse de performances.

Réduire la surface d'attaque et les privilèges

Ces mesures générales ne corrigent pas les CVE, mais limitent les conséquences d'une exploitation :

  • préférer PHP-FPM à mod_php, avec un pool et un compte système par site ;
  • faire en sorte que le compte web ne puisse pas modifier le code de l'application ;
  • restreindre l'accès réseau sortant du serveur web ;
  • limiter les droits du compte de base de données de l'application ;
  • restreindre l'accès aux serveurs qui ne peuvent pas être mis à jour immédiatement (watchTowr recommande de les retirer d'Internet si possible).

Surveiller les journaux

Les avis recommandent d'activer la journalisation complète des erreurs (log_errors = On, error_reporting = E_ALL, un error_log fonctionnel). Surveillez en particulier les plantages de workers (segmentation fault), les pics d'erreurs de mémoire et les requêtes multipart volumineuses ou inhabituelles. Gardez en tête l'avertissement de l'avis GitHub : des journaux propres ne prouvent pas l'absence d'attaque.

Checklist opérationnelle pour les administrateurs

Dans les 24 heures

  • Inventorier tous les serveurs et conteneurs exécutant PHP, en commençant par ceux exposés sur Internet.
  • Identifier le mode d'exécution de chacun (mod_php, PHP-FPM, autre).
  • Vérifier la présence du correctif (version amont ou journal des modifications du paquet).
  • Appliquer la mise à jour (paquet de distribution, image Docker reconstruite ou version 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35).
  • Redémarrer tous les processus PHP et vérifier la version effectivement chargée.

Si la mise à jour est impossible immédiatement

  • Appliquer session.upload_progress.enabled = 0 (et fatal_error_backtraces = 0 sur 8.5) au niveau administrateur.
  • Appliquer memory_limit = -1 avec une limite de cgroup/conteneur, et réduire post_max_size.
  • Bloquer les requêtes multipart en frontal si l'application n'en a pas besoin.
  • Restreindre l'exposition réseau du serveur.
  • Planifier la mise à jour à court terme : ces mesures sont provisoires.

Ensuite

  • Analyser les journaux depuis le 20 octobre 2026 au moins, date des premières fuites — idéalement sur une période plus large si vos journaux le permettent (plantages, fichiers PHP récents, processus inhabituels du compte web).
  • Planifier la migration des versions sans support (8.1 et antérieures, et 8.2 avant le 31 décembre 2026).
  • Conserver session.upload_progress.enabled = 0 jusqu'à la prochaine version corrective (CVE-2026-115560).

FAQ

Mon site WordPress (ou Laravel, PrestaShop…) est à jour. Suis-je protégé ? Non, pas nécessairement. Les failles sont dans l'interpréteur PHP lui-même. C'est la version de PHP installée sur le serveur qui compte, pas celle de votre CMS ou de votre framework.

php -v affiche 8.3.6 sur mon Ubuntu. Suis-je vulnérable ? Pas forcément. Ubuntu et Debian appliquent les correctifs sans changer le numéro de version amont. Consultez le journal des modifications du paquet (apt changelog) ou la page CVE de votre distribution pour savoir si le correctif est installé.

Désactiver session.upload_progress suffit-il ? Non. Ce réglage bloque des chemins d'exploitation confirmés de CVE-2026-109619, mais pas toutes les variantes, et ne fait rien contre CVE-2026-109618. Seule la mise à jour corrige les deux failles.

PHP-FPM est-il moins exposé que mod_php ? Le projet PHP juge le risque le plus élevé pour mod_php, où une exploitation complète a été démontrée. Pour PHP-FPM, une exploitation de CVE-2026-109619 a été validée dans une configuration courante. PHP-FPM doit donc être mis à jour avec la même priorité.

J'utilise encore PHP 7.4 ou 8.1. Que faire ? Le projet PHP ne publie plus de versions pour ces branches. Utilisez les paquets corrigés de votre distribution ou de votre fournisseur de support étendu s'il y en a, ou les rétroportages source publiés par le projet PHP si vous compilez vous-même. La solution durable reste la migration vers une branche maintenue.

Faut-il tester un exploit public pour vérifier mon serveur ? Non. Une preuve de concept peut faire planter vos processus ou contenir du code malveillant. Vérifiez les versions, les paquets et la configuration, ou utilisez un scanner reconnu sur vos propres systèmes.

Conclusion

PHP2Shell rappelle une règle simple : la sécurité d'un site dépend aussi de son socle d'exécution. Les recommandations, par ordre de priorité :

  1. Mettez à jour PHP vers une version corrigée ou le paquet corrigé de votre distribution, puis redémarrez tous les processus PHP.
  2. Vérifiez que la version qui sert les requêtes est bien la bonne, sur chaque serveur et chaque conteneur.
  3. N'utilisez les réglages temporaires que pour gagner quelques heures ou quelques jours, jamais comme solution définitive.
  4. Examinez vos journaux et l'état de vos serveurs exposés, au minimum depuis le 20 octobre 2026.
  5. Profitez-en pour sortir des versions de PHP sans support et durcir les permissions de vos serveurs.

Pour la mise en pratique — inventaire, mise à jour sans interruption, durcissement et réponse à incident — consultez notre guide complémentaire : Sécuriser son serveur PHP face aux vulnérabilités critiques.

Sources officielles