Les vulnérabilités PHP2Shell : des failles critiques exploitées avant leur correction

Deux vulnérabilités critiques, CVE-2026-109618 (corruption mémoire via gestion des erreurs OOM) et CVE-2026-109619 (réutilisation d’un état global obsolète), ont été corrigées en urgence par la PHP Foundation le 21 octobre 2026. Ces failles, découvertes par Wiz, OpenAI et Calif dès août 2026, permettent une exécution de code à distance (RCE) sans authentification, avec un score CVSS de 9,2 selon Palo Alto Unit 42.

Les correctifs, intégrés aux versions PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, concernent également des backports minimaux pour les versions 7.4, 8.0 et 8.1. Cependant, les versions antérieures à PHP 8.1 ne bénéficieront d’aucune correction, comme le souligne Cisco Talos, car leur support a pris fin. Les failles affectent toutes les installations PHP traitant des requêtes web, qu’il s’agisse d’Apache avec mod_php, PHP-FPM, php-cgi, FrankenPHP ou LiteSpeed.

La PHP Foundation a accéléré la publication des correctifs après qu’un proof-of-concept (PoC) fonctionnel ait été accidentellement divulgué avant la date prévue. WatchTowr a détecté des tentatives d’exploitation dans la nature dès le 21 octobre, bien qu’aucune attaque réussie n’ait encore été confirmée. Ces vulnérabilités touchent 70 % des sites web mondiaux, indépendamment de leur système de gestion de contenu (CMS), selon la PHP Foundation.

Ces vulnérabilités touchent des parties de PHP que presque chaque requête sollicite : la gestion mémoire et le traitement des erreurs, des composants au cœur de la sécurité des sites web.

Mécanismes des failles : des erreurs profondes dans le cœur de PHP

La CVE-2026-109618 exploite une faille dans la gestion des erreurs de mémoire (OOM), où un saut de contrôle (longjmp()) interrompt le traitement d’une requête HTTP alors que les données internes ne sont pas encore entièrement initialisées. La CVE-2026-109619, quant à elle, résulte d’un état global réutilisé après que sa mémoire ait été libérée, permettant une exécution de code arbitraire, comme l’explique Unit 42.

Ces failles sont particulièrement dangereuses car elles sont déclenchées avant même que le code applicatif ne s’exécute, comme le précise Cisco Talos. Une requête HTTP malveillante suffit à exploiter ces vulnérabilités, ce qui les rend accessibles même sur des sites utilisant des CMS populaires comme WordPress, Drupal, Magento ou Shopware, à condition qu’ils tournent sur une version de PHP affectée.

La PHP Foundation souligne que ces failles résident dans des composants critiques de PHP : la gestion mémoire et la prise en charge des erreurs, des parties traversées par presque toutes les requêtes. Une fois exploitées, elles permettent non seulement d’exécuter du code à distance, mais aussi de lire la mémoire des processus sensibles du serveur.

Réactions des éditeurs de sécurité : protections immédiates et mitigation

Plusieurs acteurs majeurs de la cybersécurité ont réagi rapidement pour protéger leurs clients. Cloudflare a déployé dès le 21 octobre des règles WAF (Web Application Firewall) pour bloquer les attaques exploitant ces failles, en utilisant une analyse complète des transactions HTTP pour réduire les faux positifs. Ces protections sont activées par défaut pour tous les utilisateurs, y compris les plans gratuits, avec un identifiant de règles spécifique (Ruleset ID 77454fe2d30c4220b5701f6fdfb893ba).

De son côté, Palo Alto Networks a identifié plus de 22,6 millions d’instances PHP exposées via son outil Cortex Xpanse. L’entreprise propose des mises à jour pour ses produits Cortex XDR, Cortex Cloud et XSIAM, ainsi qu’une protection via le Frontier Virtual Patching (Threat ID 543004) depuis le 20 octobre. Cisco Talos a également publié des signatures SNORT (67359 et 67360) pour détecter les attaques, disponibles dans le Community Ruleset.

Malgré ces protections, les éditeurs insistent sur la nécessité de mettre à jour PHP en urgence. Cloudflare recommande ainsi de combiner les correctifs avec les règles WAF pour une défense en profondeur. Talos précise que les versions PHP 8.1 et antérieures, déjà en fin de vie, ne recevront aucun correctif, et conseille vivement de migrer vers PHP 8.2 ou une version ultérieure.

Ce que cela change ici : risques pour les entreprises et administrations d’Afrique de l’Ouest

Les vulnérabilités PHP2Shell représentent un risque majeur pour les entreprises et administrations d’Afrique de l’Ouest, où PHP est largement utilisé pour héberger des sites web, des plateformes e-commerce et des systèmes internes. Plus de 70 % des sites web béninois ou régionaux pourraient être concernés, notamment ceux basés sur des CMS comme WordPress, Drupal ou des frameworks comme Laravel, si leur infrastructure tourne sur une version de PHP non corrigée.

Les conséquences d’une exploitation réussie seraient graves :

• une prise de contrôle totale des serveurs web, permettant aux attaquants de déployer des malwares ou des ransomwares;
• l’exfiltration de données sensibles (bases clients, informations financières, données personnelles) ;
• l’utilisation frauduleuse de la réputation des sites infectés pour des campagnes de phishing ou de diffusion de contenu malveillant, comme le souligne Shahak Shalev de Malwarebytes.

Pour les administrations, les risques incluent une disponibilité compromise des services en ligne (portails gouvernementaux, plateformes de paiement public) et une perte de confiance des citoyens. Les entreprises, quant à elles, pourraient subir des perturbations opérationnelles, des fuites de propriété intellectuelle ou des sanctions réglementaires en cas de non-conformité aux obligations de sécurité des données.

Des mesures immédiates s’imposent :

• vérifier la version de PHP utilisée et appliquer les correctifs officiels (8.5.12, 8.4.27, etc.) ;
• pour les versions non supportées (PHP 8.1 et antérieures), envisager une migration vers une version maintenue ;
• activer des protections complémentaires comme les règles WAF (Cloudflare, Palo Alto) ou les signatures SNORT ;
• limiter temporairement les risques en ajustant les paramètres PHP (memory_limit, post_max_size, désactivation de session.upload_progress.enabled) comme suggéré par Cisco Talos.

Les organisations devraient également surveiller les alertes des éditeurs de sécurité et considérer des audits externes pour identifier d’éventuelles expositions résiduelles, surtout si elles dépendent de configurations personnalisées ou de modules tiers.