php2shell : la faille PHP critique d'octobre 2026, et comment protéger vos serveurs

Le 21 octobre 2026, l'équipe de PHP a publié en urgence des correctifs pour deux failles critiques baptisées php2shell (CVE-2026-109618 et CVE-2026-109619). Elles permettent à un attaquant non authentifié d'exécuter son propre code sur un serveur web qui fait tourner PHP. Or PHP fait fonctionner environ deux sites sur trois dans le monde : WordPress, Drupal, Joomla, Nextcloud, Matomo, PrestaShop, une bonne partie des applications métier et des panneaux d'hébergement comme cPanel ou Plesk.

Cet article explique ce qui s'est passé, comment l'attaque fonctionne (sans donner de quoi la reproduire), et surtout comment vous protéger, y compris si vous ne pouvez pas mettre à jour PHP tout de suite.

Ce qu'il faut retenir en 30 secondes

• Gravité : critique (CVSS v4 de 9,2 selon PHP, 10 selon watchTowr). Exécution de code à distance, sans compte ni mot de passe.
• Versions touchées : presque toutes les versions de PHP encore en service, de PHP 5.4 à PHP 8.5.
• Versions corrigées : PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Pour PHP 7.4, 8.0 et 8.1, en fin de vie, seuls des correctifs de code source existent, sans paquets officiels.
• Le plus exposé : PHP intégré à Apache (mod_php). PHP-FPM, php-cgi, FrankenPHP et LiteSpeed sont aussi concernés.
• Exploitation : des tentatives ont été observées avant même la publication des correctifs.

L'histoire de php2shell, de la découverte à l'urgence

Une anomalie connue depuis 2024

Selon l'historique publié depuis, un développeur du cœur de PHP avait repéré dès 2024, lors d'un audit, le mauvais comportement de PHP face à un manque de mémoire, à l'origine de l'une des deux failles. Faute d'accord sur la bonne correction, et faute d'attaque démontrée, le problème était resté en l'état.

La découverte en août 2026

En août 2026, Ryan Austin, chercheur chez Calif, retrouve ces failles et démontre qu'elles sont exploitables, dans le cadre d'un projet d'audit de logiciels libres assisté par intelligence artificielle. Les chercheurs de Wiz les découvrent de leur côté, eux aussi avec des outils d'IA. Comme le veut l'usage, les failles sont signalées discrètement à l'équipe de PHP, qui prépare les correctifs sous embargo, avec une publication prévue le 22 octobre.

La fuite et la course contre la montre

• 17 octobre : Amazon Threat Intelligence observe une tentative d'exploitation sur ses leurres (honeypots), quatre jours avant toute publication. Quelqu'un connaissait déjà la faille.
• 20 octobre : PHP annonce une publication de sécurité imminente. Le jour même, des détails fuitent : une discussion sur Hacker News, un message de watchTowr, et une vidéo de démonstration publiée par erreur. Un éditeur de distribution publie aussi ses paquets corrigés en avance, ce qui permet de comparer le code avant et après.
• 21 octobre : PHP avance sa publication. Les avis de sécurité sortent à 13 h 34 UTC, puis les versions corrigées dans la foulée.
• Le jour même : watchTowr voit des attaques sur son réseau de leurres, Cloudflare déploie en urgence des règles de pare-feu applicatif, et plusieurs administrations européennes mettent hors ligne, par précaution, des services qu'elles ne pouvaient pas corriger immédiatement.

Comment la faille a été validée

Les chercheurs ne se sont pas contentés de lire le code. Ils ont reproduit l'attaque sur des installations réelles et montré qu'une seule requête, envoyée sans authentification, suffit sur mod_php à déclencher la chaîne d'attaque avant même que le code du site ne s'exécute. C'est ce qui a fait passer ce bug d'une curiosité technique à une alerte mondiale. Plusieurs équipes de sécurité l'ont depuis reproduite indépendamment : il faut s'attendre à ce que des outils d'attaque prêts à l'emploi circulent rapidement.

Ce que fait l'attaque (sans le mode d'emploi)

Quand un navigateur envoie un formulaire ou un fichier à un site PHP, PHP analyse lui-même le contenu de la requête pour remplir $_POST et $_FILES, avant de passer la main au site. C'est à cette étape, commune à tous les sites PHP, que se trouvent les deux failles.

1. CVE-2026-109618, la mémoire interrompue au mauvais moment. L'attaquant envoie une requête construite pour que PHP manque de mémoire à un instant précis de cette analyse. Il peut par exemple multiplier les parties d'un envoi de fichiers sans nom de fichier, ou utiliser des noms de champs très imbriqués (a[b][c][d]…). PHP s'arrête alors en laissant ses données internes à moitié construites, et le nettoyage qui suit les traite comme si elles étaient valides. Cette corruption de mémoire peut être transformée en exécution de code.
2. CVE-2026-109619, l'état fantôme entre deux requêtes. Certaines données internes liées à une requête survivent alors que leur mémoire a été libérée. Une requête suivante, traitée par le même processus PHP, peut réutiliser cet état périmé, et l'attaquant en prend le contrôle. La fonction de suivi de progression des envois de fichiers (« session upload progress ») fait partie des chemins confirmés.

Deux détails rendent l'attaque sérieuse :

• La limite de taille des formulaires (post_max_size) ne suffit pas. PHP la contrôle sur la taille annoncée par la requête, pas toujours sur ce qu'il reçoit réellement, notamment avec les envois « par morceaux » (chunked).
• Avec mod_php, le processus Apache survit à l'erreur et reste réutilisable, ce qui facilite la seconde étape. C'est pourquoi PHP classe mod_php comme le plus à risque.

Enfin, aucune application n'est à l'abri par sa propre sécurité : l'attaque frappe avant même que WordPress, Nextcloud ou votre code ne démarrent.

Comment savoir si vous êtes concerné

• Votre version de PHP : php -v en ligne de commande, ou la page « Santé du site » dans WordPress. Toute version antérieure à 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 est vulnérable.
• Hébergement mutualisé ou infogéré : demandez à votre hébergeur s'il a appliqué les correctifs du 21 octobre. La plupart des grands hébergeurs l'ont fait en urgence.
• Conteneurs Docker : la version vient de l'image. Il faut retélécharger l'image et recréer le conteneur. Un simple redémarrage ne suffit pas. Les images officielles php:8.x et celles des grands projets (Nextcloud, Matomo…) ont été reconstruites le 21 octobre, mais certaines images tierces ne le sont pas encore.
• Signes d'alerte dans les journaux : erreurs Allowed memory size … exhausted sur des requêtes pourtant petites, plantages de processus PHP, envois de formulaires avec un très grand nombre de champs ou de fichiers.

Comment s'en protéger

1. La seule vraie solution : mettre à jour PHP

Passez à PHP 8.2.35, 8.3.36, 8.4.27 ou 8.5.12, ou à un paquet de votre distribution qui intègre les deux correctifs. Redémarrez ensuite tous les processus PHP : services PHP-FPM, Apache, conteneurs recréés. C'est la priorité absolue, en commençant par les serveurs en mod_php exposés sur Internet.

2. Si vous ne pouvez pas changer de version de PHP tout de suite

Application ancienne bloquée en PHP 7, image d'un éditeur pas encore mise à jour… Superposez les protections suivantes. Aucune n'est complète à elle seule, mais ensemble elles ferment l'essentiel des chemins connus.

a) Réglages PHP recommandés par l'équipe de PHP, à placer dans php.ini, le pool PHP-FPM ou la configuration Apache (php_admin_value), jamais dans .user.ini :

; Ferme le chemin confirmé de CVE-2026-109619
session.upload_progress.enabled = 0
; CVE-2026-109618 : l'épuisement de la mémoire PHP est le déclencheur.
; On retire la limite PHP et on borne la mémoire au niveau du conteneur ou du service.
memory_limit = -1
; Taille des formulaires : 8M si le site ne reçoit pas de fichiers, 32M sinon
post_max_size = 8M

Redémarrez tous les processus PHP après le changement. N'utilisez pas RLIMIT_AS ni RLIMIT_DATA pour limiter la mémoire : ils provoquent justement l'erreur exploitée. Bornez plutôt la mémoire par conteneur (mem_limit dans Docker) ou par service systemd (MemoryMax=).

b) Limiter les requêtes en amont de PHP, sur le serveur web ou le reverse proxy : taille réelle du corps, nombre de champs et d'en-têtes, en incluant les requêtes sans taille annoncée.

Nginx :

client_max_body_size 8m;          # 32m si le site reçoit des fichiers
client_body_buffer_size 128k;
large_client_header_buffers 4 8k;

Apache :

LimitRequestBody 8388608
LimitRequestFields 50
LimitRequestFieldSize 8190

Traefik : un middleware buffering avec maxRequestBodyBytes, qui lit le corps en entier avant de le transmettre (et coupe donc les envois par morceaux trop gros), et un middleware inFlightReq pour limiter les requêtes simultanées par adresse IP.

c) Un pare-feu applicatif (WAF) qui lit le contenu des requêtes. C'est la protection la plus efficace en attendant la mise à jour : il reconnaît la forme de l'attaque et la bloque avant PHP. Un patch virtuel bloque les formes connues, pas la faille elle-même — gardez-le jusqu'à ce que vos serveurs tournent en version corrigée.

Notre recommandation est CrowdSec, car une adresse qui déclenche la règle est bannie sur l'ensemble de vos serveurs, pas seulement sur le site visé. Les variantes ModSecurity, Nginx et Cloudflare sont données ensuite pour ceux qui ont déjà l'un de ces outils.

Avec CrowdSec AppSec. La règle, appsec-rules/vpatch-php2shell.yaml :

name: local/vpatch-php2shell
description: "php2shell (CVE-2026-109618 / CVE-2026-109619) - signatures du corps de requete"
seclang_rules:
  - 'SecRule ARGS_NAMES|FILES_NAMES "@rx (?i)^php_session_upload_progress$" "id:9264001,phase:2,deny,log,msg:''php2shell - champ upload progress''"'
  - 'SecRule ARGS_NAMES|FILES_NAMES "@rx (?:\[[^\]]*\]){6,}" "id:9264002,phase:2,deny,log,msg:''php2shell - nom de champ imbrique 6+ niveaux''"'
  - 'SecRule &FILES_NAMES "@gt 100" "id:9264003,phase:2,deny,log,msg:''php2shell - plus de 100 fichiers''"'
  - 'SecRule &ARGS_NAMES "@gt 2000" "id:9264004,phase:2,deny,log,msg:''php2shell - plus de 2000 champs''"'
labels:
  type: exploit
  service: http
  behavior: "http:exploit"
  label: "php2shell - PHP RCE par epuisement memoire"
  classification: [cve.CVE-2026-109618, cve.CVE-2026-109619, attack.T1190]

On l'active dans appsec-configs/ (avec la règle officielle du hub, cscli appsec-rules install crowdsecurity/vpatch-CVE-2026-109618) :

name: local/appsec-vpatch
default_remediation: ban      # l'IP qui déclenche la règle est bannie
inband_rules:
  - crowdsecurity/base-config
  - crowdsecurity/vpatch-*
  - local/vpatch-php2shell

Puis on branche le point d'écoute AppSec (crowdsec:7422) sur le reverse proxy (plugin Traefik, bouncer Nginx ou Apache) et on recharge CrowdSec. Vérifiez les seuils avec vos applications : un formulaire légitime très complexe pourrait les atteindre.

Avec ModSecurity (Apache ou Nginx) — même langage SecLang, dans un fichier chargé par votre configuration ModSecurity :

SecRequestBodyAccess On
SecRule ARGS_NAMES|FILES_NAMES "@rx (?i)^php_session_upload_progress$" "id:9264001,phase:2,deny,status:403,log,msg:'php2shell - upload progress'"
SecRule ARGS_NAMES|FILES_NAMES "@rx (?:\[[^\]]*\]){6,}" "id:9264002,phase:2,deny,status:403,log,msg:'php2shell - champ imbrique'"
SecRule &FILES_NAMES "@gt 100" "id:9264003,phase:2,deny,status:403,log,msg:'php2shell - trop de fichiers'"
SecRule &ARGS_NAMES "@gt 2000" "id:9264004,phase:2,deny,status:403,log,msg:'php2shell - trop de champs'"

Nginx seul, sans module WAF, ne sait pas lire les noms des champs et ne peut donc pas reconnaître la signature. Il peut seulement resserrer ce qui atteint PHP (client_max_body_size 8m;, large_client_header_buffers 4 8k;) et refuser les envois « par morceaux » sans taille annoncée. Pour une vraie inspection, utilisez le module ModSecurity pour Nginx ou mettez CrowdSec AppSec devant.

Avec Cloudflare, les règles gérées couvrent php2shell depuis le 21 octobre : vérifiez que le WAF est activé. Vous pouvez ajouter une règle personnalisée (action Block) :

(http.request.method eq "POST" and any(http.request.body.form.names[*] contains "PHP_SESSION_UPLOAD_PROGRESS"))

L'inspection du corps dépend de votre offre (généralement Pro et au-delà) ; sur toutes les offres, laissez surtout les Managed Rules actives.

d) Le pare-feu réseau (iptables / nftables) ne voit pas le contenu des requêtes HTTPS et ne peut donc pas reconnaître l'attaque. Il reste utile pour ralentir les attaquants qui enchaînent les tentatives :

# Au plus 20 nouvelles connexions HTTPS par seconde et par IP (rafale de 40), au-delà on rejette
iptables -A INPUT -p tcp --dport 443 --syn -m hashlimit --hashlimit-name https \
  --hashlimit-mode srcip --hashlimit-above 20/second --hashlimit-burst 40 -j DROP
# Au plus 50 connexions HTTPS simultanées par IP
iptables -A INPUT -p tcp --dport 443 --syn -m connlimit --connlimit-above 50 -j REJECT

Combinez-le avec une liste de blocage partagée (CrowdSec, AbuseIPDB…) pour écarter les adresses déjà repérées.

e) Surveiller et contenir

• Alertez sur les erreurs « Allowed memory size exhausted » et sur les plantages répétés de processus PHP.
• Faites tourner PHP sous un utilisateur sans droits, avec un système de fichiers en lecture seule là où c'est possible, pour limiter ce qu'un attaquant pourrait faire.
• Si un serveur exposé et vulnérable ne peut être ni corrigé ni protégé par un WAF, le mettre hors ligne temporairement est la recommandation de plusieurs agences (NSA, NCSC britannique).

3. Après la correction

Une machine vulnérable exposée depuis le 17 octobre a pu être visitée. Vérifiez qu'aucun fichier PHP inconnu n'est apparu dans les dossiers d'envoi de fichiers et de cache, qu'aucun compte administrateur n'a été ajouté, et qu'aucune tâche planifiée suspecte n'existe. Changez les mots de passe et les clés d'API stockés sur le serveur en cas de doute.

Ce que nous avons fait pour nos clients

Dès la publication, nous avons recensé chaque application PHP de notre infrastructure, avec sa version et son mode de fonctionnement. Nous avons ensuite :

• mis à jour toutes celles pour lesquelles une version corrigée existait ;
• pour les autres, appliqué les réglages provisoires recommandés et déployé un patch virtuel CrowdSec devant les sites concernés : les requêtes d'attaque sont bloquées et leur auteur banni automatiquement de tous nos serveurs ;
• contrôlé les journaux depuis le 17 octobre, à la recherche des signes décrits plus haut.

Si votre site ou votre application est hébergé chez nous, vous n'avez rien à faire. Si vous gérez vous-même un serveur PHP et souhaitez un diagnostic, contactez-nous.

Sources

• Avis de sécurité PHP du 21 octobre 2026 : php.net
• Calif.io : analyse technique de php2shell
• Rapid7, Tenable, watchTowr et Huntress : analyses et recommandations
• Help Net Security, Infosecurity Magazine : chronologie de la fuite