L'Halloween a apporté une vulnérabilité déguisée. PHP2Shell est le nom qui circule pour désigner une paire d'enregistrements CVE critiques dans le cœur de PHP, CVE-2026-109618 et CVE-2026-109619, tous deux permettant une exécution de code à distance sans authentification. Le nom fait beaucoup de travail à lui seul. Un bon nom place un bogue sur le téléphone du RSSI avant même que l'avis soit lisible, et dans ce cas, le branding est littéralement arrivé avant les faits : une vidéo de preuve de concept sous embargo et des diffs de conteneurs préliminaires ont fuité le 20 octobre, avant la divulgation coordonnée.

Maintenant que la poussière est retombée après la publication d'urgence du 21 octobre, séparons les faits vérifiés du moulin à rumeurs des médias sociaux. Les deux vulnérabilités résident dans le code C du Zend Engine lui-même et touchent toutes les versions de PHP de 5.4 à 8.5.11. Découvertes indépendamment en août par des chercheurs de Calif (avec OpenAI) et de Wiz Research grâce à des audits de code assistés par IA, les deux failles obtiennent un score CVSS v4.0 officiel de 9,2 :

• CVE-2026-109618 (corruption mémoire hors limites) : Lorsqu'une requête forgée épuise memory_limit en cours d'analyse, PHP abandonne via longjmp() avant que les structures internes soient entièrement initialisées, ce qui amène la routine de nettoyage à libérer de la mémoire non initialisée. Contre Apache mod_php, une seule requête non authentifiée peut déclencher une RCE avant qu'une seule ligne de code applicatif ne s'exécute.

• CVE-2026-109619 (état global périmé) : Après une erreur fatale, des pointeurs appartenant à la requête peuvent subsister en pointant vers de la mémoire libérée. La requête suivante traitée par le même worker persistant (comme PHP-FPM) réutilise cet état corrompu, notamment via le paramètre session.upload_progress.enabled activé par défaut.

Dans les 48 premières heures suivant la dénomination d'un bogue, le récit comporte toujours trois couches : ce que dit l'avis officiel, ce que disent les billets des chercheurs, et ce que répètent à l'envi un millier de reposts paniqués. Le catalogue Known Exploited Vulnerabilities (KEV) de la CISA () demeure le signal fiable ici. Bien que les réseaux de honeypots d'Amazon, de Cloudflare et d'Arctic Wolf aient déjà détecté de l'exploration opportuniste et des sondes de botnets, la CISA a indiqué dans son alerte du 21 octobre qu'elle n'avait pas encore confirmé de compromissions réussies dans la nature, et aucun des deux CVE n'a encore été ajouté au KEV.

Ce que nous pouvons analyser avec une totale certitude, c'est ce qui vient ensuite, car le livre de jeu post-exploitation ne change jamais. Qu'un attaquant utilise PHP2Shell pour exécuter des commandes directement en mémoire (MITRE ATT&CK T1190) ou dépose un web shell persistant (T1505.003, ), la charge utile s'exécute sous l'identité du serveur web. Et dans beaucoup trop d'environnements, cette identité est un compte de service discrètement puissant, avec un mot de passe de base de données stocké dans un fichier de configuration juste à côté.

C'est pourquoi une publication IAM écrit sur un bogue PHP. L'exploit est le point d'entrée. L'identité est le butin. Une fois qu'un attaquant exécute du code en tant que www-data ou l'utilisateur du pool de workers FPM, les questions qui déterminent si c'est un mauvais après-midi ou un mauvais trimestre sont toutes des questions d'identité :

• Quels justificatifs ce processus peut-il lire ? Utilisateurs de base de données, clés API, secrets de clients OAuth, et rôles d'instances cloud accessibles via le point de terminaison de métadonnées.

• Que peuvent faire ces justificatifs ? Un utilisateur de base de données qui n'a besoin que du SELECT sur trois tables, mais qui détient les droits DBA parce que « c'était plus simple en 2019 », transforme un worker compromis en violation de données complète.

• Quelle est la propre identité de l'hôte web ? Un rôle IAM trop permissif attaché à l'instance de calcul est le chemin le plus rapide d'une seule machine vers l'ensemble du compte infonuagique. AWS documente le durcissement des métadonnées d'instance (IMDSv2) précisément pour cette raison ().

• Le verriez-vous seulement ? Les workers compromis sont bruyants si vous journalisez le comportement des processus, et silencieux si vous surveillez uniquement les journaux HTTP. Les connexions sortantes d'un serveur web vers des hôtes inconnus, les nouveaux fichiers dans des répertoires accessibles en écriture par le web, et les workers PHP qui lancent /bin/sh, curl ou wget sont des détections peu coûteuses et à fort signal.

PHP offre des leviers de configuration qui réduisent la surface d'exposition pendant que vous testez le correctif (). Pour PHP2Shell en particulier, définir session.upload_progress.enabled = 0 et (sous PHP 8.5) fatal_error_backtraces = 0 ferme les chemins les plus courants de CVE-2026-109619. Verrouiller disable_functions (exec, shell_exec, system, passthru) et open_basedir reste une bonne hygiène contre les charges utiles PHP opportunistes, bien que, PHP2Shell corrompant la mémoire dans le moteur C sous-jacent, un exploit sophistiqué puisse contourner les restrictions de php.ini en mémoire. Le confinement au niveau du système d'exploitation (SELinux, AppArmor, et limites mémoire strictes avec cgroup v2) est là où réside la vraie frontière.

Du côté IAM, les conseils en vigueur sont peu spectaculaires et justes. Accordez au niveau web le minimum de permissions nécessaires, faites pivoter les secrets qu'il détient, sortez ces secrets des fichiers .env plats pour les placer dans un gestionnaire de secrets avec des jetons à courte durée de vie, et traitez le compte de service du serveur web comme un principal à auditer au même titre que n'importe quel administrateur humain. Les comptes de service ne se plaignent pas lors d'entrevues de départ, alors personne ne les révise. C'est tout le problème.

Voici la partie encourageante, et je le pense sincèrement. Chaque bogue portant un nom effrayant est un exercice tabletop gratuit. Vous n'avez pas besoin d'attendre le prochain CVE pour répondre à cette question : « Si un inconnu exécutait du code sur notre niveau PHP ce soir, qu'obtiendrait-il, et le saurions-nous ? » Si votre réponse honnête vous fait grimacer, félicitations : vous venez de trouver la vraie vulnérabilité, et elle n'avait pas besoin d'un numéro CVE.

Mettez à jour vers PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 (et si vous exécutez encore PHP 8.1 ou 7.x en fin de vie, reconnaissez qu'aucun correctif amont n'arrivera). Surveillez le KEV de la CISA. Entre-temps, réduisez la portée du niveau web. Le déguisement disparaîtra d'ici lundi. Le compte de service sur-privilégié, lui, sera toujours là, à moins que vous ne vous en occupiez.