Failles divulguées prématurément : les attaques actives ont devancé les correctifs de quatre jours
Le 21 octobre 2026, l’équipe officielle de maintenance de PHP a publié des correctifs d’urgence pour deux vulnérabilités critiques d’exécution de code à distance (RCE) : CVE-2026-109618 et CVE-2026-109619. Ces deux failles affichent un score CVSS v4.0 de 9.2. Les versions corrigées couvrent PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Fait exceptionnel, l’équipe de sécurité a également fourni des rétro-portages (backports) au niveau du code source pour les branches obsolètes 7.4, 8.0 et 8.1.
Le modèle traditionnel de divulgation coordonnée des vulnérabilités repose sur l’hypothèse que les correctifs parviennent aux défenseurs avant que les attaques ne se propagent sur Internet. Dans le cas de l’incident baptisé PHP2Shell, ce mécanisme a volé en éclats. Bien avant la publication officielle, l’entreprise de sécurité Huntress a émis une alerte intitulée « Leaked Critical PHP Vulnerabilities », avertissant que les détails techniques avaient déjà fuité par des canaux non officiels. Les mainteneurs de PHP ont alors réagi de manière inédite en diffusant l’annonce n° 509 sur php.announce pour exhorter les administrateurs système du monde entier à se préparer. Ars Technica a relayé cette alerte anormale, soulignant que cette démarche préventive des mainteneurs démontrait une perte de contrôle totale sur le calendrier.
Les attaquants n’ont pas attendu les correctifs. Datadog Security Labs avait déjà conçu de manière indépendante un exploit fonctionnel avant la divulgation publique. De son côté, l’équipe de renseignement sur les menaces d’AWS a confirmé, via son réseau de serveurs leurres (honeypots) MadPot, que des tentatives réelles d’exploitation avaient été interceptées dès le 17 octobre, soit quatre jours complets avant l’annonce officielle. Les serveurs connectés à Internet étaient déjà la cible de sondages offensifs avant même que les équipes de défense ne reçoivent la moindre alerte institutionnelle.
La société de cybersécurité Sansec a aussitôt averti que des vagues d’attaques automatisées frapperaient l’ensemble du réseau mondial dans les quinze minutes suivant la publication des correctifs. Au 21 octobre, Datadog s’appuyait sur la télémétrie de Patchstack pour confirmer que de multiples exploitations réelles et des analyses massives et indifférenciées balayaient déjà Internet. Les attaquants et les défenseurs ayant accédé au code du correctif au même instant, la fenêtre temporelle habituellement dédiée à la planification des mises à jour a été réduite à néant.
Figure : Périmètre d’impact et chaîne d’attaque de PHP2Shell publiés par Datadog Security Labs. Source : Datadog Security Labs
Exécution avant le code applicatif : le nettoyage de l’interpréteur délivre un shell
La plupart des architectures de sécurité web concentrent leurs défenses sur l’authentification au niveau des passerelles, le contrôle des accès et l’audit du code applicatif. Pourtant, lors des tests reproduits par Datadog Security Labs, PHP2Shell a contourné l’ensemble des couches de logique applicative. Dans un environnement de test exécutant PHP 8.5.11, Apache prefork avec mod_php et des paramètres classiques (memory_limit=16M, post_max_size=64M), une simple requête HTTP POST non authentifiée et spécialement forgée a suffi pour prendre le contrôle absolu de la machine hôte.
Le déclencheur se situe au niveau du moteur d’exécution en C de l’interpréteur PHP. Dès la réception de la requête hostile, une erreur d’analyse syntaxique (parsing) est immédiatement provoquée. À cet instant, le flux d’exécution n’a pas encore été transféré au moindre script applicatif. Lors de la routine interne de nettoyage de PHP pour les requêtes avortées, le moteur exécute directement les commandes système injectées dans la charge utile de l’attaquant. Même sur un serveur n’hébergeant qu’un script minimal affichant une chaîne statique, l’ensemble du système d’exploitation est compromis dès l’échec de l’analyse syntaxique.
Cette vulnérabilité frappe pratiquement tous les modes de déploiement en production. D’après les rapports de Huntress et le suivi technique de l’incident, les versions s’étendant de PHP 5 à PHP 8 sont toutes exposées. Les environnements touchés incluent Apache mod_php, le mode php-cgi, le moteur de production à haute concurrence PHP-FPM, ainsi que FrankenPHP et LiteSpeed. Aucune couche d’authentification applicative ne peut intervenir au stade du parsing.
Figure : Flux d’appels montrant la routine de nettoyage consécutive à l’échec d’analyse exécutant des commandes système. Source : Datadog Security Labs
Compteur incrémenté avant allocation : dissection de la double faille CVE
Les deux vulnérabilités exploitent des défauts structurels distincts au cours du cycle de traitement d’une requête HTTP. Pour CVE-2026-109618, le problème réside dans la routine de nettoyage consécutive à un échec d’allocation mémoire, qui accorde à tort sa confiance à des structures non initialisées. Le point de rupture se trouve au cœur du moteur Zend, au sein de la fonction _zend_hash_str_add_or_update_i(). Lorsqu’elle insère des paires clé-valeur dans une table de hachage, cette fonction incrémente le compteur de compartiments (buckets) avant même de réserver la mémoire nécessaire au stockage de la clé.
Si l’allocation de la clé dépasse la limite fixée par memory_limit, le moteur Zend déclenche immédiatement une erreur fatale. Cependant, le compteur interne a déjà comptabilisé le nouveau nœud non initialisé, qui conserve des octets résiduels (dirty bytes) issus d’opérations antérieures sur le tas (heap). La routine de nettoyage subséquente traite ces octets corrompus comme des variables légitimes et tente de les détruire. En manipulant ces reliquats de mémoire, l’attaquant peut détourner le flux d’exécution pour invoquer system(). Même dans PHP 8.5.12, le compteur continue d’être incrémenté avant l’allocation ; le correctif officiel a révisé la gestion d’erreur afin qu’une allocation avortée ne laisse plus d’entrées semi-initialisées.
La seconde vulnérabilité, CVE-2026-109619, tire parti du partage d’état entre requêtes successives au sein des processus de traitement (workers). Sous PHP 8.5 et mod_php, les traces d’appels consécutives à des erreurs fatales peuvent conduire directement à une exécution de commande arbitraire. De manière plus générale lors du téléversement de fichiers multipart, les états de session ou de décodeurs abandonnés après une erreur fatale persistent et polluent les requêtes suivantes. La directive session.upload_progress.enabled, activée par défaut sur de nombreux systèmes, fonctionne en arrière-plan sans qu’aucun script n’ait besoin d’appeler explicitement session_start().
L’exploitation réussie de CVE-2026-109619 exige que plusieurs requêtes hostiles consécutives atteignent exactement le même processus worker. Dans les architectures à processus multiples ou à fort trafic, la probabilité d’atteinte sur une seule tentative est diluée, mais cette contrainte purement statistique n’enlève rien à la gravité de la faille.
Figure : Mécanisme de réutilisation de mémoire non nettoyée entre requêtes successives au niveau des workers. Source : Datadog Security Labs
Désactiver la progression de téléversement ne suffit pas : la configuration ne répare pas la mémoire
Dès l’annonce des failles, une recommandation temporaire a circulé au sein de la communauté suggérant de positionner session.upload_progress.enabled = 0. Cet ajustement crée un angle mort critique. S’il bloque certains vecteurs de téléversement liés à CVE-2026-109619, il est totalement inopérant contre l’anomalie d’allocation mémoire de CVE-2026-109618. Laisser cette dernière non corrigée expose le serveur à une compromission totale, que la progression des envois soit coupée ou non.
L’équipe officielle de maintenance de PHP a ensuite publié des directives strictes de remédiation temporaire. Pour CVE-2026-109618, elle préconise d’imposer impérativement memory_limit = -1. Parallèlement, les administrateurs doivent brider drastiquement la taille du corps des requêtes au niveau du reverse proxy et appliquer des plafonds de mémoire via cgroups à l’échelle du conteneur. Il est expressément interdit d’utiliser des quotas par processus comme RLIMIT_AS ou RLIMIT_DATA, car ces limites artificielles provoquent précisément les échecs d’allocation requis par l’exploit.
Pour CVE-2026-109619, outre la coupure de la progression de téléversement, les serveurs tournant sous PHP 8.5 doivent configurer fatal_error_backtraces = 0. Tous ces paramètres doivent impérativement être pris en compte avant l’analyse des requêtes, ce qui impose un redémarrage complet de chaque processus worker. Le CERT-EU a recommandé dans son bulletin d’alerte 2026-018 d’isoler immédiatement du réseau les applications ne pouvant recevoir de mise à jour instantanée. Datadog recommande en complément de bloquer les requêtes anormales dès le reverse proxy ou les passerelles en bordure de réseau.
Régler 40 ans de dette technique : le remplacement immédiat du moteur d’exécution comme unique rempart
En observant le déroulement de la crise PHP2Shell, on constate que la véritable victime n’a pas seulement été le parser de PHP, mais tout le protocole d’application sereine des mises à jour : l’éditeur livre le correctif, diffuse l’alerte, puis les entreprises mettent à jour selon leur calendrier de maintenance. Avec une fuite précoce et quatre jours d’attaques silencieuses en amont, la marge de sécurité des défenseurs s’est effondrée. Les attaquants et les administrateurs ont reçu le correctif au même instant, et les scans automatisés mondiaux ont démarré quelques minutes après la divulgation.
IEEE Spectrum a résumé cet événement avec pertinence : l’essor de l’IA force l’industrie informatique à rembourser d’un coup 40 années d’accumulation de dette technique. PHP2Shell en est la démonstration parfaite : incrémenter un compteur avant l’allocation de la mémoire était une habitude de codage que personne n’avait remise en question depuis des décennies. Même le correctif de PHP 8.5.12 a corrigé la gestion des erreurs périphériques plutôt que de réordonner la logique du compteur.
Les équipes d’exploitation vérifiant l’intégrité de leur parc doivent surveiller trois indicateurs caractéristiques : une recrudescence soudaine d’erreurs de dépassement de mémoire (Out of Memory) lors de l’initialisation des requêtes, la soumission de formulaires volumineux contenant des noms de champs anormaux, et l’apparition inattendue de processus shells enfants sous le compte d’exécution du serveur web. Ces signes traduisent des tentatives d’exploitation active visant l’interpréteur.
Face à la disparition des délais de réaction, les retouches de configuration ne restent que des palliatifs précaires. Le filtrage sur les reverse proxies peut atténuer le trafic hostile, mais ne résout pas la faille intrinsèque de l’interpréteur. Remplacer sans délai les environnements d’exécution vulnérables sur l’ensemble des serveurs de production reste la seule stratégie viable pour les défenseurs.
Liens de référence :
- Rapport technique d’analyse des failles de Datadog Security Labs
- Annonces officielles de sécurité de PHP et bulletin php.announce n° 509
- Rapport de veille sur les menaces de Huntress
- Données de télémétrie de l’AWS Security Blog
- Analyse thématique d’Ars Technica
- Bulletin d’alerte de sécurité CERT-EU 2026-018
- Dossier d’analyse approfondie d’IEEE Spectrum
