Failles du moteur PHP de base PHP2Shell, risque lié au code propre

Votre application peut passer une revue de code, échapper ses entrées et garder une logique d’authentification assez propre pour faire brièvement croire à un auditeur en l’humanité. Puis l’environnement d’exécution situé en dessous peut quand même tendre un pied-de-biche à un visiteur non authentifié. C’est la leçon inconfortable de PHP2Shell, les deux failles PHP suivies sous les références CVE-2026-109618 et CVE-2026-109619.

Le risque principal n’est pas que toutes les applications PHP aient soudainement oublié comment être sécurisées. C’est que le moteur PHP lui-même se trouve dans la zone d’impact, ce qui signifie qu’un code applicatif propre peut reposer sur une couche d’exécution dangereuse. Les notes de correctifs se lisent souvent comme des manuels d’électroménager, mais quand un interpréteur central reçoit des correctifs critiques, c’est que la cave a commencé à faire du bruit.

Ce qui s’est passé sous le framework, selon la CISA et Huntress

La CISA a indiqué que PHP2Shell permet l’exécution de code à distance sans authentification dans PHP et affecte toutes les installations PHP qui servent des requêtes web. Huntress a déclaré que les déploiements exposés incluent PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le détail crucial pour les développeurs est l’ordre des événements : Huntress a décrit un chemin d’exploitation via mod_php qui peut se déclencher « avant que le moindre code applicatif ne s’exécute ». C’est le rebondissement le moins apprécié du théâtre de la sécurité, parce que votre contrôleur n’a même pas l’occasion d’avoir l’air courageux.

@title Chemin d’une requête PHP2Shell
@source CISA
@source Wiz Blog

  Web request
     │
     ▼
  PHP core
     │
     ├→ Code execution
     └→ Memory disclosure

@caption L’étape risquée se produit dans PHP lui-même, sous le code applicatif que les équipes examinent généralement.

BleepingComputer a rapporté que PHP prévoyait des mises à jour de sécurité d’urgence pour le 21 octobre à 14 h 00 UTC, les deux failles étant notées 9,2 selon CVSS v4.0. Huntress a ensuite indiqué que l’équipe PHP avait publié PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 vers 9 h 30 HE le 21 octobre. La CISA a aussi déclaré ne pas avoir observé d’exploitation au moment de la publication, ce qui est un contexte utile, pas une autorisation d’attendre que le scanner arrête de hurler.

Pourquoi un code applicatif propre ne vous sauve pas, selon Wiz et SANS

Wiz a indiqué que les vulnérabilités se trouvent dans PHP lui-même, indépendamment de l’application qui s’exécute au-dessus. Wiz a aussi déclaré que les versions remontant jusqu’à PHP 5.4 sont affectées par au moins l’une des failles, et que les bugs peuvent permettre à des attaquants non authentifiés d’exécuter du code ou de lire la mémoire du processus. Cette mémoire peut contenir des mots de passe, des jetons d’authentification, des clés d’API et des certificats, ce qui revient à peu près, côté runtime, à laisser l’armoire à dossiers ouverte pendant un exercice d’incendie.

SANS a également décrit le problème comme une vulnérabilité du cœur de PHP et a indiqué que les installations PHP par défaut devaient être considérées comme vulnérables. Il a aussi averti que seul PHP 8 devait recevoir un correctif, car les anciennes versions ne sont plus prises en charge. C’est là que les logiciels hérités cessent d’être une stratégie de continuité d’activité pour ressembler davantage à une antiquité hantée avec un câble réseau.

La fenêtre de réponse, selon The Record et BleepingComputer

The Record a rapporté que les bugs peuvent permettre l’exécution de code à distance sur des sites web non corrigés et que des centaines de sites ont été mis hors ligne pendant que les administrateurs réagissaient. Il a aussi cité l’équipe de sécurité de PHP, qui exhortait les utilisateurs à se préparer afin de pouvoir mettre à niveau dès que la version serait disponible. C’est la version responsable de la panique : courte, planifiée et, de préférence, suivie d’une fenêtre de maintenance plutôt que d’un pont de crise.

BleepingComputer a rapporté que les failles étaient suivies sous les références CVE-2026-109618 et CVE-2026-109619, et que les chercheurs pensaient qu’elles affectaient les versions PHP 5, 6, 7 et 8. SANS a indiqué que les premières recommandations suggéraient de définir session.upload_progress.enabled sur Off comme mesure d’atténuation partielle, mais le mot partielle fait ici beaucoup de travail. L’atténuation fait gagner du temps. Le correctif règle l’addition.

Ce qui change vraiment pour les équipes, selon la CISA et SANS

La CISA a demandé aux organisations d’identifier et d’inventorier les systèmes exécutant n’importe quelle version de PHP, puis de prioriser l’application des correctifs sur les systèmes exposés à Internet. Elle a aussi averti que la « prévalence » de PHP pouvait ne pas être directement observable, car il peut être intégré comme composant d’autres logiciels. Traduction : si votre inventaire d’actifs ne connaît que le nom de l’application, et pas le runtime qui tourne en dessous, félicitations, vous avez inventé le cache-cache pour la réponse aux incidents.

SANS a noté que de nombreux produits pare-feu et routeurs open source utilisent PHP et a conseillé de ne pas exposer les interfaces d’administration web à Internet. Ce conseil n’est pas très glamour, mais expliquer pourquoi un panneau d’administration est devenu la porte d’entrée ne l’est pas non plus. L’inventaire des runtimes devrait couvrir les applications web basées sur PHP, les systèmes de gestion de contenu, les interfaces d’administration web et les logiciels de fournisseurs dans lesquels PHP peut être empaqueté sous le nom du produit.

Ce que cela signifie vraiment pour vous

Si vous exécutez PHP pour servir des requêtes web, passez à PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, comme le recommande la CISA. Si vous êtes sur PHP 8.1 ou une version antérieure, traitez cela comme un problème de runtime non pris en charge, pas simplement comme un élément du backlog développeur. La leçon pour les équipes qui construisent des logiciels dépasse cette paire de CVE : la sécurité applicative doit inclure l’interpréteur, l’intégration au serveur web et les dépendances de plateforme discrètes qui exécutent du code avant que votre propre code ait eu le temps de se présenter.

La prochaine chose à surveiller est de savoir si les produits en aval publieront leurs propres mises à jour et si les inventaires d’actifs peuvent réellement trouver PHP là où il est glissé à l’intérieur d’autres logiciels. Pas besoin de musique apocalyptique. Corrigez simplement le runtime, vérifiez la version en cours d’exécution, réduisez l’exposition inutile à Internet et ajoutez les moteurs de langage à la liste des éléments que votre programme de sécurité traite comme une infrastructure de production plutôt que comme de la plomberie.