PHP2Shell, RCE PHP CVE-2026-109618 et CVE-2026-109619

Le 21 octobre 2026 à 14 h UTC, PHP a publié PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 pour corriger deux vulnérabilités critiques dans PHP lui-même, CVE-2026-109618 et CVE-2026-109619, surnommées PHP2Shell. Toutes deux sont notées 9,2 en CVSS 4.0 et peuvent permettre une exécution de code à distance sans authentification. Les détails ont fuité la veille du correctif, et internet a passé la matinée à attendre : DigiD, le parlement néerlandais, des rédactions et Root-Me ont mis leurs sites hors ligne, et le CERT-EU a demandé aux organisations de recenser leurs applications PHP.

La première question de la plupart des équipes est simple : est-ce que j'utilise PHP, et où ? Si vous gérez plus d'une poignée de sites, la réponse est souvent « quelque part, sans doute ». Le moyen le plus rapide de vérifier depuis l'extérieur est notre Technology Checker gratuit : collez une URL et il liste les technologies que la page laisse voir, dont PHP et les applications PHP construites dessus (WordPress, Drupal, Magento, Laravel, MediaWiki et bien d'autres), avec leurs versions, leur statut de fin de vie et les CVE connues.

Un résultat illustratif sur des données d'exemple : PHP 8.1.27 est signalé en fin de vie, avec une CVE critique connue.

La réponse courte, selon ce que vous trouvez :

• PHP 8.2 à 8.5 : mettez à jour dès maintenant vers 8.2.35, 8.3.36, 8.4.27 ou 8.5.12.
• PHP 8.1 ou antérieur : aucune version officielle. Appliquez le paquet rétroporté de votre fournisseur ou le backport source de PHP, ou isolez le site jusqu'à ce qu'il tourne sur une version corrigée.
• Hébergement managé (WP Engine, Kinsta, WordPress.com et équivalents) : c'est l'hébergeur qui gère et met à jour PHP, pas vous. Consultez sa page de statut pour confirmer que le correctif est appliqué.

Cet article résume ce qu'est PHP2Shell, le déroulé de la journée, comment savoir si vos sites tournent sous PHP et quoi faire maintenant. Il reste au niveau du quoi et du pourquoi : aucun détail d'exploitation.

Qu'est-ce que PHP2Shell, CVE-2026-109618 et CVE-2026-109619Copy Anchor Link

Ce sont deux vulnérabilités de l'interpréteur PHP, pas d'un framework ni d'un plugin. Selon l'avis de sécurité de PHP, toutes deux peuvent permettre une exécution de code à distance (RCE, remote code execution) sans authentification : un attaquant capable d'envoyer une requête à un serveur PHP vulnérable peut parvenir à y exécuter du code avec les privilèges du worker web, sans compte.

• CVE-2026-109618, "RCE via OOM corruption" (GHSA-w8hw-w9fx-j79w). Une erreur de mémoire insuffisante (out of memory) peut arrêter PHP alors que les données de la requête ne sont que partiellement initialisées, et le nettoyage qui suit travaille alors sur des données invalides.
• CVE-2026-109619, "RCE via stale global state" (GHSA-6wmf-4rv5-p3rp). Un état interne issu d'une requête peut survivre à sa mémoire, et la requête suivante traitée par le même worker peut l'utiliser.

Comme le bug se trouve dans PHP et non dans le code applicatif, aucune modification de code dans WordPress, Drupal ou Laravel ne le corrige. PHP liste quelques changements de configuration qui réduisent l'exposition à certains chemins d'attaque, et précise qu'ils ne rendent pas une installation sûre : mettre à jour PHP est le seul correctif complet.

Le déroulé de la journéeCopy Anchor Link

La publication était prévue dans le cadre d'une divulgation coordonnée, puis le calendrier a déraillé.

• 20 octobre. Les deux identifiants CVE ont circulé sur les réseaux sociaux et Hacker News avant la date d'embargo prévue (Tenable). L'équipe sécurité de PHP a publié une annonce préalable d'une version pour le lendemain, en précisant qu'elle pourrait sortir plus tôt si des détails devenaient publics ou si une exploitation apparaissait. Le CERT-EU a publié le Security Advisory 2026-018 le soir même.
• 21 octobre, matin. watchTowr a confirmé que les failles sont des vulnérabilités d'exécution de code à distance dans PHP et a indiqué penser avoir reproduit CVE-2026-109618. Un code d'exploitation présenté comme une preuve de concept a circulé, sans que sa validité soit confirmée. Les informations sur l'exploitation divergent : le CTO de Cloudflare a déclaré que l'entreprise observait des premières attaques et Cloudflare a déployé des règles WAF pour les vecteurs connus, tandis que watchTowr, Huntress et le NCSC néerlandais ne signalaient aucune exploitation confirmée dans la nature (Tenable, SecurityWeek, NOS). Sansec s'attend à des attaques massives dans les 15 minutes suivant la publication.
• 21 octobre, 14 h UTC. PHP a publié 8.5.12, 8.4.27, 8.3.36 et 8.2.35 avec un avis de sécurité. Il indique que les distributions Linux et les fournisseurs de support long terme ont reçu les correctifs en avance, et qu'un exploit a été démontré contre Apache avec mod_php.

C'est l'ampleur qui inquiétait les défenseurs : les estimations publiques du nombre d'hôtes PHP exposés sur internet vont de 1,3 million (Silas Cutler) à 1,9 million (une recherche Shodan de Henk Poley), selon la compilation de Tenable.

Black-out, les sites mis hors ligne avant le correctifCopy Anchor Link

Beaucoup d'organisations n'ont pas attendu 14 h UTC. Le CERT-EU a conseillé à celles qui ne pouvaient pas corriger tout de suite d'envisager d'isoler leurs applications exposées sur internet, et plusieurs gouvernements, groupes de médias et plateformes ont coupé leurs sites par précaution. Être hors ligne ne veut pas dire qu'un site a été piraté : cela ferme la porte jusqu'à l'installation du correctif.

Pays-Bas. Selon la NOS, ces sites ont été mis hors ligne par précaution :

• Le National Cyber Security Centre (NCSC), l'agence nationale de cybersécurité elle-même
• MijnOverheid.nl et le site de DigiD, le portail citoyen et le service d'authentification de l'administration
• La Tweede Kamer, la chambre basse du parlement
• L'Autoriteit Persoonsgegevens, l'autorité de protection des données
• RTL Nieuws, son site et son application
• Tweakers, le site d'actualité tech
• Notubiz, la plateforme de réunions utilisée par une centaine de communes
• L'ANP, l'agence de presse nationale, qui a mis ses systèmes hors ligne

Belgique. DPG Media a suspendu plusieurs de ses sites belges et néerlandais. Roularta a coupé les sites de ses magazines, dont Le Vif et Trends Tendances, et la plateforme scolaire Smartschool était inaccessible. La RTBF cite aussi le comparateur de prix de l'énergie du régulateur CREG et des sites officiels de la Région flamande.

Finlande. Une agence gouvernementale finlandaise a mis des sites hors ligne, selon des informations de Reuters.

France. Root-Me, la plateforme d'entraînement au hacking, a remplacé tout son site par un avis de maintenance. Elle y explique que la plateforme est hors ligne par précaution, après la divulgation de vulnérabilités critiques dans PHP, le temps que l'équipe évalue l'impact sur son infrastructure et applique les correctifs.

La page de connexion de YesWeHack, la plateforme de bug bounty, affichait une page « Under maintenance » le même après-midi. YesWeHack n'avait pas donné de raison au moment de notre vérification : le lien avec PHP est notre hypothèse, pas la leur.

La liste s'est allongée tout au long de la journée. Le liveblog de la NOS ajoute l'application de l'aéroport de Schiphol, la fédération néerlandaise de football KNVB et les clubs FC Twente, Fortuna Sittard et Willem II, l'Unie van Waterschappen (l'union des offices de l'eau), la province de Groningue, six hôpitaux néerlandais dont Haaglanden MC et St. Antonius Ziekenhuis, et en Belgique l'hôpital AZ Monica et tous les sites du gouvernement flamand. Tous ont d'abord dû répondre à la même question : où faisons-nous tourner PHP ?

Quelles versions de PHP sont affectées et corrigéesCopy Anchor Link

Les deux avis listent les mêmes plages : toute version de PHP inférieure aux versions de ce tableau est affectée, et seules les branches supportées reçoivent une version officielle.

Les sources et les builds Windows sont sur la page de téléchargement de PHP. La plupart des serveurs obtiennent PHP via une distribution ou une image de conteneur : mettez à jour avec votre gestionnaire de paquets ou reconstruisez sur une image de base corrigée. PHP prévient que le dépôt rpms.remirepo.net, maintenu par des bénévoles, n'aurait pas les mises à jour le jour de la publication, et conseille de passer aux paquets de la distribution ou de compiler depuis les sources.

PHP 8.2 est corrigé, mais son support sécurité s'arrête le 31 décembre 2026. Si vous corrigez un serveur 8.2 aujourd'hui, planifiez dès maintenant son passage à 8.4 ou 8.5.

PHP 8.1 et antérieures, vulnérables et sans version officielleCopy Anchor Link

Les avis marquent comme affectée toute version inférieure aux versions corrigées, et Sansec indique que les bugs remontent à PHP 5.4. PHP 8.1 a atteint sa fin de vie le 31 décembre 2025, il n'existe donc pas de version de PHP 8.1 avec le correctif.

Vu la gravité, l'équipe sécurité de PHP a fait une exception et publié des backports source minimaux pour PHP 7.4, PHP 8.0 et PHP 8.1, destinés à ceux qui compilent PHP depuis les sources ou n'ont pas de fournisseur de support long terme. Certaines distributions et certains fournisseurs LTS livrent leurs propres paquets rétroportés, renseignez-vous auprès du vôtre. Pour PHP 7.3 et antérieur, rien n'a été publié : considérez ces serveurs comme exposés jusqu'à leur mise à niveau.

Est-ce que j'utilise PHP ? Vérifier si un site utilise PHPCopy Anchor Link

Vous faites peut-être tourner PHP sans l'avoir jamais choisi. La plupart du PHP sur le web arrive par une application : un CMS, une boutique, un forum, un wiki, un outil d'administration. Si un site repose sur l'une d'elles, le serveur exécute PHP.

Pour vérifier un site depuis l'extérieur, collez son URL dans le Technology Checker. Il signale PHP directement quand le serveur le révèle, et il signale les applications qui impliquent PHP, comme WordPress ou Magento, même quand PHP lui-même reste caché. Quand une version est lisible, il indique si elle est en fin de vie et quelles CVE connues l'affectent.

Deux indices trahissent PHP dans une réponse : un header X-Powered-By: PHP/8.1.27 et un cookie PHPSESSID. Beaucoup de sites masquent les deux, c'est pourquoi le checker cherche aussi les applications. Ce header est en soi une fuite d'information, et une bannière de version comme PHP/8.1 indique à un attaquant qu'aucun correctif n'arrivera. Pour la méthode générale qui permet de lire la stack d'un site, lisez Quelle technologie utilise ce site, et est-elle encore à jour.

Depuis l'intérieur, sur un serveur que vous contrôlez, vérifiez le PHP qui sert le site, pas seulement celui de la ligne de commande, car ils peuvent différer :

php -v          # PHP en ligne de commande
php-fpm8.3 -v   # PHP-FPM, le nom dépend de votre version et de votre distribution
dpkg -l 'php*'  # paquets Debian et Ubuntu
rpm -qa 'php*'  # paquets Red Hat, Rocky, Alma

Les paquets de distribution qui embarquent un correctif rétroporté conservent l'ancienne chaîne de version upstream : lisez le changelog du paquet plutôt que le seul numéro de version. Pour une application en production, le panneau de contrôle de l'hébergeur affiche la version de PHP utilisée par le site.

WordPress, Drupal ou Magento sont-ils affectés ? Les applications qui tournent sous PHPCopy Anchor Link

Oui, quand le PHP sous-jacent est affecté. Chacune de ces applications tourne sous PHP : si le checker en trouve une sur votre site, le site exécute PHP, même quand la version de PHP elle-même est masquée. Voici les plus connues, par catégorie.

CMS et créateurs de sites. WordPress, Drupal, Joomla, TYPO3, Craft CMS, Concrete CMS, Contao, MODX, ProcessWire, Grav, Kirby, Statamic, Silverstripe, Backdrop CMS, October CMS, Winter CMS, Pimcore, Ibexa DXP, ExpressionEngine, SPIP, 1C-Bitrix.

E-commerce. Magento, PrestaShop, Shopware, OpenCart, osCommerce, CS-Cart, X-Cart, OXID eShop, Sylius, Thelia, Drupal Commerce, VirtueMart, Craft Commerce. WooCommerce tourne sur WordPress, donc sous PHP aussi.

Frameworks. Laravel, Symfony, CodeIgniter, CakePHP, Yii, Nette, ThinkPHP, Livewire (Laravel), Neos Flow.

Forums, wikis et blogs. MediaWiki, DokuWiki, phpBB, MyBB, vBulletin, XenForo, Invision Community, Flarum, Vanilla Forums, Discuz!, Dotclear.

Outils métier et d'administration. Moodle, Nextcloud, ownCloud, phpMyAdmin, Adminer, Roundcube, osTicket, GLPI, Zabbix, BookStack.

Hébergeurs WordPress managés. WP Engine, Kinsta, WordPress.com et WordPress VIP. Un site sur ces plateformes exécute PHP, mais c'est l'hébergeur qui gère le runtime PHP : consultez sa page de statut plutôt que votre serveur. Pour les failles du cœur de WordPress cette année, voir Failles WordPress en 2026.

Suis-je vulnérable à la RCE PHP ?Copy Anchor Link

Si un site public tourne sous PHP, il est concerné tant que vous ne connaissez pas sa version de PHP et ne l'avez pas corrigé. Les vérifications, dans l'ordre :

1. Recensez tous les sites qui tournent sous PHP. Partez de votre liste de domaines et sous-domaines, passez chacun dans le Technology Checker et cherchez PHP ou l'une des technologies de la liste ci-dessus. N'oubliez pas les sites de préproduction, les vieux microsites marketing, les panneaux d'administration et le blog WordPress dont plus personne ne s'occupe.
2. Relevez la version de PHP. Sur le serveur avec les commandes ci-dessus, dans le panneau de l'hébergeur, ou dans le résultat du checker quand le serveur l'expose.
3. Comparez-la aux versions corrigées du tableau ci-dessus. Pour un paquet de distribution, consultez plutôt l'avis du fournisseur.

Une version hors de la plage affectée écarte l'avis. Une version dans la plage signifie que le site est exposé jusqu'à ce qu'il soit corrigé, quelle que soit l'application au-dessus.

Que faire maintenantCopy Anchor Link

Nos recommandations, de la plus urgente à la moins urgente :

1. Mettez hors ligne tout site public que vous ne pouvez pas corriger aujourd'hui. Cela concerne PHP 8.1 et antérieur, sauf si vous appliquez le paquet rétroporté de votre fournisseur ou compilez depuis le backport source de PHP, ainsi que tout serveur supporté que vous ne pouvez pas mettre à jour tout de suite. Placez le site derrière une authentification, limitez-le aux IP internes ou coupez-le jusqu'à ce qu'il tourne sur une version corrigée, et planifiez la migration des serveurs en fin de vie vers une branche supportée. Le CERT-EU recommande d'isoler des réseaux publics les applications exposées sur internet jusqu'à ce qu'un correctif puisse être appliqué.
2. Corrigez maintenant. Pour PHP 8.2 à 8.5, mettez à jour vers 8.2.35, 8.3.36, 8.4.27 ou 8.5.12, via les paquets de votre distribution, votre image de base de conteneur ou votre hébergeur. Les images de conteneur et les runners de CI comptent aussi : reconstruisez-les, ne vous contentez pas de corriger les hôtes.
3. Placez un WAF bien configuré devant vos applications PHP. Cloudflare a déployé des règles pour les vecteurs d'attaque connus, y compris sur son offre gratuite, et les présente comme une solution d'attente (Tenable). Un WAF fait gagner du temps et bloque les payloads connus, mais il ne corrige pas PHP et ne protège que le trafic qui passe réellement par lui. Vérifiez que vos serveurs d'origine ne sont pas joignables directement.
4. Surveillez vos serveurs à la recherche de comportements inhabituels. Guettez les fichiers .php nouveaux ou modifiés dans les racines web, les processus inattendus lancés par l'utilisateur de PHP ou du serveur web, les connexions sortantes depuis les serveurs web, les nouveaux comptes administrateur dans vos applications et les pics d'erreurs. Aikido conseille de rechercher une compromission après la mise à jour, en remontant au moins jusqu'à juin 2026 : web shells, fichiers inattendus, nouveaux administrateurs, connexions sortantes inhabituelles et fichiers PHP modifiés.

Tenir un inventaire avant la prochaine failleCopy Anchor Link

La question de la semaine, « faisons-nous tourner PHP, et en quelle version ? », revient à chaque CVE critique. C'était WordPress et Next.js plus tôt cette année, c'est PHP aujourd'hui. Une vérification ponctuelle répond pour une URL, un jour donné.

Pour les logiciels côté serveur comme PHP, le Technology Checker gratuit donne une vue rapide depuis l'extérieur. Pour le code qui s'exécute dans le navigateur de vos visiteurs, CentralCSP tient l'inventaire à jour : il liste les scripts chargés par chaque page, identifie la bibliothèque et la version derrière chacun, et vous alerte quand une nouvelle CVE touche une version que vous servez. L'inventaire est décrit dans Technologies, et la page de la fonctionnalité supply chain en fait le tour. Commencez gratuitement avec CentralCSP pour voir vos propres sites.

FAQCopy Anchor Link

Qu'est-ce que PHP2Shell ?Copy Anchor Link

PHP2Shell est le surnom donné par les chercheurs et la presse à CVE-2026-109618 et CVE-2026-109619, les deux failles critiques d'exécution de code à distance dans PHP annoncées le 20 octobre 2026. Ce n'est pas un nom officiel de PHP.

PHP 8.1 est-il affecté ?Copy Anchor Link

Oui, et il n'existe pas de version officielle 8.1 avec le correctif : voir PHP 8.1 et antérieures, vulnérables et sans version officielle.

PHP 8.2 est-il corrigé ?Copy Anchor Link

Oui, dans PHP 8.2.35. Son support sécurité s'arrête le 31 décembre 2026, planifiez donc le passage à 8.4 ou 8.5.

Désactiver session.upload_progress protège-t-il contre PHP2Shell ?Copy Anchor Link

En partie seulement. PHP cite session.upload_progress.enabled=0 parmi les mesures qui réduisent l'exposition si vous ne pouvez pas mettre à jour tout de suite : cela bloque les chemins confirmés pour CVE-2026-109619 mais pas d'autres variantes, et ne fait rien contre CVE-2026-109618. PHP précise que seule une mise à jour est une solution complète.

PHP2Shell est-il exploité dans la nature ?Copy Anchor Link

Le 21 octobre, les informations divergeaient : Cloudflare disait observer des premières attaques, tandis que watchTowr, Huntress et le NCSC néerlandais ne signalaient aucune exploitation confirmée. L'avis de PHP mentionne un exploit démontré contre Apache avec mod_php. Considérez tout serveur PHP exposé sur internet et non corrigé comme une cible.

WordPress est-il affecté par PHP2Shell ?Copy Anchor Link

Un site WordPress est exposé quand la version de PHP de son serveur est affectée. Mettre à jour WordPress n'y change rien, car les failles sont dans PHP. Sur un hébergement WordPress managé, c'est l'hébergeur qui gère PHP : consultez sa page de statut.

Mettre à jour Drupal, Magento ou Laravel corrige-t-il la faille ?Copy Anchor Link

Non. Les failles sont dans PHP lui-même : mettre à jour l'application ne change pas l'interpréteur PHP qui l'exécute. Vous devez mettre à jour PHP.

Comment savoir si un site utilise PHP ?Copy Anchor Link

Collez son URL dans le Technology Checker gratuit. Il affiche PHP quand le serveur le révèle, et sinon les applications PHP (WordPress, Magento, MediaWiki et d'autres) qui impliquent PHP. Sur votre propre serveur, lancez php -v.

Mon site est-il vulnérable s'il est derrière Cloudflare ?Copy Anchor Link

Il est moins exposé aux vecteurs d'attaque connus, puisque Cloudflare a déployé des règles WAF pour eux, mais il reste vulnérable. Les règles WAF ne couvrent que les payloads connus, et un attaquant qui atteint directement le serveur d'origine les contourne. Corrigez PHP quoi qu'il en soit.

Articles liésCopy Anchor Link

• Quelle technologie utilise ce site, et est-elle encore à jour
• Failles WordPress en 2026, CVE-2026-87902, wp2shell et la version sûre par branche
• Failles Next.js en 2026, la RCE AVIF et la version à installer
• Comment détecter les bibliothèques JavaScript vulnérables sur un site en production
• À quoi sert un détecteur de technologies, des notes de sécurité aux scans PCI

SourcesCopy Anchor Link

• PHP, archive des actualités 2026, avis de sécurité et annonce préalable
• GitHub, GHSA-w8hw-w9fx-j79w, RCE via OOM corruption, CVE-2026-109618
• GitHub, GHSA-6wmf-4rv5-p3rp, RCE via stale global state, CVE-2026-109619
• PHP, Supported versions
• CERT-EU, Security Advisory 2026-018, Critical Vulnerabilities in PHP
• Tenable, FAQ php2shell
• SecurityWeek, PHP2Shell, une exploitation massive se profile
• Sansec, Critical PHP RCE, CVE-2026-109618 et CVE-2026-109619
• NOS, des sites comme MijnOverheid et DigiD hors ligne à cause de la faille
• Liveblog de la NOS, sites hors ligne après la faille logicielle
• La Libre, DPG Media suspend plusieurs de ses sites internet
• DH, des plateformes belges déjà mises hors ligne
• Global Banking and Finance Review (Reuters), une agence cyber prévient que des sites pourraient être coupés
• Aikido, Critical vulnerabilities in PHP
• PHP, Unsupported branches
• RTBF, DPG Media met plusieurs sites hors ligne par précaution