PHP2Shell : les correctifs sont publiés et l'exploitation a commencé. Voici les versions à installer et quoi faire.

Le 22 octobre 2026, la situation autour de PHP2Shell a changé. En effet, les correctifs sont disponibles depuis la veille. Cependant, des attaques sont déjà observées. Ce dossier de suivi fait le point sur les versions concernées, l’état de l’exploitation et les mesures à prendre. Il complète également notre premier article du 21 octobre au matin, publié avant la sortie des correctifs.

PHP2Shell : deux failles critiques au cœur de PHP

PHP2Shell est le surnom de deux vulnérabilités qui touchent PHP lui-même. Elles portent les identifiants CVE-2026-109618 et CVE-2026-109619. Par ailleurs, les avis officiels, GHSA-w8hw-w9fx-j79w et GHSA-6wmf-4rv5-p3rp, ont été publiés le 21 octobre 2026.

La gravité est qualifiée de critique. Ainsi, chaque faille reçoit un score CVSS v4.0 de 9.2. Des chiffres non officiels (10.0 et 9.4) ont circulé avant la publication. Toutefois, la note retenue par PHP est bien 9.2.

L’impact est sérieux. En effet, un attaquant distant, sans authentification, peut exécuter du code avec les droits du processus qui fait tourner PHP. En outre, CVE-2026-109619 peut provoquer une fuite de mémoire du serveur. Cette mémoire est susceptible de contenir des identifiants.

Un point mérite d’être souligné. C’est le cœur de PHP qui est en cause, pas une application. Par conséquent, mettre à jour WordPress ou un autre CMS ne protège pas. WordPress.org l’indique clairement : aucune mise à jour de WordPress n’est nécessaire. C’est donc PHP qu’il faut mettre à jour.

Ce que corrigent les deux failles

Les deux défauts sont de nature différente. Voici l’essentiel de chacun.

• CVE-2026-109618 : une mauvaise gestion des erreurs de manque de mémoire (« out of memory »). Lorsqu’une requête épuise la mémoire, PHP l’interrompt brutalement. Or certaines données internes ne sont alors pas complètement initialisées. Pourtant, elles sont traitées comme valides lors du nettoyage. Ainsi, le correctif supprime cette interruption brutale. Il la remplace par un arrêt contrôlé.
• CVE-2026-109619 : un « use-after-free » entre deux requêtes. Un processus PHP réutilisé pour plusieurs requêtes peut conserver un état interne, comme les erreurs ou la session. Cet état peut pointer vers de la mémoire déjà libérée par une requête précédente. Le correctif réinitialise donc complètement cet état entre deux requêtes.

Les chercheurs précisent que le code concerné remonte à PHP 5.4.0. Autrement dit, ces défauts sont présents depuis très longtemps.

Quels modes d’exécution sont exposés

Toutes les installations qui servent des requêtes web sont concernées. Cela inclut notamment PHP-FPM, Apache mod_php, php-cgi, FrankenPHP et LiteSpeed (LSAPI). Cependant, le niveau d’exposition varie selon le mode.

• Apache mod_php : le plus exposé, selon l’équipe PHP. En effet, une exploitation y a été démontrée avant même l’exécution du code de l’application.
• PHP-FPM : exploitation confirmée par l’un des chemins de CVE-2026-109619. Pour CVE-2026-109618, l’analyse du code suggère une exposition. Toutefois, aucune exploitation complète n’a été démontrée.
• FrankenPHP et LSAPI : probablement exposés, d’après l’analyse du code.

Versions corrigées et branches sans correctif

Les versions corrigées ont été publiées le 21 octobre 2026 à 14 h UTC. Elles concernent les branches encore maintenues.

• PHP 8.5.12 pour la branche 8.5 ;
• PHP 8.4.27 pour la branche 8.4 ;
• PHP 8.3.36 pour la branche 8.3 ;
• PHP 8.2.35 pour la branche 8.2.

La situation est moins confortable pour les branches anciennes. En effet, les branches 8.1, 8.0 et 7.4 sont en fin de vie. Il n’y a donc pas de nouvelle version officielle. L’équipe PHP a seulement publié des correctifs minimaux en code source. Ils s’adressent à ceux qui compilent PHP eux-mêmes.

Pour les autres, le correctif doit venir des distributions et des éditeurs. C’est le cas, par exemple, d’Ubuntu, du dépôt sury.org et de cPanel. Par ailleurs, Plesk travaille encore sur les branches 8.0 et 8.1. Quant aux versions PHP 5.4 à 7.3, le projet PHP ne fournit aucun correctif.

Ubuntu a publié des paquets corrigés pour les versions 22.04, 24.04, 26.04 et 26.10. En revanche, le dépôt Remi a prévenu qu’il ne serait pas à jour le 21 octobre. Il faut donc surveiller ses annonces.

Attention au numéro de version. Les distributions corrigent souvent une faille sans changer la version affichée. Ainsi, un serveur peut afficher une version ancienne tout en étant protégé. L’inverse est tout aussi possible. C’est pourquoi il faut consulter l’avis de sécurité de sa distribution ou interroger son hébergeur.

Une exploitation PHP2Shell déjà en cours

Les événements se sont enchaînés très vite. Voici la chronologie connue.

• 17 octobre 2026 : Amazon Threat Intelligence observe une tentative d’exploitation sur ses pots de miel MadPot. C’était quatre jours avant la divulgation.
• 20 octobre : les identifiants CVE fuitent publiquement. PHP annonce alors une publication le lendemain à 14 h UTC. Elle était initialement prévue le 22. Elle a donc été avancée après la fuite.
• 21 octobre : les correctifs et les avis sortent. Le SANS ISC passe son niveau d’alerte InfoCon au jaune. Par ailleurs, Cisco, OPNsense, pfSense et Palo Alto Networks publient des bulletins sur leurs produits concernés. La CISA appelle également à corriger immédiatement. Enfin, le CERT-EU publie l’avis 2026-018.

La découverte est créditée à des chercheurs de Calif, Wiz, Areion et OpenAI. Calif et Wiz indiquent avoir utilisé des modèles d’IA dans leurs recherches. En revanche, les correctifs ont été développés par l’équipe de maintenance de PHP.

Où en sont les attaques

Amazon décrit une exploitation désormais large. En effet, plusieurs acteurs ont tenté des attaques le 21 octobre. Leur efficacité réelle reste toutefois incertaine.

Cloudflare affirme voir des attaques émerger. L’entreprise a déployé des règles WAF pour tous ses clients, offre gratuite comprise. De son côté, watchTowr a reproduit les deux failles. De plus, le groupe observe des tentatives contre les deux.

Des preuves de concept circulent. Elles sont cependant jugées peu fiables ou incomplètes. À la publication, PHP n’avait identifié aucun exploit public fonctionnel. Néanmoins, Rapid7 s’attend à une exploitation massive rapide. Cette prudence se comprend, car la fenêtre entre correctif et attaques de masse se réduit.

Une surface d’attaque considérable

L’ampleur potentielle est importante. Selon W3Techs, PHP équipe environ 69,3 % des sites dont le langage serveur est connu. Par ailleurs, une estimation évoque plus de 1,3 million de serveurs exposés potentiellement vulnérables.

Le contexte n’est pas rassurant. En effet, le catalogue KEV de la CISA compte déjà trois failles PHP exploitées : CVE-2024-4577, CVE-2019-11043 et CVE-2012-1823. Deux d’entre elles ont servi dans des campagnes de rançongiciels. Les attaquants connaissent donc bien ce terrain.

Que faire dès maintenant

La seule correction complète est la mise à jour. Il faut d’abord installer une version corrigée de PHP, ou un paquet de distribution corrigé. Ensuite, il faut redémarrer tous les processus PHP : PHP-FPM, Apache et les workers. En effet, sans redémarrage, l’ancien code reste en mémoire.

Hébergement mutualisé

Si votre site est sur un hébergement mutualisé, commencez par vérifier la version de PHP. Dans WordPress, ouvrez Outils > Santé du site > Info > Serveur. Surveillez ensuite les annonces de votre hébergeur. Demandez-lui également s’il a appliqué le correctif du 21 octobre.

Si vous êtes sur PHP 8.1 ou plus ancien, passez à PHP 8.2 ou plus récent. Testez d’abord sur une copie du site. Vous éviterez ainsi une mauvaise surprise de compatibilité.

Mesures temporaires

Parfois, la mise à jour est impossible tout de suite. Dans ce cas, certaines mesures réduisent le risque sans le supprimer. Elles s’appliquent dans la configuration du serveur. Il faut ensuite redémarrer les processus.

• session.upload_progress.enabled = 0 : ferme un chemin d’attaque de CVE-2026-109619. WordPress n’utilise pas cette fonction. L’avis conseille de la laisser désactivée même après correction si elle est inutile. Toutefois, un réglage via ini_set() ou .user.ini arrive trop tard.
• Sur PHP 8.5 : fatal_error_backtraces = 0.
• Pour CVE-2026-109618 : imposer memory_limit = -1 au niveau administrateur. Il s’agit toutefois d’une mesure partielle.
• Garder des limites de taille de requête basses, avec post_max_size et upload_max_filesize. Elles doivent également être appliquées au niveau du serveur frontal ou du pare-feu applicatif.
• Activer les règles WAF disponibles, par exemple celles de Cloudflare. Imunify360 bloque l’exploit public sur Apache. Ces règles aident en attendant, mais ne remplacent pas un correctif.
• Isoler les applications exposées sur Internet. Le CERT-EU le recommande tant que le correctif n’est pas appliqué et vérifié.

Deux idées reçues sont à écarter. Masquer les erreurs avec display_errors ou l’opérateur @ ne protège pas. De plus, l’absence de traces dans les journaux ne prouve pas qu’un serveur est sain.

Équipements réseau basés sur PHP

Certains pare-feu reposent sur PHP, notamment OPNsense et pfSense. Appliquez les mises à jour de l’éditeur dès qu’elles sont disponibles. Par ailleurs, n’exposez jamais leur interface d’administration sur Internet.

Ce qu’il faut retenir

• Les deux failles, CVE-2026-109618 et CVE-2026-109619, sont critiques (CVSS v4.0 : 9.2).
• Mettre à jour WordPress ne suffit pas : c’est PHP qu’il faut corriger.
• Les versions corrigées sont 8.5.12, 8.4.27, 8.3.36 et 8.2.35.
• Les branches 8.1 et antérieures dépendent des distributions ou des hébergeurs. Il faut donc migrer dès que possible.
• L’exploitation est en cours et devrait s’amplifier. Par conséquent, redémarrez tous les processus PHP après la mise à jour.
• Les mesures temporaires et les règles WAF ne sont donc qu’un filet de sécurité.

Source : Avis de sécurité PHP : CVE-2026-109618 et CVE-2026-109619 (PHP2Shell)