Failles RCE critiques dans PHP : correctifs CVE-2026-109618

Le 21 octobre 2026, l’équipe de développement de PHP a publié les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35 afin de corriger deux vulnérabilités critiques regroupées sous le nom « php2shell » : CVE-2026-109618 et CVE-2026-109619. Ces deux failles permettent une exécution de code à distance (RCE) sans authentification sur les serveurs web exposés. Le message des mainteneurs de PHP est sans appel : la mise à jour de l’environnement PHP constitue le seul correctif complet.

PHP propulsant près de 70 % des sites web utilisant un langage serveur connu, cette annonce a immédiatement donné lieu à des bulletins d’alerte de la part des centres gouvernementaux de réponse aux incidents, notamment CERT-EU (avis de sécurité 2026-018) et le Centre national de cybersécurité des Pays-Bas (NCSC-NL). En Europe et à l’international, de nombreux portails publics et services d’entreprise ont temporairement basculé leurs sites en maintenance le temps d’appliquer les correctifs.

Fuite prématurée des CVE, chronologie de découverte et cause racine

D’après le retour d’expérience technique de The PHP Foundation, le problème de gestion de dépassement de mémoire (OOM) à l’origine de la CVE-2026-109618 avait été remarqué une première fois lors d’un audit externe réalisé en 2024 par l’OSTIF et Quarkslab avec le financement de la Sovereign Tech Agency. L’exploitation paraissait alors purement théorique et les correctifs envisagés risquaient de rompre la compatibilité avec des extensions tierces. La situation a basculé après l’intégration de PHP au programme Patch the Planet fin juillet 2026 : le 11 août 2026, le chercheur Ryan Austin de Calif (dirigée par Thai Duong) a démontré un scénario d’exécution de code à distance inconditionnel et l’a transmis à Volker Dusch chez The PHP Foundation. OpenAI a signalé indépendamment la même cause racine le jour même, suivie par des vecteurs complémentaires transmis par Wiz le 24 août et OpenAI le 18 septembre.

Le calendrier de divulgation coordonnée a toutefois été compromis environ 24 heures avant la sortie officielle. Le 20 octobre vers 15 h 00 UTC, les deux identifiants CVE et leurs intitulés ont fuité dans des flux publics avant la mise à disposition des paquets corrigés. Cette fuite anticipée a conduit le CERT-EU et le NCSC-NL à publier des recommandations d’urgence. Un point essentiel doit être souligné : les coupures de sites observées les 20 et 21 octobre résultaient de mises hors ligne préventives décidées par les administrateurs dans l’attente du correctif, et non de pannes massives causées par des attaques.

Sur le plan technique, la CVE-2026-109618 (GHSA-w8hw-w9fx-j79w, NVD) découle d’un nettoyage incomplet lorsqu’une erreur de manque de mémoire (OOM) survient pendant l’analyse des données d’une requête entrante, laissant des structures partiellement initialisées propices à une corruption mémoire et à une RCE (CWE-119, CWE-787). La CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp, NVD) est une vulnérabilité use-after-free (CWE-416) où certains états internes liés au suivi de téléversement de session ou aux traces d’erreur persistent après la libération de la mémoire de la requête. PHP attribue aux deux failles un score CVSS v4.0 de 9,2 (Critique), tandis que le NVD les évalue à 9,8 (Critique) en CVSS v3.1.

Environnements exposés et versions corrigées

L’avis officiel de PHP précise que toute installation PHP traitant des requêtes web est concernée, y compris PHP-FPM, Apache mod_php, php.exe, CGI/FastCGI ainsi que les environnements à travailleurs persistants tels que FrankenPHP, RoadRunner et Swoole. Le risque maximal concerne les déploiements Apache mod_php, où l’ensemble des threads partagent le même espace mémoire.

Les administrateurs utilisant PHP-FPM ne doivent pas pour autant s’estimer à l’abri. Si FPM offre une meilleure isolation des processus face à la CVE-2026-109618, la fonctionnalité de suivi de téléversement de session impliquée dans la CVE-2026-109619 est activée par défaut et peut être exploitée sur une installation FPM standard sans nécessiter de script applicatif particulier. Les chercheurs ont validé l’exécution de code à distance complète aussi bien sur mod_php que sur FPM. De plus, l’analyse de Tenable rappelle que le processus maître de FPM relance automatiquement les workers qui plantent : un service toujours en ligne peut donc avoir subi des tentatives d’exploitation. Tenable met également en garde contre de faux dépôts GitHub prétendant fournir un PoC « php2shell » mais diffusant en réalité des malwares voleurs d’informations (infostealers).

Les versions officielles corrigées pour les branches maintenues sont PHP 8.5.12, PHP 8.4.27, PHP 8.3.36 et PHP 8.2.35. Au vu de la criticité des failles, l’équipe de sécurité PHP a également publié des branches de correctifs minimaux en code source pour les versions en fin de vie PHP 7.4, 8.0 et 8.1. Sur les distributions Linux comme Debian et Ubuntu, les correctifs étant rétroportés (backport) dans les paquets de la distribution, il faut vérifier la version exacte du paquet installé auprès des bulletins de la distribution plutôt que de se fier uniquement à la commande php -v (Debian Security Tracker, Ubuntu Security).

Liste de contrôle et mesures d’atténuation temporaires

1. Inventaire des environnements PHP : Recensez toutes les instances PHP traitant des requêtes HTTP externes ou internes — pools FPM, Apache mod_php, images de conteneurs et workers FrankenPHP, RoadRunner ou Swoole — et supprimez toute page publique exposant phpinfo().

2. Mise à jour et redémarrage des processus : Passez à PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 (ou au paquet corrigé de votre distribution Linux) et redémarrez le serveur web ainsi que tous les processus workers PHP-FPM afin qu’aucun binaire vulnérable ne reste chargé en mémoire.

3. Mesures temporaires (uniquement d’ici l’application du correctif) : PHP insiste sur le fait que les réglages de configuration ne font que réduire certains chemins d’attaque et ne sécurisent pas une installation non corrigée. En attendant la mise à jour, la surface d’exposition à la CVE-2026-109618 peut être réduite en fixant memory_limit=-1 via php_admin_value (pour empêcher toute modification par ini_set() ou .user.ini) et en abaissant post_max_size et upload_max_filesize, tout en veillant à ne définir aucune limite système RLIMIT_AS ou RLIMIT_DATA qui déclencherait l’erreur mémoire plus tôt. Pour la CVE-2026-109619, appliquez session.upload_progress.enabled=0 et, sous PHP 8.5, fatal_error_backtraces=0, en gardant à l’esprit que l’opérateur @ génère tout de même des structures d’erreur internes même lorsque error_reporting et display_errors sont désactivés.

4. Examen des journaux de plantage : Recherchez dans les journaux FPM et serveur web les arrêts répétés de processus workers, les requêtes multipart anormalement volumineuses et toute activité inhabituelle liée au téléversement de session. Des journaux d’accès HTTP apparemment propres ne suffisent pas à exclure une compromission, car les requêtes interrompues par un crash mémoire n’y figurent pas systématiquement.

Point de vue de LeakData : Protéger vos identifiants et vos données après une faille serveur

Tout d’abord, nous tenons à rassurer nos utilisateurs et partenaires : la plateforme et les services de LeakData ne sont pas affectés par les failles CVE-2026-109618 et CVE-2026-109619. Dès la publication des avis internationaux, notre équipe de sécurité a vérifié l’ensemble de nos contrôles périmétriques et confirmé la protection complète de nos services. Toutefois, pour les organisations qui exploitent des serveurs web, le risque majeur d’une faille RCE critique comme php2shell se manifeste souvent après coup, sous la forme de fuites d’identifiants et de bases de données.

Lorsqu’un attaquant parvient à exécuter du code sur un serveur web non corrigé, son premier objectif consiste généralement à extraire les fichiers de configuration, les identifiants de base de données, les clés d’API, les jetons de session actifs et les tables d’utilisateurs. Même une fois la mise à jour PHP appliquée, les identifiants professionnels et les données copiés pendant la fenêtre d’exposition refont souvent surface quelques jours ou semaines plus tard dans des journaux d’infostealers, sur des canaux Telegram ou sur des forums spécialisés.

LeakData accompagne aussi bien les particuliers que les équipes de sécurité dans la détection rapide de ces fuites secondaires. Après avoir mis à jour vos serveurs, vous pouvez vérifier sur LeakData si les adresses e-mail de votre domaine, vos comptes d’administration ou vos mots de passe figurent dans des bases de données compromises récentes, et activer la surveillance continue de vos domaines afin d’être alerté immédiatement et de procéder sans délai à la rotation de vos mots de passe et clés d’accès. Pour en savoir plus, consultez notre page Comment ça marche.