PHP2Shell : deux failles critiques RCE dans PHP

PHP2Shell est le nom donné par les chercheurs à deux vulnérabilités critiques révélées le 21 octobre 2026 dans le runtime PHP lui-même, et non dans une application construite avec ce langage. Selon l'avis officiel publié sur php.net, un attaquant non authentifié peut, dans certaines configurations, exécuter du code arbitraire sur le serveur sans la moindre interaction de la victime.

Que sait-on des deux failles de PHP2Shell ?

Deux CVE sont concernées, toutes deux notées 9,2 sur l'échelle CVSS v4.0 selon l'avis PHP :

• CVE-2026-109618 : une corruption mémoire liée à la gestion des situations de manque de mémoire (« out-of-memory »). Une requête interrompue à ce moment laisse des données internes partiellement initialisées, que le nettoyage de la requête traite ensuite comme valides.
• CVE-2026-109619 : un état interne obsolète qui survit après la libération de sa mémoire. Un worker PHP réutilisé pour une requête suivante peut exploiter cet état avant la réinitialisation normale. L'avis PHP précise que cette faille implique le mécanisme session.upload_progress.

Les deux failles touchent, selon php.net, la quasi-totalité des versions PHP depuis la branche 5.4, sur toutes les interfaces courantes : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le projet PHP considère le risque le plus élevé pour mod_php, où un exploit démontré permet de déclencher l'attaque avant même l'exécution du code de l'application.

Pourquoi ces failles sont-elles si critiques ?

Parce qu'elles se situent dans le moteur PHP et non dans le code métier, aucune bonne pratique de développement ne protège une application : un site parfaitement sécurisé côté code reste exposé si le runtime sous-jacent ne l'est pas. Un attaquant qui parvient à déclencher la faille peut, selon l'avis PHP, lire la mémoire d'autres requêtes traitées par le même worker, où peuvent se trouver mots de passe, jetons de session, clés API ou certificats appartenant à d'autres utilisateurs du même serveur.

L'origine du bug remonterait, selon le chercheur Calif qui a participé à la découverte, à des choix d'implémentation datant de 2004. Les failles ont été identifiées et signalées par Wiz Research, Calif et l'équipe Codex Security d'OpenAI ; l'équipe de sécurité de PHP et l'équipe Gemini de Google ont ensuite travaillé sur les correctifs, selon les sources citées par The Hacker News.

Versions concernées et correctifs disponibles

PHP 8.1 et les versions antérieures ne reçoivent plus de correctifs du projet PHP ; des backports source existent pour les branches 7.4, 8.0 et 8.1 dans le dépôt php-src, et certaines distributions Linux ou fournisseurs LTS publient leurs propres paquets corrigés sans forcément changer le numéro de version affiché. Vérifiez le changelog de votre distribution plutôt que la seule version PHP annoncée par php -v.

Exploitation en cours : ce que l'on sait

PHP avait initialement prévu de publier son avis le 22 octobre, mais a avancé la divulgation au 21 octobre à 14 h 00 UTC après la fuite d'informations la veille sur un forum, selon The Hacker News. Cloudflare indique avoir observé des tentatives d'exploitation précoces et avoir déployé des règles de pare-feu applicatif à titre provisoire. De son côté, la société de recherche watchTowr, qui dit avoir reproduit la faille CVE-2026-109618, n'avait constaté aucune exploitation confirmée à 11 h 26 UTC le 21 octobre, et aucune des deux failles ne figurait alors dans le catalogue des vulnérabilités activement exploitées de la CISA.

Par précaution, plusieurs organisations ont mis des services hors ligne. L'éditeur de paie BambooHR a interrompu une partie de son service sans donner de délai de rétablissement. Aux Pays-Bas, selon le média NOS, les portails MijnOverheid et DigiD, la Chambre basse du Parlement et le centre national de cybersécurité ont été temporairement coupés par précaution, ce dernier n'ayant constaté aucun abus à ce stade.

Comment se protéger si vous ne pouvez pas patcher immédiatement ?

La mise à jour reste la seule protection complète, mais l'avis PHP propose des mesures provisoires en attendant de pouvoir l'appliquer :

• Pour CVE-2026-109618 : fixez memory_limit à une valeur illimitée (-1) ou abaissez post_max_size, et limitez la taille des requêtes au niveau du serveur web ou du proxy. Évitez d'utiliser RLIMIT_AS ou RLIMIT_DATA pour contraindre la mémoire, ce qui aggraverait le problème.
• Pour CVE-2026-109619 : désactivez la fonctionnalité avec session.upload_progress.enabled=0, puis redémarrez les workers PHP pour que le changement s'applique. Sur PHP 8.5, ajoutez aussi fatal_error_backtraces=0.
• Si vous administrez un serveur mod_php exposé publiquement, basculer vers PHP-FPM réduit la surface d'attaque en attendant la mise à jour, PHP-FPM se comportant différemment face à l'exploit démontré.
• Côté détection, surveillez les redémarrages anormaux ou répétés de workers PHP-FPM, les segmentation faults inhabituels dans les journaux, et toute connexion sortante inattendue depuis le serveur web après un pic de requêtes volumineuses ou malformées.
• Surveillez les changelogs de votre distribution Linux ou de votre hébergeur : plusieurs fournisseurs ont reçu les correctifs en avance et peuvent déjà proposer un paquet corrigé sans changement visible de version.

Pour suivre l'exposition de votre périmètre et prioriser vos correctifs, notre base de données de CVE recense les vulnérabilités publiées avec leur statut d'exploitation, et notre calculateur de score CVSS aide à évaluer l'urgence d'un correctif selon votre contexte. D'autres failles critiques corrigées récemment, comme celle touchant Windows Shell ou WordPress, suivent le même principe : patcher vite, puis vérifier.

Points clés

• PHP2Shell regroupe deux failles critiques du runtime PHP, CVE-2026-109618 et CVE-2026-109619, notées 9,2/10 en CVSS v4.0 selon l'avis officiel PHP.
• Elles permettent une exécution de code à distance non authentifiée et touchent quasiment toutes les versions depuis PHP 5.4, sur mod_php, PHP-FPM, php-cgi, FrankenPHP et LiteSpeed.
• Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 ; PHP 8.1 et les versions antérieures ne reçoivent plus de mise à jour du projet.
• Selon Cloudflare, des tentatives d'exploitation précoces ont été observées, mais aucune exploitation confirmée ni inscription au catalogue CISA KEV n'était signalée au moment de la publication de cet article.
• En l'absence de mise à jour immédiate, appliquez les mesures provisoires de l'avis PHP, renforcez la détection côté serveur, et surveillez les publications de votre distribution.