PHP2Shell (CVE-2026-109618, CVE-2026-109619) : PHP est patché, vérifiez maintenant votre checkout

En bref : PHP2Shell (CVE-2026-109618, CVE-2026-109619)

• Ce qui s'est passé : le 2026-10-21, PHP a publié 8.5.12, 8.4.27, 8.3.36 et 8.2.35 pour corriger deux failles notées CVSS 9.2 dans le moteur lui-même. Toutes deux peuvent donner à un attaquant sans compte une exécution de code sur n'importe quel serveur web PHP, sous WordPress, Magento ou Laravel.
• Les attaques ont commencé avant le correctif : les identifiants CVE ont fuité environ 23 heures avant la publication. Cloudflare a vu du trafic d'attaque avant le patch, et watchTowr a signalé des tentatives d'exploitation 19 minutes après.
• Patché n'est pas sain : mettre PHP à jour ferme la porte mais n'expulse personne. Sur les boutiques en ligne, un accès au serveur finit souvent en skimmer sur le checkout, et cela ne se voit que dans le navigateur.

Peu de temps ? Découvrez la surveillance des scripts côté client de cside. Vous pouvez ainsi surveiller les changements et le comportement des scripts dans le navigateur décrits ci-dessous.

Le 2026-10-21, le projet PHP a publié des correctifs d'urgence pour deux failles critiques du moteur PHP, référencées CVE-2026-109618 et CVE-2026-109619 et surnommées PHP2Shell. Comme les failles se trouvent dans le runtime et non dans un CMS ou un plugin, tous les sites WordPress, WooCommerce, Magento, Shopware et Drupal tournant sur une version de PHP non corrigée étaient exposés en même temps.

L'essentiel de la couverture jusqu'ici porte sur le serveur, et c'est normal : mettez PHP à jour et redémarrez chaque worker. Cet article traite de la partie qu'on oublie souvent. Quand un attaquant obtient une exécution de code sur une boutique en ligne, le serveur est rarement le butin. Le butin, ce sont quelques lignes de JavaScript ajoutées au checkout et servies à chaque acheteur jusqu'à ce que quelqu'un regarde ce que le navigateur exécute réellement.

Ce qui s'est passé : un vieux bug et une divulgation qui a fuité

La cause profonde n'était pas nouvelle. Selon la PHP Foundation, un développeur du cœur a repéré les premiers signes du problème de manque de mémoire à l'origine de CVE-2026-109618 lors de l'audit externe de PHP en 2024. Personne n'a alors trouvé de véritable chemin vers l'exécution de code, chaque correctif envisagé avait un coût en compatibilité ou en déni de service, et le travail s'est enlisé. La Fondation qualifie ce retard d'échec structurel de son propre processus.

Tout a changé en août 2026, quand les audits de Calif, OpenAI et Wiz ont transformé ce vieux bug en exploits fonctionnels. La publication coordonnée était prévue pour le 2026-10-22. Elle n'a pas tenu.

L'écart qui compte pour les défenseurs, ce sont ces quelque 23 heures entre la fuite et la publication. Quiconque faisait tourner PHP a passé cette fenêtre exposé à un bug dont les attaquants connaissaient déjà l'existence, sans aucun patch à installer.

Les deux vulnérabilités, en clair

Les deux bugs se trouvent dans du code que presque chaque requête PHP traverse : la gestion de la mémoire et la gestion des erreurs. Toutes deux sont notées 9.2 en CVSS v4.0 et peuvent donner à un attaquant non authentifié une exécution de code avec les privilèges du worker web.

Deux détails rendent la situation pire qu'un bug de CMS classique. D'abord, la faille agit sous votre application : une installation WordPress ou Magento entièrement à jour sur une version vulnérable de PHP reste exposée, et les plugins de sécurité ne voient jamais la requête. Ensuite, selon les chercheurs, un attaquant peut aussi lire la mémoire du worker PHP sans obtenir d'abord une exécution de code. Cette mémoire peut contenir les jetons de session, mots de passe, clés d'API et certificats d'autres utilisateurs.

Les descriptions officielles sont l'avis sur la corruption par manque de mémoire et l'avis sur l'état périmé.

Qui est concerné, et la faille est-elle exploitée ?

Toute installation PHP qui sert des requêtes web est concernée, quelle que soit l'interface serveur : PHP-FPM, Apache mod_php, php-cgi, FrankenPHP et LiteSpeed. Les chercheurs ont démontré une exécution de code sans authentification sur des installations standard de Magento 2.4.9, WordPress, Drupal, Joomla, Nextcloud, phpMyAdmin, Laravel et d'autres. Sansec met en avant les boutiques Magento, Shopware et WooCommerce.

Trois points piègent souvent. Les paquets des distributions ont reçu le correctif à l'avance et peuvent le porter sous un numéro de version qui semble ancien : cherchez le CVE dans le changelog du paquet plutôt que de vous fier à la version. Le dépôt de Remi, courant sur les serveurs basés sur RHEL, n'a pas publié de mise à jour le 2026-10-21. Et mettre à jour WordPress, Magento ou Laravel ne sert à rien ici : le correctif vient du paquet serveur, de votre hébergeur ou de votre image de conteneur.

Côté exploitation, tout est allé très vite. Cloudflare indique avoir vu du trafic d'attaque contre ses clients avant la sortie du correctif, et avoir observé des attaquants modifier leurs payloads pour contourner ses règles. watchTowr a signalé des tentatives d'exploitation actives contre les deux CVE à 14:19 UTC. Au moment de la publication, aucune source n'a confirmé publiquement la compromission réussie d'un serveur précis. Plusieurs organisations, dont des services publics néerlandais et BambooHR, se sont mises hors ligne par précaution plutôt que d'attendre.

Si vous n'avez pas pu patcher dans cette fenêtre, partez du principe que vous avez été sondé.

Pourquoi un bug serveur devient un problème de checkout

Sur une boutique en ligne, un shell est un moyen, pas une fin. Le scénario s'est répété après chaque vague d'exploitation massive visant les plateformes e-commerce en PHP, CosmicSting en 2024 étant la plus connue : les attaquants obtiennent une exécution de code, posent une porte dérobée, puis modifient ce que la boutique envoie aux navigateurs des acheteurs. L'argent se trouve dans les numéros de carte saisis au checkout, et ceux-ci n'existent que dans le navigateur.

La chaîne ressemble généralement à ceci :

1. Exploit. Une requête forgée atteint un worker PHP non corrigé.
2. Exécution de code. Le code de l'attaquant s'exécute en tant qu'utilisateur web, sans connexion.
3. Persistance. L'attaquant installe un webshell, une tâche cron ou un nouveau compte administrateur. Cela survit à la mise à jour de PHP, car le patch ferme la porte mais n'expulse pas ceux qui sont déjà entrés.
4. Injection. L'attaquant modifie ce que reçoit le navigateur : une balise <script> dans un template du checkout, un bundle JavaScript maison modifié ou, très souvent sous Magento et WordPress, un fragment stocké en base de données (réglages d'en-tête du thème, blocs CMS, options de widgets) là où les contrôles d'intégrité des fichiers ne regardent jamais.
5. Collecte. Le navigateur de chaque acheteur exécute le skimmer. Il lit les champs de carte, ou affiche un faux formulaire de paiement, et envoie les données vers un domaine qui ressemble à un hôte d'analytics ou de CDN.

Le marchand l'apprend généralement par un avis de point d'achat commun émis par un réseau de cartes, des semaines ou des mois après le vol de la première carte.

Chaque défense couvre une portion différente de cette chaîne :

Les skimmers modernes sont conçus pour rester invisibles aux outils qui contrôlent le côté serveur. Ils ne se déclenchent que sur la page de checkout, une seule fois par session, pour certains pays ou quand aucun outil de développement n'est ouvert, si bien qu'un crawler venant d'un datacenter reçoit une page propre. Nous avons vu l'astuce du déclenchement unique par session il y a quelques jours dans le détournement du checkout HulkApps. Un WAF voit l'exploit entrant, pas le script que votre page sert trois semaines plus tard. Le seul endroit où le skimmer se révèle de façon fiable, c'est la session de navigateur d'un vrai client.

Patché n'est pas synonyme de sain : ce qu'il faut vérifier maintenant

Si vos serveurs PHP étaient exposés à internet avec une version concernée à un moment quelconque après la fuite du 2026-10-20, parcourez les deux listes ci-dessous. La première porte sur le serveur. La seconde porte sur ce que reçoivent les navigateurs de vos clients, et c'est celle que la plupart des listes de réponse à incident oublient.

Sur le serveur

• Préservez d'abord les preuves. Faites une copie des logs PHP et du serveur web, de la configuration et de tout fichier suspect avant de modifier quoi que ce soit.
• Mettez à jour et redémarrez. Installez la version corrigée de PHP, puis redémarrez Apache, PHP-FPM et chaque worker de longue durée. Un paquet à jour avec d'anciens workers encore actifs reste vulnérable.
• Traquez la persistance. Cherchez des fichiers PHP nouveaux ou modifiés dans les racines web et les répertoires d'envoi, des tâches cron inattendues et des comptes administrateurs que personne n'a créés.
• Cherchez les empreintes de l'exploit dans les logs. Les chercheurs conseillent de repérer des requêtes multipart inhabituelles suivies d'erreurs de limite de mémoire ou de rafales d'erreurs HTTP 500, des cookies PHPSESSID de réponse anormalement volumineux et des redémarrages inexpliqués de workers PHP.
• Surveillez le comportement des processus. Des connexions sortantes depuis des workers PHP, ou un sh, curl ou wget lancé par php-fpm, sont des signaux forts.
• Renouvelez ce qui vivait en mémoire. Comme la mémoire des workers pouvait être lue sans exécution de code, renouvelez les clés d'API, les identifiants de base de données et les secrets de passerelle de paiement détenus par les processus PHP, et envisagez d'invalider les sessions actives.

Dans le navigateur

• Inventoriez chaque script de vos pages sensibles. D'abord le checkout, le paiement, la connexion et le compte. Incluez vos bundles maison, pas seulement les tags tiers.
• Comparez avec une référence antérieure au 2026-10-20. Tout nouveau script, tout hash de fichier modifié et tout nouveau domaine contacté par le checkout mérite une explication.
• Vérifiez les endroits où les skimmers se cachent hors de votre code. Sous Magento, les réglages « Scripts and Style Sheets » de l'en-tête HTML et « Miscellaneous HTML » du pied de page, les blocs CMS et les widgets. Sous WordPress, les plugins d'injection d'en-tête et de pied de page, les widgets et les options du thème stockés en base.
• Ne vous fiez pas à un seul crawl. Un skimmer qui se déclenche une fois par session ou ignore les adresses IP de datacenters passera un scan sans problème. Il vous faut des observations issues de vraies sessions, dans la durée.
• Surveillez les requêtes sortantes du checkout. Les données de carte doivent bien quitter la page d'une façon ou d'une autre : un fetch, une balise image, un WebSocket. Une nouvelle destination sur la page de paiement est le signal le plus clair que vous aurez.
• Examinez les rapports de violation CSP, si vous les collectez. Un rapport qui mentionne un domaine que vous n'avez jamais utilisé mérite d'être suivi, même si la page semble normale.

Rien de tout cela ne remplace le patch. Cela répond à la question que le patch ne peut pas trancher : quelque chose a-t-il changé pendant que la porte était ouverte ?

Ce que cela implique pour PCI DSS 6.4.3 et 11.6.1

PHP2Shell est un cas d'école pour les deux exigences de PCI DSS 4.0.1 devenues obligatoires le 2025-03-31.

• L'exigence 6.4.3 vous demande de gérer chaque script chargé et exécuté sur une page de paiement dans le navigateur du consommateur : confirmer que chacun est autorisé, garantir son intégrité et tenir un inventaire avec une justification écrite pour chacun. Un skimmer injecté après la compromission d'un serveur est, par définition, un script non autorisé.
• L'exigence 11.6.1 impose un mécanisme de détection des modifications et des altérations qui vous alerte en cas de changement non autorisé des scripts des pages de paiement et des en-têtes HTTP liés à la sécurité, tels que le navigateur les reçoit. C'est exactement le changement qu'opère un attaquant à l'étape 4 de la chaîne ci-dessus.

Deux questions pratiques pour votre prochaine évaluation. À quelle fréquence votre mécanisme 11.6.1 évalue-t-il réellement la page ? Si la réponse est hebdomadaire, un skimmer injecté le 2026-10-21 pourrait tourner plusieurs jours avant que quiconque ne s'en aperçoive. Et vos preuves couvrent-elles la période qui débute le 2026-10-20 ? Si vous pouvez montrer que l'inventaire des scripts de vos pages de paiement n'a pas changé, vous avez une réponse nette. Sinon, cette lacune mérite d'être comblée dès maintenant.

Les marchands en SAQ A qui intègrent l'iframe d'un prestataire de paiement ne sont pas tirés d'affaire pour autant. Depuis la révision du SAQ A de janvier 2025, l'éligibilité dépend de la confirmation que votre site n'est pas vulnérable aux attaques par script susceptibles d'affecter vos systèmes e-commerce. Une page parente compromise peut toujours remplacer ou masquer cet iframe.

La place de cside

Pour être clair sur le périmètre : cside ne patche pas PHP et n'arrête pas la requête d'exploit. C'est le rôle de votre mise à jour de PHP et de votre WAF. cside couvre la couche qui vient ensuite : ce que vos pages exécutent réellement dans les navigateurs de vos clients.

De vraies sessions, pas des crawls synthétiques. cside surveille les scripts dans les sessions réelles des acheteurs au lieu de s'appuyer sur un scan périodique, si bien qu'un skimmer qui se déclenche une fois par session ou se cache des datacenters s'exécute quand même sous nos yeux.

Les changements et le comportement, pas seulement les noms de fichiers. Un nouveau script sur le checkout, un bundle maison modifié ou un script qui commence à lire les champs de carte et à les envoyer vers un domaine que votre boutique n'a jamais utilisé déclenche une alerte, avec le contenu du script disponible pour inspection.

Arrêté dans la session. Avec Script Method, cside récupère chaque script tiers côté serveur pour le hacher, l'archiver et l'analyser, et les blocages sont appliqués à l'exécution dans le navigateur, aux côtés de CSP. Un script non autorisé, ou une capacité précise qu'il tente d'utiliser, est arrêté dans la session au lieu d'être signalé après coup.

Des preuves pour PCI. PCI Shield tient l'inventaire des scripts exigé par 6.4.3 et les alertes de modification de 11.6.1, avec des rapports hebdomadaires lisibles par votre évaluateur.

Les informations ci-dessus reflètent les sources publiques et les déclarations des éditeurs au 2026-10-21. Nous mettrons cet article à jour à mesure que les signalements d'exploitation évoluent.

Si cside surveillait déjà votre checkout le 2026-10-20, consultez les données enregistrées depuis cette date ou réservez une démo pour les examiner avec notre équipe. Commencez gratuitement pour lancer la surveillance à partir du déploiement. Un nouveau déploiement ne permet pas de reconstituer les sessions antérieures du navigateur.

Sources

• Avis de sécurité PHP : RCE par corruption en cas de manque de mémoire (GHSA-w8hw-w9fx-j79w)
• Avis de sécurité PHP : RCE par état périmé (GHSA-6wmf-4rv5-p3rp)
• Annonce PHP, 2026-10-21
• The PHP Foundation : Today's PHP security release, and how we're strengthening PHP security
• Cloudflare : Cloudflare deploys protections against php2shell vulnerability
• watchTowr : PHP Remote Code Execution (PHP2Shell)
• Rapid7 : CVE-2026-109618 and CVE-2026-109619
• The Hacker News : PHP issues emergency patches for two critical PHP2Shell RCE flaws
• Sansec : PHP2Shell critical PHP RCE
• CERT-EU Security Advisory 2026-018