php2shell : deux failles RCE critiques dans le cœur de PHP

Pourquoi php2shell concerne à peu près tout le monde

Le 20 octobre 2026 en fin de journée, l'équipe de sécurité de PHP a publié une annonce d'une sobriété inhabituelle : une version de sécurité sortira le mercredi 21 octobre à 14 h 00 UTC (16 h à Paris) pour corriger deux vulnérabilités critiques, notées 9,2 en CVSS v4.0. Pas d'identifiant, pas de composant, pas de version concernée. Juste une consigne : préparez-vous à mettre à jour dès que c'est disponible. Et une phrase qui en dit long : l'équipe se réserve le droit de publier plus tôt « si des détails de l'une ou l'autre vulnérabilité deviennent publics ».

Ils l'étaient déjà, en partie. Quelques heures auparavant, un message sur Hacker News avait annoncé deux RCE dans PHP, avec les deux numéros de CVE réservés, CVE-2026-109618 et CVE-2026-109619, une date de divulgation et un score, le tout appuyé sur une « source fiable » et aucune preuve. La société de recherche watchTowr a confirmé dans la foulée que ces failles étaient réelles et sous embargo. Un chercheur leur a donné un nom, php2shell, et une capture d'écran d'un outil d'exploitation a circulé. L'embargo, prévu jusqu'au jeudi, a sauté. PHP a avancé la publication d'un jour.

Pourquoi c'est un sujet pour votre organisation, même si vous pensez « ne pas faire de PHP » : d'après W3Techs, PHP fait tourner un peu plus de deux sites web sur trois dont le langage serveur est connu. WordPress, Drupal, Magento, PrestaShop, Nextcloud, Laravel, Symfony, les panneaux d'hébergement, une bonne partie des intranets et des extranets, et une quantité d'appliances qui embarquent un PHP dont personne ne connaît la version. Une faille dans l'interpréteur lui-même, exploitable avant que la moindre ligne de code applicatif ne s'exécute, c'est une faille dans tout cela à la fois.

Cet article fait le point sur l'état des connaissances au 21 octobre 2026 au matin, avant la publication du correctif. Il sépare ce qui est établi de ce qui n'est qu'une hypothèse, délimite le périmètre, et détaille ce qu'on peut faire dans les heures qui viennent et dans les jours qui suivent. Nous le mettrons à jour quand l'avis officiel sera sorti.

Les faits, tels que les sources primaires les posent

Deux lectures de ce tableau. D'abord, tout ce qui est officiel tient en quatre lignes : deux failles, un score, une date, des branches maintenues. Tout le reste vient de chercheurs, d'éditeurs de sécurité et de la fuite elle-même. Ce n'est pas rien, plusieurs équipes indépendantes convergent, mais il faut le lire pour ce que c'est. Ensuite, le score : la fuite parlait de 10,0, PHP dit 9,2. Les deux ne mesurent pas forcément la même chose (le 10 vient d'une rumeur, le 9,2 d'un vecteur CVSS v4.0 que l'équipe n'a pas publié), et la différence ne change rien à la conduite à tenir.

Chronologie : une divulgation à l'envers

Le point de comparaison qui vient à l'esprit est CVE-2024-4577, l'injection d'arguments dans PHP-CGI sous Windows divulguée en juin 2024 : Akamai avait observé les premières tentatives sur ses leurres dans les vingt-quatre heures, et un rançongiciel l'exploitait dans la semaine. Cette faille-là ne touchait qu'une configuration précise. php2shell, si l'hypothèse se confirme, touche la configuration par défaut.

Ce qui est établi, ce qui est hypothèse, ce qui est rumeur

Pour une faille divulguée à l'envers, la hiérarchie des sources compte plus que d'habitude. Trois niveaux.

Établi. L'annonce de PHP, relayée sur oss-security et le forum de la PHP Foundation : deux vulnérabilités critiques, 9,2, correctif le 21 octobre à 14 h UTC. La confirmation de watchTowr, par la voix de son dirigeant Benjamin Harris : « Information has leaked wrt zero-day embargoed RCE vulns in PHP. We can confirm that they're real. » La société ajoute avoir reproduit CVE-2026-109618 en laboratoire et refuse d'en dire plus avant le correctif. L'avis 2026-018 du CERT-EU, qui recommande d'isoler du réseau public toute application PHP exposée qu'on ne pourra pas corriger immédiatement.

Hypothèse convergente. Plusieurs sources indépendantes désignent le même endroit du code : la fonctionnalité Session Upload Progress de l'extension session, activée par défaut depuis PHP 5.4, et plus largement le parseur de corps multipart/form-data. GMO Flatt Security, au Japon, y arrive par sa propre analyse et par la lecture d'un enregistrement d'exploitation diffusé par un chercheur. Le chercheur Kirill Firsov, qui a baptisé la faille, recommande de désactiver cette fonctionnalité en attendant. Un fil Hacker News parle de « deux primitives de type use-after-free sur le tas » dans ce gestionnaire. La piste est crédible, cohérente avec le fait que le code concerné tourne sur toutes les branches depuis 5.4, et PHP ne l'a ni confirmée ni démentie.

Rumeur. Le score de 10,0. La liste précise des versions affectées. L'affirmation qu'un simple POST sur n'importe quel fichier .php suffit (plausible, non démontrée). Une analyse anonyme très détaillée, avec numéros de ligne et décalages de structures, qui circule depuis le 20 octobre : elle cite 8.2.34 à la fois comme version vulnérable et comme version corrigée, promet un outil doté d'une option « cible en direct », et ne montre aucun résultat vérifiable. Nous ne la reprenons pas, et nous vous déconseillons d'exécuter quoi que ce soit qui en provient. Les faux PoC piégés sont une technique d'attaque à part entière, et ces journées-là sont leur meilleur moment.

Le mécanisme supposé : un code qui s'exécute avant le vôtre

Si l'hypothèse se confirme, voici ce qu'il faut comprendre, au niveau où les sources publiques le décrivent et sans recette d'exploitation.

Quand un navigateur envoie un formulaire contenant un fichier, il encode la requête en multipart/form-data, une suite de « parties » séparées par une chaîne de délimitation. PHP lit ce corps très tôt, à l'initialisation de la requête, dans le gestionnaire hérité de la RFC 1867 : c'est lui qui remplit $_POST et $_FILES avant que votre script ne commence. Votre application n'a pas besoin d'accepter des fichiers, ni même de lire $_POST, pour que ce code s'exécute. Il suffit qu'une URL servie par PHP reçoive une requête de ce type.

Greffée sur ce parseur, la fonctionnalité Session Upload Progress existe depuis PHP 5.4. Son but est anodin : permettre à une page d'afficher une barre de progression pendant un envoi de fichier. Pour cela, quand le formulaire contient un champ portant un nom particulier (PHP_SESSION_UPLOAD_PROGRESS par défaut), PHP écrit dans la session, au fil de la lecture du corps, des compteurs d'octets reçus. Elle est activée par défaut dans php.ini-production. La grande majorité des applications ne s'en servent jamais, et elle est là quand même.

L'hypothèse technique qui circule tient en une phrase : ce gestionnaire conserverait des références vers des structures qu'une autre partie du traitement libère, puis les réutiliserait, ce qui en fait un use-after-free sur le tas, la classe de bug qui mène le plus sûrement à l'exécution de code quand on sait façonner la mémoire. L'enregistrement analysé par Flatt Security va dans ce sens : on y voit des fuites d'adresses mémoire servant à contourner la randomisation (ASLR), puis l'obtention d'une commande sous l'identité du serveur web, www-data, en une vingtaine de secondes, sur un Ubuntu 26.04 en Apache et mod_php. Une seconde faille, celle que les mêmes sources situent dans le parseur multipart lui-même, se déclencherait indépendamment du réglage de progression. C'est le point qui rend la mesure d'attente la plus citée insuffisante, nous y revenons plus bas.

Ce qu'il faut en retenir, sans attendre la confirmation : la surface n'est pas « les pages qui acceptent des fichiers ». C'est toute URL servie par PHP, y compris une page de maintenance en PHP, un index.php vide, un vieux info.php oublié. Et aucun contrôle écrit en PHP ne s'exécute avant : ni authentification, ni vérification de signature, ni pare-feu applicatif codé dans le framework. Sansec le dit pour les boutiques : l'attaque frappe PHP avant le code du commerçant et avant leur propre protection applicative.

Suis-je concerné ? Le périmètre, sans jargon

La bonne question n'est pas « est-ce que mon site utilise des uploads ». C'est « est-ce que du PHP répond en HTTP quelque part sur mon périmètre, et sur quelle branche ».

• Vous exposez un site ou une application PHP sur Internet, en mod_php, PHP-FPM, php-cgi ou LiteSpeed : vous êtes en première ligne, quel que soit le CMS ou le framework posé dessus. Le correctif attendu ne concerne que les branches 8.2, 8.3, 8.4 et 8.5.
• Vous êtes sur PHP 8.1 ou plus ancien : aucune version amont ne sortira pour vous. Mais « hors support amont » ne veut pas toujours dire « sans correctif », voir plus bas la nuance sur les paquets de distribution.
• Vous utilisez un hébergement mutualisé ou infogéré : c'est l'hébergeur qui met PHP à jour. Votre travail aujourd'hui est de savoir quelle version vous sert et de lui demander son calendrier.
• Vous n'exposez PHP qu'en interne, intranet, outil métier, console d'une appliance : le risque est moindre mais pas nul. Un poste compromis sur le réseau, ou un prestataire, peut atteindre ces URL.
• PHP en ligne de commande seulement (scripts, cron, workers) : le vecteur multipart suppose une requête HTTP. Ce n'est pas exposé à cette faille, mettez à jour dans le cycle normal.

Un mot sur les branches, parce que le calendrier de support est au cœur du sujet. PHP maintient chaque branche quatre ans : deux ans de support actif puis deux ans de correctifs de sécurité seuls. Au 21 octobre 2026 :

La proportion de parc concernée est ce qui rend cette faille différente des précédentes. Toujours selon W3Techs, 27 % des sites PHP tournent encore sur une branche 7 et près de 8 % sur une branche 5. Du côté des serveurs visibles depuis Internet, le relevé Shodan publié le 20 octobre par Mallory compte environ 1,5 million d'hôtes annonçant leur version de PHP dans leurs en-têtes, dont 59 % sur une branche qui ne recevra pas de correctif amont. Pour la France, c'est un peu plus d'un hôte sur deux. Ces chiffres comptent des bannières, pas des organisations, et un serveur mutualisé en cache des centaines : ils donnent un ordre de grandeur, pas un décompte. Il dit assez que le 21 octobre à 16 h, la moitié du PHP exposé n'aura pas de correctif à appliquer.

Vérifier son exposition sans rien casser

On ne « teste » pas php2shell en envoyant une charge : sans correctif publié, reproduire la faille, c'est au mieux faire planter un processus de production, au pire exécuter un code dont on ne sait pas d'où il vient. La vérification se fait donc par constat de configuration, et elle tient en trois gestes.

1. Savoir quelle version de PHP répond réellement en HTTP

Le piège classique : sur Debian et Ubuntu, php -v en ligne de commande peut répondre pour une autre installation que celle qui sert vos pages. Interrogez le binaire qui tourne vraiment :

php-fpm -v                 # ou php-fpm8.3 -v, php83-php-fpm -v selon la distribution
apachectl -M | grep php    # mod_php chargé ?
dpkg -l 'php*' | grep '^ii'    # Debian / Ubuntu : révision exacte des paquets
rpm -qa 'php*'                 # RHEL / Alma / Rocky

Si vous n'avez pas la main sur le serveur (mutualisé), un fichier temporaire contenant <?php phpinfo(); donne la version et la configuration du SAPI web. Supprimez-le aussitôt lu : un phpinfo() oublié est une fuite d'information en soi. Et regardez vos en-têtes de réponse : un X-Powered-By: PHP/8.1.2 dans la réponse HTTP est exactement ce que les attaquants utiliseront pour trier leurs cibles. Le faire taire (expose_php = Off) ne corrige rien, mais vous retire de la première vague de scans.

Depuis l'extérieur, un seul en-tête lu sans rien envoyer d'autre suffit à situer la version. C'est exactement ce que fait notre analyse de domaine, et rien de plus :

curl -sI https://exemple.fr/ | grep -iE '^(server|x-powered-by):'
# Server: Apache/2.4.57 (Debian)
# X-Powered-By: PHP/8.1.2      ← version annoncée, à situer dans la plage touchée

2. Lire l'état du réglage incriminé, côté serveur web

php-fpm -i | grep -E 'session.upload_progress.enabled|file_uploads|session.upload_progress.name'

Sur mod_php, lisez ces valeurs dans le phpinfo() évoqué plus haut : la ligne de commande charge souvent un php.ini différent de celui d'Apache. On partout est la configuration par défaut, et donc l'état le plus probable.

3. Lister ce qui, chez vous, parle PHP

C'est le geste le plus rentable, et le plus souvent oublié. Pas seulement « le site » : les sous-domaines de préproduction, l'ancien blog, le phpMyAdmin derrière un chemin obscur, l'extranet fournisseur, la console de la baie de stockage, l'interface de la caméra. Tout ce qui répond avec un en-tête PHP ou un cookie PHPSESSID est dans le périmètre. Les outils d'inventaire de surface externe le font en une passe ; à la main, c'est un grep dans vos zones DNS et un passage sur chaque hôte.

Un mot sur les outils de « détection » apparus depuis le 20 octobre. Un scanner public mesure si un serveur est joignable par le chemin de code suspecté en lui envoyant deux douzaines de requêtes multipart aux formes limites et en comptant les processus PHP-FPM qui meurent. Son propre laboratoire n'a provoqué aucun plantage, et un résultat « mitigé » signifie seulement qu'un 403 a bloqué la requête en amont, pas que PHP est corrigé. Lancé contre une production, il envoie du trafic anormal à un serveur sans rien prouver. Nous ne le recommandons pas tant que le correctif n'a pas donné une référence à laquelle comparer.

Que faire maintenant : le plan de remédiation

Par ordre d'efficacité, la seule remédiation complète étant la version corrigée.

Avant 16 h : se mettre en position de corriger en minutes, pas en jours

1. Identifier le canal par lequel le correctif vous arrivera. Paquets de la distribution (et lesquels : dépôt officiel, PPA d'Ondřej Surý, dépôt Remi), image Docker officielle php ou dérivée (FrankenPHP, images maison), panneau d'hébergement (cPanel et EasyApache, Plesk, CloudLinux et ses alt-php), ou hébergeur infogéré. Chacun a son propre délai de construction après la sortie amont, qui se compte en heures pour les premiers et parfois en jours pour les derniers. Le savoir maintenant évite de le découvrir à 16 h 05.
2. Préparer et répéter la procédure : commande de mise à jour, redémarrage de PHP-FPM ou d'Apache, test de non-régression minimal (une page qui se charge, un envoi de formulaire, une connexion). Sur un parc, l'avoir scriptée.
3. Prévenir qui doit l'être : une mise à jour de PHP en pleine journée coupe le service quelques secondes et peut révéler une incompatibilité. Mieux vaut l'annoncer que la subir.
4. Prendre un instantané (sauvegarde, snapshot de VM) des hôtes exposés. Si une compromission survient entre la fuite et le correctif, c'est l'état de référence pour l'enquête.

En attendant : des mesures qui réduisent la surface, pas qui la ferment

• Désactiver le suivi de progression. Dans le php.ini du SAPI web : session.upload_progress.enabled = Off, puis recharger PHP-FPM ou Apache. Sans accès au php.ini, un fichier .user.ini à la racine web fait l'affaire en FPM et en CGI (pris en compte après au plus cinq minutes, le temps du cache user_ini.cache_ttl), et une ligne php_flag session.upload_progress.enabled off dans .htaccess sous mod_php, si AllowOverride l'autorise. Ce réglage ne peut pas se poser depuis le code avec ini_set(), il est trop tôt dans la requête. Vérifiez le résultat du côté web, pas en ligne de commande.
• Refuser les requêtes multipart là où elles n'ont rien à faire. C'est la mesure la plus solide en attendant, parce qu'elle agit avant PHP, au niveau du serveur web ou du reverse proxy : un POST en multipart/form-data sur une URL qui n'accepte pas de fichiers n'a aucune raison d'exister. Un kit communautaire propose la règle Apache en mod_rewrite ; sous nginx, un if sur $content_type dans les location concernées fait le même travail. Contrepartie évidente : vous cassez les envois de fichiers sur les routes bloquées. Faites la liste de celles qui en ont besoin et ne bloquez que le reste. Bloquer le seul nom de champ PHP_SESSION_UPLOAD_PROGRESS au pare-feu applicatif est plus fin mais ne couvre que le premier chemin.
• Les règles de pare-feu applicatif des fournisseurs. Cloudflare a poussé le 21 octobre deux versions d'urgence de ses jeux de règles gérés et gratuits, quatre règles intitulées « Generic Rules - Anomalous Execution », en mode blocage. Elles ne nomment ni CVE ni PHP, ce qui est normal sous embargo. Si vous êtes derrière un WAF, vérifiez que ces jeux sont actifs. Et gardez en tête ce que rappelle Sansec : une protection applicative arrive après le point d'impact, elle filtre du trafic connu, elle ne corrige pas le parseur.
• Ce qui ne sert à rien. Bloquer le cookie PHPSESSID (les sessions légitimes cassent, le parseur tourne quand même). Mettre à jour WordPress, Drupal ou vos dépendances Composer (la faille est dans l'interpréteur, pas dans le code qu'il exécute). Compter sur file_uploads = Off seul : il écarte les parties « fichier », le corps est toujours lu.
• Isoler ce qu'on ne pourra pas corriger. Pour les branches sans correctif et sans rétroportage, le CERT-EU est clair : derrière un VPN, une liste d'adresses autorisées, ou hors ligne. Une vieille application PHP 5.6 exposée au public le 21 octobre au soir est un problème de jours, pas de semaines.

Concrètement, pour refuser les requêtes multipart hors des routes qui acceptent un envoi de fichier, côté Apache (.htaccess) :

<If "%{REQUEST_METHOD} == 'POST' && %{CONTENT_TYPE} =~ m#multipart/form-data#i">
  Require all denied
</If>

Et côté nginx, dans les location sans upload légitime :

if ($content_type ~* multipart/form-data) { return 403; }

À réserver aux chemins qui n'acceptent pas de fichier : ailleurs, vous casseriez les formulaires d'envoi.

Réduire ce qu'un attaquant obtiendrait

Même corrigé le jour même, un serveur a pu être visé entre la fuite et la mise à jour. Les mesures de défense en profondeur habituelles prennent ici tout leur sens : un utilisateur www-data sans droits inutiles, disable_functions et open_basedir posés, un filtrage des connexions sortantes (un shell inversé a besoin de sortir), des secrets qui ne traînent pas en clair dans l'arborescence web, et des journaux qui partent vers un hôte distant avant qu'un intrus ne les nettoie.

Surveiller, le temps de corriger, et après

Il n'existe aucun indicateur de compromission propre à php2shell au 21 octobre. La surveillance est donc comportementale, et Huntress en a dressé la liste utile : un processus php-fpm, php-cgi, httpd ou apache2 qui lance un shell (sh, bash), un interpréteur (python, perl) ou un outil réseau (curl, wget, nc) ; des lignes de commande contenant /dev/tcp/, mkfifo ou fsockopen ; des commandes de reconnaissance (whoami, id, uname -a) lancées sous l'identité du serveur web ; de nouveaux fichiers PHP dans la racine web ou dans /tmp ; des connexions sortantes inhabituelles. Les règles Sigma génériques « webshell sous Linux » couvrent l'essentiel, et une configuration auditd sur l'UID du serveur web fait le reste. Ajoutez un signal propre à cette faille : une hausse de plantages de workers PHP-FPM (segfaults dans le journal de FPM) corrélée à des POST multipart est exactement la trace qu'un exploit peu fiable laisse derrière lui.

Après le correctif : vérifiez la version par SAPI, pas seulement en ligne de commande, et si un hôte a été exposé sans mesure d'attente entre le 20 et le moment de sa mise à jour, cherchez. Fichiers récents dans la racine web, tâches cron, comptes créés, clés SSH ajoutées. Et changez les secrets accessibles depuis le serveur : si un attaquant est passé, c'est ce qu'il a emporté.

La leçon : ce qui tourne avant votre code échappe à vos protections

php2shell, quelle que soit sa mécanique exacte, rappelle une chose que les équipes applicatives oublient facilement. Toute une couche logicielle s'exécute avant la première ligne de votre code : le serveur web, le SAPI, les parseurs de requête de l'interpréteur. Vos contrôles d'accès, vos validations, votre pare-feu applicatif écrit dans le framework ne voient jamais une requête qui a fait planter PHP avant eux. La seule défense à ce niveau est la version, et la seule façon de la tenir est de savoir, à tout moment, ce qui tourne où.

C'est aussi un rappel sur la dette des versions en fin de vie. Une branche hors support ne coûte rien tant qu'il ne se passe rien. Le jour où une faille de l'interpréteur sort, elle devient un actif qu'on ne peut ni corriger ni laisser en ligne, et la migration qu'on repoussait depuis deux ans doit se faire en un week-end. Un tiers du web PHP est dans cette situation ce matin.

Et une faille comme celle-ci ne se voit ni dans un scan applicatif, ni dans un pentest annuel daté du printemps. Elle se voit quand on cartographie tout son système d'information, quand on fait l'inventaire de sa surface d'attaque externe jusqu'au dernier sous-domaine qui répond en PHP 5.6, et quand on sait prioriser : un 9,2 sur un interpréteur présent partout passe avant tout le reste de la semaine. La leçon rejoint celle de wp2shell et de CVE-2026-87902 cet été : la fenêtre entre divulgation et exploitation se compte en heures, et on ne la tient que si l'inventaire existait avant.

Détecter ce type d'exposition en continu avec Flawfence

Chez Flawfence, le principe ne change pas d'une faille à l'autre. Le moteur cartographie votre périmètre exposé sur Internet, identifie les services qui y répondent en votre nom, situe leurs versions dans les plages vulnérables connues et vérifie l'exposition des vecteurs concernés, sans jamais envoyer de charge destructrice.

Pour php2shell, soyons précis sur ce que cela veut dire aujourd'hui. Nous ne lançons pas l'exploit, et nous ne prétendons pas confirmer à distance une faille dont l'éditeur n'a pas encore publié le mécanisme : ce serait malhonnête, et dangereux pour vos serveurs. Ce que le moteur fait déjà, c'est l'autre moitié du problème, celle qui décide de tout à 16 h : la liste de vos hôtes qui répondent en PHP, avec la branche annoncée, le signalement de celles qui sont en fin de vie, et les interfaces d'administration, préproductions et sous-domaines oubliés qui parlent PHP sans que personne ne s'en souvienne. Dès que l'avis officiel aura donné les plages de versions affectées et corrigées, la vérification de version sera alignée dessus, comme nous l'avons fait pour chaque faille WordPress de l'été.

Questions fréquentes sur php2shell (CVE-2026-109618 et CVE-2026-109619)

Qu'est-ce que php2shell, en une phrase ?

Le nom donné à deux vulnérabilités critiques d'exécution de code à distance dans le cœur de PHP, CVE-2026-109618 et CVE-2026-109619, notées 9,2 en CVSS v4.0, dont l'existence a fuité le 20 octobre 2026 et dont le correctif est publié le 21 octobre à 14 h UTC. Selon l'hypothèse dominante, non confirmée par PHP, elles vivent dans le traitement des requêtes multipart et du suivi de progression des envois de fichiers.

Quelles versions de PHP sont concernées ?

PHP ne l'a pas encore publié. La fuite revendique « toute version depuis 5.4.0 », ce que la nature du code suspecté rend plausible, mais que l'éditeur n'a pas confirmé. Ce qui est certain, c'est que le correctif amont ne sortira que pour les branches maintenues, 8.2 à 8.5. Les branches plus anciennes dépendent du rétroportage de leur distribution ou de leur hébergeur.

Mon site WordPress est-il vulnérable ?

Si l'hypothèse se confirme, oui, comme toute application servie par un PHP non corrigé, et sans qu'aucun plugin ni réglage de WordPress n'y change quoi que ce soit : la faille s'exécute avant WordPress. Mettre WordPress à jour ne protège pas. Ce qui compte est la version de PHP qui le sert, donc le travail de votre hébergeur si vous êtes en mutualisé.

La faille est-elle exploitée dans la nature ?

Pas à notre connaissance au 21 octobre 2026 au matin : ni Huntress ni watchTowr n'ont observé d'exploitation, et la faille ne figure pas au catalogue KEV de la CISA. Mais du code d'exploitation circule selon GMO Flatt Security, et le correctif révélera le bug à qui lit le diff. Il faut raisonner comme si l'exploitation commençait dans les heures qui suivent la publication.

Désactiver session.upload_progress suffit-il ?

Non. Cette mesure ferme probablement l'un des deux chemins, elle ne coûte rien et elle vaut la peine d'être appliquée. Mais GMO Flatt Security a corrigé sa recommandation le 21 octobre : l'attaque semble rester possible avec ce seul réglage. Ne marquez aucun système comme remédié tant qu'il ne tourne pas sur une version corrigée.

Un pare-feu applicatif me protège-t-il ?

Il réduit le risque, surtout s'il refuse les requêtes multipart sur les URL qui n'en ont pas besoin, parce que ce filtrage agit avant PHP. Les règles d'urgence poussées par Cloudflare le 21 octobre vont dans ce sens. Mais un pare-feu applicatif filtre des formes connues de trafic et peut se contourner ; il achète du temps, il ne remplace pas la mise à jour.

Je suis sur un hébergement mutualisé, que faire ?

Vérifier la version de PHP qui vous sert (dans le panneau de l'hébergeur ou via un phpinfo() temporaire), choisir la branche la plus récente qu'il propose si vous êtes encore en 7.x ou 8.0, et lui demander explicitement quand les versions corrigées seront déployées. Les bons hébergeurs communiquent dessus aujourd'hui ; un silence est une réponse.

En résumé

php2shell est la situation que les équipes de sécurité redoutent : une faille dans un composant présent sur deux tiers du web, divulguée par une fuite avant son correctif, exploitable avant tout code applicatif, et dont la moitié du parc exposé ne pourra pas se corriger par une simple mise à jour. L'état des connaissances au 21 octobre au matin est clair sur l'essentiel, deux RCE réelles et un correctif à 16 h, et flou sur le reste, mécanisme exact et versions affectées.

Ce qu'on peut faire aujourd'hui tient en trois lignes : savoir quel PHP répond où, être prêt à mettre à jour en minutes à 16 h, et pour ce qui ne pourra pas l'être, réduire la surface maintenant et isoler ce qui doit l'être. Le réflexe de fond reste le même que pour chaque faille que nous couvrons : un inventaire exhaustif de ce que votre organisation expose, et une surveillance continue de la version de ces actifs. C'est ce que Flawfence fait, pour PHP comme pour la prochaine faille qui n'a pas encore de numéro.

Vérifiez votre exposition dès maintenant, il ne vous faudra que 5 minutes.

Sources

• php.net, « Upcoming Critical PHP Security Release », 20 octobre 2026
• PHP Foundation, annonce sur le forum
• oss-security, relais de l'annonce, 20 octobre 2026
• CERT-EU, avis de sécurité 2026-018
• watchTowr, « PHP Remote Code Execution FAQ: CVE-2026-109618 & CVE-2026-109619 »
• watchTowr, confirmation de la fuite sur X
• Sansec, « Critical PHP RCE: CVE-2026-109618 and CVE-2026-109619 »
• Huntress, « Rapid Response: php2shell, Leaked Critical PHP Vulnerabilities »
• GMO Flatt Security, synthèse et consignes sur php2shell (japonais, mis à jour le 21 octobre)
• Mallory, « PHP Remote Code Execution (RCE): 884K Hosts Get No Fix » (relevé Shodan du 20 octobre)
• Hacker News, « Tell HN: 2x PHP RCE CVEs with CVSS 10.0 Incoming »
• SecurityWeek, « PHP2Shell: Mass Exploitation Looms for Leaked Critical PHP Flaws »
• Cloudflare, journal des modifications du WAF, versions d'urgence du 21 octobre 2026
• php.net, versions supportées
• W3Techs, usage de PHP par version
• Documentation PHP, Session Upload Progress