PHP2Shell : deux failles RCE critiques forcent un correctif d'urgence pour PHP

Aucune authentification requise, risque maximal sur les configurations les plus courantes, et des attaques déjà observées avant même la sortie du correctif. En vérifiant notre propre infrastructure pour écrire cet article, on a trouvé une instance non protégée — corrigée dans l'heure.

22 octobre 2026 · Équipe SunuCyberSecurity

Sources : avis de sécurité PHP, Centre canadien pour la cybersécurité, BleepingComputer — détail en fin d'article

Le 21 octobre 2026, le projet PHP a publié un correctif d'urgence pour deux failles critiques, baptisées « PHP2Shell » par les chercheurs qui les ont découvertes. Référencées CVE-2026-109618 et CVE-2026-109619, elles permettent à un attaquant non authentifié d'exécuter du code arbitraire sur n'importe quel serveur exposant PHP à l'écoute — ce qui, vu l'omniprésence de PHP sur le web africain (WordPress, applications métier, panneaux d'administration), concerne une part considérable de l'infrastructure en ligne de la région.

Ce que sont vraiment ces deux failles

Les deux CVE sont classées « Use After Free » (CWE-416) — une catégorie de bug mémoire où le programme continue d'utiliser une zone de mémoire après qu'elle a été libérée, ce qui permet à un attaquant de la manipuler pour détourner l'exécution. Le point commun : PHP peut laisser sa mémoire interne corrompue quand une requête se termine de façon anormale.

CVE-2026-109618 exploite cette corruption mémoire via une chaîne de faiblesses pour obtenir une exécution de code avec les privilèges du processus web (worker). CVE-2026-109619 repose sur un état global « périmé » (stale global state) : une requête suivante, traitée par le même worker, peut réutiliser un état qui n'a jamais été correctement réinitialisé — ouvrant la voie à une divulgation de mémoire et, là aussi, à une exécution de code.

Les deux failles sont notées 9,2 sur 10 en CVSS v4.0 par l'équipe sécurité de PHP elle-même. Fait important : le risque n'est pas identique selon la façon dont PHP est déployé. PHP évalue le risque comme maximal sur mod_php (le module Apache classique) — un exploit démontré permet de déclencher l'attaque via une simple requête non authentifiée, avant même que le code de l'application concernée ne s'exécute. PHP-FPM, php-cgi, FrankenPHP et LiteSpeed sont aussi concernés, avec une exploitabilité qui varie selon la configuration exacte.

Versions affectées et correctifs

PHP 8.1 et les versions antérieures ne reçoivent plus de correctifs du projet PHP lui-même — certaines distributions Linux (via leurs propres dépôts LTS) peuvent proposer un rétroportage, mais ce n'est pas garanti. Si votre infrastructure tourne encore sur une de ces branches, le vrai correctif est la montée de version, pas un simple patch ponctuel.

Exploitation : ce qu'on sait, à l'heure où on écrit

La situation évolue vite et les sources ne disent pas toutes la même chose. Ce qui est confirmé : avant même la sortie officielle du correctif, Dane Knecht, CTO de Cloudflare, a déclaré publiquement que Cloudflare observait déjà des tentatives d'attaque ciblant ces deux failles — un signal fort que le détail technique avait fuité avant le patch. Le NCSC britannique a, de son côté, averti les organisations de mettre à jour immédiatement ou de couper l'accès public aux systèmes concernés. Le projet PHP, lui, est resté prudent dans son propre avis : il n'a pas confirmé d'exploitation massive de son côté au moment de la publication, tout en reconnaissant que la situation pouvait changer rapidement.

Détail notable sur la découverte : les deux failles ont été trouvées avec l'aide d'outils d'IA, par les équipes de Wiz en collaboration avec OpenAI — une illustration concrète que l'IA sert aussi, de plus en plus, à défendre plutôt qu'à attaquer.

Mise à jour du 22 octobre, en journée : Cloudflare confirme avoir commencé à filtrer des tentatives d'exploitation dès 3h02 UTC le 21 octobre — avant même la sortie officielle du correctif à 16h — et avoir observé des attaquants modifier leurs charges utiles pour contourner ses règles de filtrage. En France, le CERT-FR a publié l'alerte officielle CERTFR-2026-ALE-014, recommandant d'isoler les machines concernées et de mettre à jour sans délai.

L'impact réel : des sites coupés par précaution, pas piratés

En France, le ministère de l'Intérieur a mis hors ligne l'ensemble de ses sites exposés — préfecture de police et préfectures de Seine-Saint-Denis, Hauts-de-Seine, Val-de-Marne, Essonne, Gironde, Bouches-du-Rhône et Savoie — en précisant explicitement agir « à la demande de l'ANSSI ». Bercy, Météo-France (qui a confirmé le lien) et Les Echos ont fait de même. Ameli, la CAF, l'URSSAF, les impôts et le site du CNES ont aussi été perturbés ou coupés, sans toujours confirmer ou démentir le lien avec la faille. La Ville de Paris et la métropole de Lille ont également coupé certains services.

Ailleurs en Europe : l'administration numérique fédérale allemande (ITZBund), le ministère belge des Affaires étrangères, plusieurs services de l'État finlandais, le port de Rotterdam, le site public néerlandais Overheid.nl et la fédération néerlandaise de football ont coupé leurs accès par précaution. La Wikimedia Foundation a elle aussi retiré plusieurs de ses systèmes — une mesure préventive, pas la conséquence d'un piratage confirmé.

Un point essentiel à retenir : aucune de ces organisations n'a signalé d'intrusion confirmée. Ce sont des coupures préventives, décidées pendant que le correctif n'existait pas encore ou venait tout juste de sortir — pas la preuve d'un piratage réussi. Côté exposition résiduelle, VulnCheck recense environ 2,6 millions de serveurs PHP accessibles depuis Internet, dont près de 700 000 (plus d'un sur quatre) tournent encore sur des versions PHP 3 à 7.3 — trop anciennes pour recevoir le moindre correctif officiel. Les grandes structures (ministères, banques, hébergeurs comme OVHcloud qui a corrigé automatiquement ses offres mutualisées) ont refermé la brèche en moins de 24h. Ce sont les petites structures — PME, associations, petites communes, souvent sans même savoir qu'elles utilisent PHP — qui restent les plus exposées dans la durée.

Comment on a vérifié notre propre exposition — et ce qu'on a trouvé

Avant de publier cet article, on a vérifié notre propre infrastructure PHP plutôt que de se contenter d'en parler en théorie. Premier réflexe : php -v en ligne de commande — réponse rassurante, PHP 8.4.27, déjà la version corrigée, mise à jour automatiquement le jour même de la sortie du correctif.

Mais la ligne de commande ne dit pas tout. En creusant la configuration nginx réelle, on a trouvé que le serveur fait tourner trois versions de PHP-FPM en parallèle (7.4, 8.2 et 8.4) pour différents services historiques. Un de nos panneaux d'administration de messagerie pointait vers l'instance PHP 8.2 — et cette instance précise était restée en 8.2.30, antérieure au correctif (8.2.35). Le paquet corrigé était déjà disponible dans le dépôt, juste pas encore installé.

Corrigé dans la foulée (mise à jour du paquet, redémarrage du service, vérification externe que le panneau répondait toujours normalement). La leçon est directement réutilisable : vérifier la version PHP « par défaut » d'un serveur ne suffit pas — un serveur qui a vécu plusieurs migrations ou héberge plusieurs outils peut très bien faire tourner une ancienne version oubliée à côté de la version à jour, invisible tant qu'on ne vérifie pas chaque socket PHP-FPM réellement utilisé par chaque site.

Que faire maintenant

Sources et méthodologie

Centre canadien pour la cybersécurité, avis AL26-026 (versions affectées/corrigées, classification CWE-416, recommandations) · BleepingComputer (déclaration du CTO de Cloudflare, alerte du NCSC britannique, détail de découverte Wiz/OpenAI) · Journal du Coin (rôle de l'ANSSI, chronologie précise, filtrage Cloudflare dès 3h02 UTC) · Clubic (organismes français affectés) · L'Appel (chiffres VulnCheck, situation des petites structures) · CERT-FR, alerte CERTFR-2026-ALE-014. Vérification de notre propre infrastructure effectuée en direct le 22 octobre 2026 (accès SSH, inspection de la configuration nginx/PHP-FPM réelle). Données au 22 octobre 2026 — la situation évolue rapidement, consultez l'avis officiel PHP et le CERT-FR pour les dernières mises à jour.

À lire aussi

Vérifiez votre propre exposition

Un scan gratuit, en quelques minutes, sans carte bancaire.