PHP2Shell : PHP corrige deux failles critiques permettant une exécution de code à distance

L’équipe de sécurité de PHP a publié les correctifs attendus ce mercredi 21 octobre 2026. Connues sous le nom de PHP2Shell, les vulnérabilités CVE-2026-109618 et CVE-2026-109619 sont toutes deux notées 9,2 sur 10 selon CVSS 4.0. Elles peuvent permettre une exécution de code à distance sans authentification. PHP appelle à installer immédiatement une version corrigée.

Les versions corrigées sont disponibles

Les versions corrigées sont PHP 8.5.12, PHP 8.4.27, PHP 8.3.36 et PHP 8.2.35. Toutes les installations de PHP qui traitent des requêtes web sont considérées comme exposées, notamment avec PHP-FPM, Apache mod_php, php-cgi, FrankenPHP et LiteSpeed. PHP estime le risque particulièrement élevé avec mod_php, pour lequel une exploitation avant l’exécution du code de l’application a été démontrée.

PHP 8.1 et les branches antérieures ne reçoivent plus de versions de sécurité ordinaires du projet. Les utilisateurs concernés doivent vérifier les correctifs rétroportés par leur distribution ou leur fournisseur de support. PHP fournit exceptionnellement des branches contenant les modifications minimales pour PHP 7.4, PHP 8.0 et PHP 8.1, destinées avant tout aux personnes capables de reconstruire PHP depuis ses sources. Elles ne rétablissent pas le support général de ces versions.

Des tentatives d’exploitation déjà observées

Cloudflare indique avoir observé du trafic d’attaque visant ses clients ainsi que des modifications des charges utiles destinées à contourner les protections déployées. CloudLinux rapporte également des requêtes correspondant aux formes d’exploitation connues et à un outil désormais diffusé publiquement. Dans les 24 premières heures suivies par Imperva, l’entreprise a comptabilisé 482 342 requêtes réparties en 122 311 sessions d’attaque, visant 21 998 sites dans 103 pays. Elle décrit une activité largement automatisée et opportuniste.

Ces observations confirment que les vulnérabilités sont activement testées contre des serveurs exposés. Imperva précise que ses chiffres décrivent le trafic et les cibles observés, pas des exploitations réussies ni des sites compromis. Ils ne permettent donc pas, à eux seuls, d’affirmer que des compromissions massives ont eu lieu. Les règles de pare-feu applicatif proposées par certains fournisseurs constituent une protection supplémentaire contre les formes d’attaque connues, mais ne remplacent pas la mise à jour de PHP.

Des paquets corrigés dans plusieurs distributions

Canonical a publié le bulletin USN-8948-1 pour Ubuntu 22.04 LTS à 26.10, puis le bulletin USN-8948-2 pour les anciennes versions couvertes par Ubuntu Pro ou son option Legacy Support. Debian, Arch Linux, Alpine Linux, Fedora, SUSE, Amazon Linux et Gentoo ont également publié des paquets corrigés. Le tableau ci-dessous rassemble les principales références vérifiées, sans prétendre couvrir tous les produits et niveaux de support de chaque éditeur.

Ces numéros montrent pourquoi la seule version affichée par php -v ne suffit pas toujours. Ubuntu rétroporte les correctifs dans ses propres paquets : PHP 8.3.6 sur Ubuntu 24.04 peut ainsi être corrigé sans devenir PHP 8.3.36. Il faut comparer la révision complète du paquet installé avec celle publiée par la distribution. Après un apt update, la commande apt policy php8.3-fpm, adaptée à la branche utilisée, permet de contrôler la version installée et la version candidate.

Sur Ubuntu 22.04 LTS et les versions suivantes ainsi que sur les branches Debian corrigées, une mise à jour système standard installe les correctifs lorsque les dépôts de sécurité sont activés. Pour Ubuntu 20.04 LTS et les versions antérieures citées dans le tableau, il faut disposer de la couverture Ubuntu Pro correspondante. Sur les autres distributions, il faut utiliser leur gestionnaire de paquets habituel et vérifier la version complète proposée. Leur apparition peut être légèrement différée sur certains miroirs. Le ticket de sécurité Gentoo reste par ailleurs ouvert, même si les quatre versions corrigées ont été ajoutées au dépôt. Debian Forky reste également indiquée vulnérable à cette heure. SUSE a publié le correctif indiqué pour SLES 15 SP7, mais sa page de suivi classe encore certains autres produits et branches comme affectés.

AlmaLinux a placé dans ses dépôts de production des rétroportages pour tous les flux PHP proposés sur AlmaLinux 8, 9 et 10. Red Hat a publié des correctifs pour les flux PHP 7.4 et 8.2 de RHEL 8, les flux par défaut, 8.2 et 8.3 de RHEL 9, ainsi que les paquets PHP et PHP 8.4 de RHEL 10. Le flux PHP 8.4 de RHEL 9 reste indiqué affecté, tandis que RHEL 6 et 7 sont encore en cours d’évaluation.

Le correctif pour Fedora 43, initialement placé dans updates-testing, a rejoint les dépôts stables le 22 octobre. Le paquet destiné à Fedora 45 a été intégré à sa branche le 23 octobre, mais cette distribution est encore en préversion à cette date. Les quatre versions corrigées de PHP sont également disponibles dans le dépôt Remi pour Fedora 43 et versions ultérieures ainsi que pour Enterprise Linux 8 et versions ultérieures. Amazon indique par ailleurs qu’aucun correctif n’est prévu pour PHP 8.1 sur Amazon Linux 2023 ni pour l’ancien paquet PHP du dépôt principal d’Amazon Linux 2.

Pour les environnements d’hébergement, CloudLinux a publié les paquets corrigés alt-php et ea-php. Depuis le 22 octobre à 19 h 50 UTC, les correctifs de toutes les versions natives affectées de PHP proposées par CloudLinux OS 7 à 10 sont également dans le canal stable. CloudLinux a ensuite publié pour alt-php 8.2 à 8.5 des paquets reprenant les numéros de version de PHP.net dans les dépôts stables de CloudLinux OS 8 et 9. Cet alignement ne concerne pas encore ea-php, dont les paquets restent corrigés par rétroportage sous un numéro de version antérieur. Les anciens paquets alt-php déjà corrigés par rétroportage restent eux aussi protégés contre ces deux CVE.

En France, o2switch confirme que les correctifs sont appliqués à toutes les versions de PHP 5.2 à 8.5 proposées dans son sélecteur. Dans une mise à jour publiée le 23 octobre à 10 h, l’hébergeur précise que PHP affiche désormais le numéro de version officiel correspondant au correctif. Les installations étaient déjà protégées auparavant malgré l’ancien numéro affiché, et aucune action supplémentaire n’est demandée aux clients.

Cet alignement facilite désormais la vérification chez o2switch. Il ne faut toutefois pas le généraliser à tous les hébergeurs ni à tous les paquets CloudLinux. Certains rétroportages, notamment dans ea-php, peuvent encore conserver un numéro de version antérieur. Dans ce cas, la version visible dans un panneau d’hébergement, WordPress ou phpinfo() ne permet ni de confirmer ni d’exclure l’installation du correctif. Il faut consulter le journal des versions de CloudLinux ou la confirmation de l’hébergeur.

Après l’installation, les processus PHP-FPM ou Apache concernés doivent être redémarrés, puis la version réellement utilisée par le site doit être vérifiée.

Ce que PHP confirme sur les deux vulnérabilités

Pour CVE-2026-109618, PHP décrit une corruption de mémoire liée à la gestion d’un épuisement de mémoire. Une interruption au mauvais moment peut laisser des données internes de la requête dans un état partiellement initialisé, puis conduire le nettoyage à traiter des données invalides comme si elles étaient valides.

Pour CVE-2026-109619, PHP décrit la persistance possible d’un état global associé à une requête après la libération de la mémoire correspondante. Une requête ultérieure traitée par le même processus peut alors réutiliser cet état avant sa réinitialisation.

Ces descriptions officielles sont plus larges et plus précises que les analyses publiées avant la levée de l’embargo. Les premières affirmations attribuant les deux failles à une même fonction de suivi des téléversements ne doivent donc pas être reprises comme une description complète des vulnérabilités.

Des outils d’exploitation circulent publiquement, mais leurs affirmations de compatibilité ne constituent pas une liste fiable des versions affectées. Il faut se référer aux avis de PHP et des fournisseurs de paquets.

Pourquoi certains évoquent un score CVSS de 10

Le score de 10 sur 10 vient des premières informations ayant circulé avant l’annonce de PHP. Un message supprimé sur Hacker News et une déclaration initiale de watchTowr cités par BleepingComputer attribuaient ce score aux deux failles.

Le score retenu dans les avis officiels est toutefois de 9,2 selon CVSS 4.0 pour chacune des deux vulnérabilités. Il faut donc retenir 9,2, sans présenter le score de 10 comme une évaluation confirmée. Dans les deux cas, la classification reste critique.

Vérifier toutes les versions de PHP réellement utilisées

La commande suivante permet de connaître la version de l’interpréteur PHP lancé depuis le terminal :

php -v

Ce résultat ne suffit cependant pas à inventorier un serveur. Le site web peut utiliser une autre version par l’intermédiaire de PHP-FPM ou d’Apache, tandis que les tâches planifiées, les files de traitement et les outils en ligne de commande peuvent encore en charger une autre. La version indiquée dans WordPress ou dans un panneau d’hébergement constitue donc un premier repère, mais pas une vérification complète.

Sur un hébergement mutualisé, le panneau de contrôle n’affiche parfois que la branche, par exemple « PHP 8.3 », sans le numéro complet de la version ni la révision du paquet. Cette indication ne permet pas de savoir si un correctif précis a été installé. Dans WordPress, la version complète peut généralement être consultée dans Outils > Santé du site > Informations > Serveur. Il ne faut pas laisser en ligne une page phpinfo(), car elle dévoilerait de nombreux détails sur la configuration du serveur.

Si la version complète reste inaccessible, seul l’hébergeur peut confirmer la version ou le paquet réellement déployé et la prise en charge des deux vulnérabilités. Il faut alors consulter son avis de sécurité ou demander explicitement si PHP 8.2.35, 8.3.36, 8.4.27 ou 8.5.12, selon la branche utilisée, a été installé. Un fournisseur peut aussi appliquer un correctif rétroporté sous une autre référence de paquet. Le simple affichage d’une branche récente, ou la possibilité de la sélectionner dans le panneau, ne constitue pas une confirmation.

Avec Nginx, la commande php -v exécutée sur le serveur ne correspond pas nécessairement à la version utilisée par le site. Nginx transmet généralement les fichiers PHP à un service PHP-FPM défini par la directive fastcgi_pass. La configuration active permet d’identifier cette cible :

nginx -T 2>&1 | grep -nE '^[[:space:]]*fastcgi_pass[[:space:]]'

Cette commande doit être lancée sur le système où Nginx est installé, avec les droits nécessaires pour lire sa configuration. Si Nginx fonctionne dans Docker, elle devient par exemple docker exec NOM_DU_CONTENEUR_NGINX nginx -T 2>&1 | grep -nE '^[[:space:]]*fastcgi_pass[[:space:]]'. La configuration complète pouvant contenir des informations sensibles, elle ne doit pas être publiée telle quelle.

La directive peut désigner un socket local, un port réseau ou le nom d’un service Docker. C’est la version du processus ou du conteneur PHP-FPM correspondant qu’il faut contrôler. Plusieurs sites hébergés par le même serveur Nginx peuvent aussi utiliser des pools, et même des versions de PHP, différents.

Une vigilance particulière est nécessaire avec Docker. Il faut d’abord identifier les images utilisées, puis vérifier la version à l’intérieur de chaque conteneur qui exécute PHP :

docker ps --format 'table {{.Names}}\t{{.Image}}'
docker exec NOM_DU_CONTENEUR php -v

NOM_DU_CONTENEUR doit être remplacé par un nom affiché par la première commande. Avec Docker Compose, la vérification peut aussi être effectuée avec docker compose exec NOM_DU_SERVICE php -v. Elle doit inclure les conteneurs web, mais aussi les workers, les tâches planifiées, les outils d’administration et les environnements de préproduction. Le nom ou le tag d’une image ne garantit pas la version corrective réellement exécutée. Lorsque l’image corrigée est disponible auprès de sa source, un simple redémarrage ne suffit pas : les conteneurs doivent être recréés à partir de la nouvelle image, puis leur version doit être contrôlée.

Il faut enfin rechercher les anciennes applications, les hôtes virtuels oubliés et les images susceptibles d’être redéployées plus tard. Pour les versions fournies par une distribution Linux, le numéro affiché par PHP ne permet pas toujours de reconnaître un correctif rétroporté. Il faudra aussi comparer la révision du paquet installé avec l’avis de sécurité de la distribution.

La mise à jour est la seule protection complète

Pour les deux vulnérabilités PHP2Shell, PHP indique clairement que seule l’installation d’une version corrigée apporte une protection complète. Les mesures temporaires publiées dans l’avis officiel réduisent l’exposition à certains chemins d’exploitation, mais ne rendent pas une installation vulnérable sûre.

Pour CVE-2026-109619, la désactivation de session.upload_progress.enabled est maintenant mentionnée par PHP comme une mesure temporaire contre les chemins d’exploitation confirmés liés aux sessions. Elle doit être appliquée dans php.ini, dans la configuration du pool PHP-FPM ou dans celle du serveur, avant le traitement de la requête, puis tous les processus PHP doivent être redémarrés. Une modification avec ini_set() ou dans un fichier .user.ini n’intervient pas assez tôt. PHP précise aussi que cette désactivation peut ne pas couvrir d’autres variantes de la vulnérabilité. Sur PHP 8.5, fatal_error_backtraces=0 bloque un autre chemin confirmé, sans constituer là non plus une protection complète. PHP recommande également de supprimer les réglages invalides ou obsolètes appliqués à chaque requête et de corriger les erreurs fatales ou délais d’exécution qu’un attaquant pourrait déclencher.

Le 23 octobre, PHP a publié un avis d’information distinct sur un autre vecteur RCE jugé peu probable, référencé CVE-2026-115560. Un avis complet et un correctif sont annoncés avec la prochaine version corrective ordinaire. Ce scénario nécessite une combinaison inhabituelle : l’application configure session.serialize_handler sur php_binary ou php_serialize, le remplace ensuite par php avec ini_set() avant session_start(), et conserve le suivi des téléversements actif. PHP recommande de garder session.upload_progress.enabled=0 jusqu’à cette prochaine version si ce réglage a déjà été appliqué. Cette précaution reste donc pertinente après l’installation des correctifs PHP2Shell. Les applications qui ne changent jamais le gestionnaire de sérialisation à l’exécution ne sont pas concernées par ce nouveau scénario.

Pour CVE-2026-109618, PHP cite notamment la suppression de la limite mémoire de PHP avec memory_limit=-1, la réduction de post_max_size et des limites de requêtes imposées par le serveur web ou le proxy. Même sans limite mémoire PHP, un échec d’allocation sous-jacent peut encore atteindre le chemin vulnérable. Ces réglages peuvent avoir des effets importants sur la consommation de ressources, les téléversements et la disponibilité du service. Ils doivent être évalués dans le contexte de chaque application et ne doivent pas être appliqués comme des recettes universelles.

Ces mesures peuvent donc compléter la protection pendant un délai de déploiement très court, mais elles ne remplacent pas les correctifs et ne doivent pas retarder leur installation. Si la mise à jour ne peut pas être appliquée rapidement, il faut aussi envisager de retirer temporairement l’application de l’accès public ou de limiter strictement son exposition.

La priorité est d’installer PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou un paquet explicitement corrigé par la distribution ou l’hébergeur. Il faut ensuite redémarrer les processus PHP-FPM, les serveurs concernés et les conteneurs, puis vérifier la version réellement utilisée par chaque site.