PHP2Shell est le nom donné à deux failles critiques d’exécution de code à distance dans PHP, CVE-2026-109618 et CVE-2026-109619, notées 9.2 sur 10. Le correctif officiel sort le 21 octobre 2026 à 16h (heure de Paris). Voici ce qu’on sait de cette faille PHP, les risques pour vos sites, les contournements à appliquer tout de suite et la procédure de mise à jour.
Article publié le 21 octobre 2026 avant la release officielle — mis à jour dès la publication de l’avis de sécurité PHP.
PHP2Shell : deux RCE dans PHP lui-même, publiées dans l’urgence
Ce mercredi 21 octobre 2026 à 14h00 UTC (16h00 heure de Paris), l’équipe sécurité de PHP publie une release corrigeant deux vulnérabilités critiques : CVE-2026-109618 et CVE-2026-109619, surnommées PHP2Shell. Il ne s’agit pas d’une faille dans un CMS ou une extension, mais dans l’interpréteur PHP : WordPress, Nextcloud, Magento, Drupal, Laravel, vos outils internes… tout ce qui tourne sur PHP est potentiellement concerné.
La divulgation devait se faire sous embargo le jeudi 22 octobre. Les identifiants CVE et une capture d’un outil d’exploitation ont fuité la veille, ce qui a poussé PHP à avancer la publication. Cet article fait le point sur ce qui est confirmé, ce qui ne l’est pas encore, et surtout sur ce que vous pouvez faire avant et après 16h.
- Type : exécution de code à distance (RCE) dans le cœur de PHP
- Sévérité : CVSS v4.0 = 9.2 pour les deux CVE selon l’équipe PHP (les messages ayant fuité parlaient de 10.0, sans préciser la version de CVSS)
- Correctif : release officielle le 21/10/2026 à 14h00 UTC, uniquement sur les branches supportées (8.2 à 8.5)
- Versions corrigées attendues (non confirmées par php.net au moment d’écrire) : 8.5.12, 8.4.27, 8.3.36, 8.2.35
- PHP 8.1 et antérieurs : fin de vie, aucun correctif officiel
Chronologie de la fuite PHP2Shell
| Date (UTC) | Événement |
|---|---|
| 20/10, 15h20 | Un post sur Hacker News annonce deux divulgations RCE imminentes dans PHP |
| 20/10 | PHP publie un avis anticipé (« advance notice ») de release de sécurité critique. watchTowr confirme que les failles sont réelles. CERT-EU publie un avis |
| 21/10, 02h13 | Un développeur du cœur PHP déclare que la seule mitigation est la mise à jour |
| 21/10, 07h43 | Cloudflare signale les premières attaques contre des sites PHP et déploie des règles WAF |
| 21/10, 08h48 | La PHP Foundation prévient que le dépôt de Remi (RHEL/Fedora) ne sera pas mis à jour le jour même |
| 21/10, 10h35 | Selon Sansec, plusieurs sites néerlandais (Tweakers, Tweede Kamer, NCSC, Security.NL) passent hors ligne |
| 21/10, 14h00 | Release de sécurité PHP |
CVE-2026-109618 et CVE-2026-109619 : ce qui est connu… et ce qui ne l’est pas
Confirmé
- Deux vulnérabilités critiques notées 9.2 en CVSS v4.0 par l’équipe PHP, annoncées officiellement sur php.net.
- Ce sont des RCE : watchTowr a confirmé la nature des failles et indique avoir reproduit CVE-2026-109618.
- Seules les branches 8.2, 8.3, 8.4 et 8.5 recevront un correctif upstream. La 8.2 n’est d’ailleurs plus supportée que jusqu’au 31 décembre 2026.
- Du code se présentant comme un exploit circule publiquement, et une vidéo de démonstration d’une chaîne baptisée « php2shell » a été diffusée (Kirill Firsov, qui en crédite les chercheurs LCFR et Calif.io).
Pas encore confirmé
- Le composant exact : aucun SAPI, extension ou fonction n’a été nommé officiellement. Les mitigations proposées par Sansec (blocage du
multipart/form-data) et les discussions autour desession.upload_progresslaissent penser que le parsing des requêtes multipart, que PHP effectue avant l’exécution de votre code applicatif, est au moins l’un des vecteurs. Rien d’officiel à ce stade. - Les versions affectées : CERT-EU évoque « possiblement toutes les versions depuis PHP 5 », la bannière de l’outil fuité revendique « 5.4.0 et suivantes ». php.net ne publiera la liste qu’avec la release.
- Les numéros de versions corrigées (8.5.12 / 8.4.27 / 8.3.36 / 8.2.35) proviennent de trackers (Alpine, Kevin Beaumont), pas encore de PHP.
- L’exploitation active : Cloudflare dit observer des attaques émergentes ; d’autres sources (watchTowr, CISA KEV) ne recensent pas encore d’exploitation confirmée. Les deux ne sont pas contradictoires : des tentatives n’impliquent pas des compromissions réussies.
Attention aux faux PoC. Comme à chaque fuite très médiatisée, des dépôts « exploit PHP2Shell » non vérifiés apparaissent. Tenable rappelle que ce genre de code est régulièrement piégé (malware ciblant… ceux qui le lancent). Ne testez rien qui ne vienne pas d’une source identifiée, et jamais hors d’un labo isolé.
Faille PHP2Shell : quels risques pour vos sites ?
Une RCE dans l’interpréteur, c’est le pire scénario pour un hébergeur ou un admin de sites :
- Surface gigantesque : Silas Cutler estime à plus de 1,3 million le nombre d’hôtes exposés potentiellement vulnérables ; une recherche Shodan (Henk Poley) compte plus de 1,9 million d’hôtes PHP exposés.
- Indépendant de l’application : si le vecteur se situe bien dans le traitement des requêtes, l’attaque frappe avant votre code. Un WordPress parfaitement à jour, un pare-feu applicatif en PHP (Wordfence, etc.) ou un plugin de sécurité ne servent à rien. Sansec note d’ailleurs que les modes maintenance de WordPress et Magento ne protègent pas, puisque PHP est toujours appelé.
- Fenêtre de patch très courte : Sansec s’attend à des attaques massives dans les 15 minutes suivant la publication, quand les correctifs (diff des sources) permettront de comprendre précisément les bugs.
- Parc legacy : tout ce qui tourne encore en PHP 7.x ou 8.0/8.1 (vieux conteneurs, Debian 11, Ubuntu 22.04 hors backports…) restera vulnérable sans correctif upstream.
- Impact classique d’une RCE web : webshell, vol de la base de données et des identifiants (
wp-config.php,.env), injection de skimmers sur les sites e-commerce, rebond vers le reste de l’infrastructure.
Avant le patch : inventorier vos versions de PHP
Première étape, savoir où tourne PHP. On oublie souvent une deuxième version installée en parallèle ou un vieux conteneur :
# Paquets PHP installés (Debian/Ubuntu)
dpkg -l 'php*' | grep ^ii
# Versions réellement en service
php -v
ps -eo pid,lstart,cmd | grep -E '[p]hp-fpm: master|[a]pache2'
# Conteneurs Docker : image utilisée et version de PHP
docker ps --format '{{.Names}}\t{{.Image}}'
for c in $(docker ps -q); do
echo "$(docker inspect -f '{{.Name}}' $c): $(docker exec $c php -r 'echo PHP_VERSION;' 2>/dev/null)"
doneEnsuite, préparez le terrain pour pouvoir patcher vite et revenir en arrière si besoin : sauvegarde des fichiers et dumps SQL, tag des images Docker actuelles (docker tag wordpress:php8.3-apache wordpress:php8.3-apache-rollback), procédure de redémarrage écrite. Repérez aussi toute machine en PHP 8.1 ou antérieur : elle devra être isolée ou migrée.
PHP2Shell : les contournements en attendant le correctif
Soyons clairs d’emblée : les développeurs PHP répètent que la seule mitigation est la mise à jour (« ini settings won’t save you », Joe Ferguson, release manager de PHP 8.6). Les mesures ci-dessous réduisent l’exposition pendant quelques heures, elles ne remplacent pas le correctif.
1. Bloquer les requêtes multipart/form-data au niveau du serveur web
C’est la mesure recommandée par Sansec : rejeter ces requêtes avant qu’elles n’atteignent PHP. Contrepartie : plus d’upload de fichiers (médiathèque WordPress, formulaires avec pièce jointe, certains tunnels de commande).
Apache (dans le VirtualHost, mod_rewrite requis) :
RewriteEngine On
RewriteCond %{HTTP:Content-Type} multipart/form-data [NC]
RewriteRule ^ - [F]Nginx (dans le bloc server) :
if ($http_content_type ~* "multipart/form-data") {
return 403;
}Si vous avez absolument besoin d’uploads pour l’administration, ajoutez une exception par IP (RewriteCond %{REMOTE_ADDR} !^203\.0\.113\.10$) plutôt que d’ouvrir à tout le monde. Testez ensuite avec curl -F 'a=b' https://votre-site/ : la réponse doit être un 403.
2. Passer le site en lecture seule ou hors ligne
Pour les sites critiques, plus radical : n’autoriser que GET et HEAD, ou arrêter PHP-FPM et servir une page de maintenance statique directement depuis le serveur web. Encore une fois, le mode maintenance de WordPress ne compte pas : PHP est toujours exécuté.
# Apache : refuser tout sauf GET/HEAD (et OPTIONS si besoin)
<Location "/">
<LimitExcept GET HEAD>
Require all denied
</LimitExcept>
</Location>3. WAF en frontal (Cloudflare & co)
Cloudflare a déployé des règles WAF managées ciblant les vecteurs connus, y compris pour les comptes gratuits. Son CTO les qualifie lui-même de « STOPGAP only ». Deux conditions pour qu’elles servent à quelque chose : le domaine doit être proxifié (nuage orange), et le serveur d’origine doit n’accepter que les plages IP de Cloudflare — sinon un attaquant qui connaît l’IP de l’origine contourne simplement le WAF. Gardez aussi en tête que les WAF ont historiquement des limites sur l’inspection des gros corps multipart (troncature au-delà d’une certaine taille).
4. Durcissement php.ini (bonus, sans garantie)
; /etc/php/8.x/{fpm,apache2}/conf.d/99-php2shell.ini
session.upload_progress.enabled = 0
session.use_strict_mode = 1Ces réglages ciblent une piste supposée et ne couvrent pas forcément le second bug ; Sansec précise qu’ils n’ont aucun effet si vos sessions sont stockées dans Redis ou en base. Ça ne coûte rien sur la plupart des sites, mais ne vous croyez pas protégé pour autant.
5. Isoler ce qui ne peut pas être patché
Pour tout ce qui est en PHP 8.1 ou antérieur, CERT-EU recommande de retirer l’application d’Internet si la mise à jour n’est pas possible : accès via VPN, liste blanche d’IP, ou arrêt pur et simple. C’est le bon moment pour enfin migrer ce vieux site…
Mettre à jour PHP : appliquer le correctif PHP2Shell
Paquets système (Debian / Ubuntu)
Les distributions rétroportent les correctifs sans changer le numéro de version upstream : un php8.3 d’Ubuntu 24.04 peut être corrigé tout en affichant 8.3.6. Vérifiez donc le changelog plutôt que la version. Si vous utilisez le dépôt d’Ondřej Surý, il suit en principe les versions upstream.
apt update && apt list --upgradable 2>/dev/null | grep php
apt install --only-upgrade 'php8.3*' # adapter à votre branche
# Le correctif est-il bien dans le paquet ?
apt changelog php8.3-fpm 2>/dev/null | grep -E 'CVE-2026-10961(8|9)'
# INDISPENSABLE : redémarrer ce qui charge PHP
systemctl restart php8.3-fpm # et/ou
systemctl restart apache2 # si mod_phpUn paquet corrigé sur le disque ne protège de rien tant que les anciens workers tournent. Comparez l’heure de démarrage des processus avec l’heure d’installation du paquet (ps -eo pid,lstart,cmd | grep '[p]hp-fpm: master').
RHEL / Rocky / Alma
Surveillez les RHSA et errata correspondants (dnf module list --enabled php pour savoir quel flux vous utilisez). Les utilisateurs du dépôt Remi doivent savoir qu’il ne sera pas mis à jour le 21 octobre : appliquez les contournements ci-dessus en attendant.
Conteneurs Docker
Les images officielles (php, wordpress, nextcloud…) seront reconstruites ; un conteneur en cours d’exécution ne récupère jamais seul la nouvelle image. Il faut tirer l’image, reconstruire vos images dérivées, puis recréer le conteneur (un simple docker restart ne suffit pas) :
docker pull wordpress:php8.3-apache
docker compose up -d --force-recreate monsite
docker exec monsite php -r 'echo PHP_VERSION, PHP_EOL;'Vérifiez la date de build de l’image (docker image inspect -f '{{.Created}}' wordpress:php8.3-apache) : si elle est antérieure au 21 octobre 14h UTC, le correctif n’est pas encore dedans. Et après chaque mise à jour, contrôlez que vos sites répondent bien (code 200) et que les conteneurs sont sains.
Détection : mon serveur PHP a-t-il été compromis ?
Pas encore d’IOC officiels. En attendant, les signaux génériques d’une RCE web restent valables :
# Processus enfants des workers PHP-FPM (normalement : rien)
for p in $(pgrep -f '^php-fpm: pool'); do
ps --no-headers -o pid,user,lstart,cmd --ppid "$p"
done
# Shells / outils lancés par l'utilisateur du serveur web
ps -u www-data -o pid,lstart,cmd | grep -E 'sh|bash|curl|wget|nc|python|perl'
# Fichiers PHP créés ou modifiés depuis le 20 octobre
find /var/www -name '*.php' -newermt '2026-10-20' -ls
# Requêtes multipart inhabituelles (POST sur des URL qui n'en reçoivent jamais)
grep '"POST ' /var/log/apache2/*access*.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -30Si vous trouvez un webshell ou un processus suspect : isolez la machine, conservez les logs, puis changez tous les secrets accessibles par PHP (mots de passe de base, clés d’API, sels WordPress, Application Passwords) après avoir restauré une version saine.
PHP2Shell en résumé : que faire selon votre situation
| Situation | Action |
|---|---|
| PHP 8.2 à 8.5, paquets distrib ou Sury | Mettre à jour dès dispo, redémarrer FPM/Apache, vérifier le changelog |
| Conteneurs Docker | Pull de l’image rebuildée + recréation du conteneur |
| Dépôt Remi | Contournements (multipart, lecture seule, WAF) jusqu’à la mise à jour |
| PHP 8.1 ou antérieur | Pas de correctif : isoler d’Internet ou migrer |
| Avant le patch | Bloquer multipart/form-data, WAF avec origine filtrée, durcir php.ini |
| Après le patch | Chercher webshells et processus enfants suspects |
Cet article sera mis à jour lorsque l’avis officiel de PHP (versions affectées, versions corrigées, détails techniques) sera publié.
FAQ PHP2Shell
Qu’est-ce que PHP2Shell ?
PHP2Shell désigne deux vulnérabilités critiques d’exécution de code à distance (RCE) dans l’interpréteur PHP, CVE-2026-109618 et CVE-2026-109619, notées 9.2 en CVSS v4.0 et corrigées le 21 octobre 2026.
Quelles versions de PHP sont vulnérables à PHP2Shell ?
Les versions affectées seront confirmées dans l’avis officiel. Les premières sources évoquent toutes les versions depuis PHP 5.4. Seules les branches 8.2, 8.3, 8.4 et 8.5 reçoivent un correctif ; PHP 8.1 et antérieur n’en auront pas.
Quelles sont les versions de PHP corrigées ?
Les versions attendues sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Les distributions Linux rétroportent souvent le correctif sans changer le numéro de version : vérifiez le changelog du paquet.
WordPress est-il concerné par PHP2Shell ?
Oui : la faille se situe dans PHP et non dans WordPress. Un WordPress à jour, Wordfence ou le mode maintenance ne protègent pas. Il faut mettre à jour PHP (ou l’image Docker) puis redémarrer PHP-FPM ou Apache.
Comment se protéger de PHP2Shell avant le correctif ?
Bloquer les requêtes multipart/form-data au niveau du serveur web, passer les sites critiques en lecture seule, utiliser un WAF comme Cloudflare en filtrant l’accès direct à l’origine, et isoler les serveurs en PHP 8.1 ou antérieur. Seule la mise à jour corrige réellement la faille.
Divulgation responsable
Cet article est publié à des fins défensives et pédagogiques. Il s’appuie exclusivement sur des informations déjà rendues publiques par l’équipe PHP et par des acteurs reconnus (Sansec, Tenable, watchTowr, CERT-EU, Cloudflare). Il ne contient volontairement aucun détail d’exploitation et ne renvoie vers aucun code d’exploit. Toute vérification doit se faire uniquement sur des systèmes vous appartenant, en environnement isolé. Attaquer un système tiers sans autorisation écrite est illégal.
À lire aussi
Autres failles critiques récentes de l’écosystème PHP : wp2shell (CVE-2026-63030 & CVE-2026-60137) et Comment2Shell (CVE-2026-93485).
Sources
- PHP — Advance notice : critical security release du 21 octobre 2026
- Sansec — Critical PHP RCE: CVE-2026-109618 and CVE-2026-109619
- Tenable — php2shell : FAQ
- watchTowr — PHP Remote Code Execution FAQ
- PatchMon — Patching the Critical PHP RCE Across Your Fleet
- Tenable CVE — CVE-2026-109618