PHP2Shell
le guide complet

01En bref

PHP2Shell, ce sont deux failles critiques corrigées en urgence le 21 octobre 2026, et une troisième annoncée deux jours plus tard sans correctif.

02Chronologie

Neuf jours entre la première tentative et l'inscription au catalogue des failles activement exploitées de la CISA.

1. 17 octobrePremière tentative d'exploitation observée par Amazon sur ses pièges, quatre jours avant les correctifs.
2. 20 octobreFuite des détails et d'un premier code d'attaque ; PHP annonce les correctifs.
3. 21 octobreCorrectifs d'urgence de PHP (8.2.35, 8.3.36, 8.4.27, 8.5.12). Alertes du CERT-FR et de la CISA. En France, à la demande de l'ANSSI, le ministère de l'Intérieur met ses sites en maintenance préventive. Un botnet de type Mirai (« Potassium ») tente déjà de s'en servir.
4. 22 – 23 octobreOutils d'attaque industrialisés, millions de tentatives bloquées par les grands filtres web. Troisième faille annoncée (CVE-2026-115560), sans correctif. La CISA publie une règle de détection Sigma.
5. 24 octobrePremières prises de contrôle confirmées, sur des serveurs leurres (35 shells sur 3 pièges). Repérage discret de 216 cibles attribué, avec une confiance modérée, à un acteur lié à la Corée du Nord (CYFIRMA).
6. 25 octobrePalo Alto Unit 42 retire son rapport du 23 sur une administration européenne compromise : le lien avec PHP2Shell n'est pas établi.
7. 26 octobreLa CISA inscrit les deux failles à son catalogue KEV des failles activement exploitées. L'exploitation réussie est confirmée publiquement.

03Comprendre la faille

La faille se déclenche dans le moteur PHP, pendant la lecture de la requête, avant même que le code du site ne s'exécute.

Deux failles, deux mécanismes

La troisième faille : CVE-2026-115560

Annoncée le 23 octobre, elle n'a pas de correctif. PHP la décrit comme exploitable dans une combinaison inhabituelle de configuration et de code applicatif, et n'a pas publié de version d'urgence. PHP comme Red Hat indiquent que désactiver session.upload_progress la neutralise.

Ce qui protège, et ce qui ne protège pas

04Qui est touché

Toutes les versions de PHP depuis la 5.4 de façon certaine, jusqu'à la 8.5 non corrigée. Ce qui change d'une version à l'autre, c'est l'existence d'un correctif.

Red Hat et dérivées (Rocky, Alma, Oracle)

Hébergeurs, panneaux et clouds

CMS : que peut-on migrer ?

05État de l'exploitation

L'exploitation fonctionne, mais reste ciblée : à la date de ce guide, aucune victime réelle n'est confirmée publiquement et aucune vague de masse n'est observée.

Ce que montrent les capteurs CrowdSec (21 au 25 octobre)

Les signaux qui feraient basculer vers l'exploitation de masse

1. Un exploit public fiable sur un PHP standardC'est le déclencheur principal. Avec React2Shell, le nombre de sources attaquantes a été multiplié par 27 entre le deuxième et le sixième jour.
2. Une hausse nette des nouvelles sourcesAu-delà du plateau d'environ 130 par jour.
3. Plus d'attaquants insistantsUne vraie tentative se répète contre la même cible.
4. La faille mémoire qui rattrape la voie de sessionLe signe d'outils plus aboutis.

06Que faire maintenant

Un arbre de décision selon votre version de PHP, puis quatre actions valables pour tout le monde.

1. InventorierLister tous les serveurs qui exécutent PHP, y compris les environnements de test exposés, les sites oubliés et les serveurs « considérés comme fermés ». Ce sont eux qui tombent.
2. Corriger, puis redémarrerUn binaire corrigé ne protège rien tant que les processus PHP-FPM ou Apache tournent encore avec l'ancien. Vérifier ensuite la version réellement servie.
3. Durcir et filtrer en attendantRéglage du php.ini, règles de pare-feu applicatif (patch virtuel), interdiction des connexions sortantes du serveur web.
4. Isoler ce qui ne peut pas être corrigéLe blocage depuis l'extérieur est une mesure d'attente : chaque application coupée doit être corrigée et rouverte au plus vite.
5. Chercher une compromissionSur tout serveur exposé et non corrigé depuis le 17 octobre (voir Détecter une intrusion).
6. Renouveler les secrets« Aucune trace trouvée » ne veut pas dire « non compromis » : l'une des failles permet de lire la mémoire. Mots de passe de base de données, clés d'API et clés applicatives des serveurs exposés sont à changer.

07Vérifier son correctif

Trois questions : quelle version tourne vraiment, le paquet installé est-il corrigé, et a-t-on redémarré ?

Red Hat, Rocky, Alma

php -v                                   # version de la ligne de commande
rpm -qa 'php*' | sort                    # paquets installés (y compris collections rh-php / remi)
rpm -q --changelog php php8.4 2>/dev/null | grep -iE '109618|109619' | head   # nom du paquet selon le flux
dnf updateinfo list --all --cve CVE-2026-109618  # RHEL 8+ : avis installé ou à installer
systemctl restart php-fpm                # indispensable après la mise à jour
# avec mod_php (sans PHP-FPM) : systemctl restart httpd

Debian, Ubuntu

php -v
dpkg -l 'php*' | awk '/^ii/{print $2, $3}'
zcat /usr/share/doc/php*-common/changelog.Debian.gz 2>/dev/null | grep -iE '109618|109619' | head
systemctl restart 'php*-fpm.service'     # avec mod_php : systemctl restart apache2

# binaire réel de chaque pool PHP-FPM et date de démarrage du processus
for p in $(pgrep -f 'php-fpm: master'); do
  echo "PID $p : $(readlink /proc/$p/exe)  démarré le $(ps -o lstart= -p $p)"
done
# un processus démarré AVANT la mise à jour tourne avec l'ancien binaire

08Durcir PHP en attendant

Une ligne coupe la voie la plus tentée et la troisième faille. Pour la 109618, aucun réglage ne protège complètement selon PHP : on réduit seulement la surface.

; PHP2Shell — mesures d'attente (ne remplacent pas la mise à jour)
session.upload_progress.enabled = 0   ; 109619 et troisième faille (115560)
post_max_size = 8M                    ; 109618 : limiter la taille des envois au strict nécessaire
session.use_strict_mode = 1           ; refuse les identifiants de session inventés
session.serialize_handler = php       ; le MÊME réglage partout, aucun mélange par dossier

Avec PHP-FPM, imposer aussi le réglage dans chaque pool, pour qu'aucun site ne puisse le réactiver : php_admin_flag[session.upload_progress.enabled] = off. Red Hat recommande en complément de réduire post_max_size et de garder un memory_limit borné (jamais -1) : ces réglages limitent la 109618 sans la corriger. Adapter post_max_size si vos sites reçoivent des fichiers plus lourds.

Le suivi de progression des envois n'est utilisé que par de rares interfaces d'envoi de fichiers avec barre de progression côté serveur. Pour la plupart des sites, le désactiver n'a aucun effet visible. Redémarrer PHP-FPM ou Apache ensuite.

# réglages de session modifiés localement dans les sites
grep -rIE 'serialize_handler|upload_progress' --include=.user.ini --include=.htaccess /var/www 2>/dev/null
grep -rIE 'serialize_handler|upload_progress' /etc/php-fpm.d /etc/php/*/fpm/pool.d 2>/dev/null

Filtrer avec un pare-feu applicatif

Plusieurs éditeurs ont publié des règles dédiées : CrowdSec (crowdsecurity/vpatch-CVE-2026-109618 et -109619, en ligne avant même les correctifs), Cloudflare, Check Point, Sophos, Fortinet, ainsi que des règles ModSecurity et Suricata partagées dans des dépôts communautaires. Un filtre ne voit le contenu d'une requête HTTPS que là où elle est déchiffrée : sur le reverse proxy, ou avec une inspection HTTPS.

09Détecter une intrusion

Quatre endroits à regarder : les journaux, les fichiers, les processus et le réseau.

1. Journaux web et PHP

# outils connus : user-agents et URL (seuls éléments présents dans les journaux d'accès)
zgrep -hiE 'php2shell|php-session-startup-rce-poc|sess_p2sopchain' \
  /var/log/httpd/*access* /var/log/nginx/*access* /var/log/apache2/*access* 2>/dev/null | tail -50

# rafales d'erreurs mémoire caractéristiques de la faille 109618
zgrep -hE 'Allowed memory size.*rfc1867|Unknown on line 0|Failed to decode session object' \
  /var/log/php-fpm/* /var/log/php*-fpm.log /var/log/httpd/*error* /var/log/apache2/*error* /var/log/nginx/*error* 2>/dev/null | tail -50

# plantages de processus PHP (segfault) dans le journal noyau (journal persistant requis)
journalctl _TRANSPORT=kernel --since '2026-10-17' | grep -iE '(php|httpd|apache2).*segfault|segfault.*(php|httpd|apache2)' | tail

2. Fichiers déposés

# PHP récent dans les dossiers d'envoi (emplacement typique d'un webshell)
find /var/www -xdev -type f -name '*.ph*' -newermt 2026-10-17 \
  \( -path '*/upload*' -o -path '*/images/*' -o -path '*/files/*' -o -path '*/cache/*' \) -ls

# images contenant du code PHP
grep -rlaE '<\?php|eval\(' --include='*.jpg' --include='*.jpeg' --include='*.png' --include='*.gif' --include='*.webp' /var/www 2>/dev/null

# fichiers de preuve laissés par les outils d'attaque et charges connues
find /tmp /var/tmp /dev/shm -xdev \( -name x1 -o -name p1 -o -name nfs -o -name mountpoint -o -name cCmono \) -ls
ls -la /var/www/p1 /var/www/html/p1 2>/dev/null   # tentatives d'écriture observées sur les leurres

# sessions PHP contenant du code
grep -rlE '<\?php|system\(|base64_decode' /var/lib/php/session* /tmp/sess_* /tmp/systemd-private-*/tmp/sess_* 2>/dev/null

3. Processus

# shells et outils réseau lancés par le compte du serveur web
ps -eo user,pid,ppid,lstart,cmd --forest | grep -E '^(apache|nginx|www-data)' \
  | grep -E '(^|[ /])(sh|bash|dash|curl|wget|python[0-9.]*|perl|nc|ncat|socat)( |$)'

# programmes exécutés depuis /tmp ou dont le fichier a été supprimé
ls -l /proc/[0-9]*/exe 2>/dev/null | grep -E '/tmp/|/dev/shm/|\(deleted\)'

4. Réseau

# connexions ouvertes par PHP ou Apache vers autre chose que les visiteurs (hors ports 80/443 locaux)
ss -tnp state established '( not sport = :80 and not sport = :443 )' | grep -E 'httpd|apache2|php-fpm'
# connexions vers les serveurs de commande du botnet Potassium
ss -tn dst 134.199.154.64 ; ss -tn dst 117.55.202.115

# /etc/audit/rules.d/php2shell.rules  (remplacer 48 par l'UID réel : id -u apache)
# (Debian : www-data = 33)
-a always,exit -F arch=b64 -S execve -F uid=48 -k php2shell_exec
-a always,exit -F arch=b32 -S execve -F uid=48 -k php2shell_exec
-a always,exit -F arch=b64 -S memfd_create -F uid=48 -k php2shell_memfd
# puis : augenrules --load ; recherche : ausearch -k php2shell_exec -i

10Indicateurs de compromission

Les indicateurs publiés par les chercheurs et éditeurs, triés par force du signal. Une connexion sortante vers l'infrastructure d'attaque vaut compromission ; une requête entrante d'un scanner, une simple tentative.

Télécharger la liste (.txt)   Télécharger avec sources (.csv)

Infrastructure d'attaque · signal fort

Domaines, empreintes et réseau

Marqueurs dans les requêtes et sur le système · signal moyen

11Questions fréquentes

12Sources

• CISA · alerte du 21 octobre et règle Sigma
• BleepingComputer · inscription au catalogue KEV
• BleepingComputer · exploitation réussie (26/10)
• SecurityWeek · des sondes aux shells
• Adel Karimi · rapport des serveurs leurres
• CrowdSec · pas encore d'exploitation de masse
• Palo Alto Unit 42 · rapport et rétractation du 25/10
• Sophos · code d'exploitation et indicateurs
• Arctic Wolf · analyse et indicateurs
• The Hacker News · des millions de tentatives
• isMalicious · indicateurs Amazon et Hunt.io
• Amazon · exploitation avant publication
• Cybersecurity News · outils d'exploitation publics
• Censys · avis et mesure d'exposition
• CERT-FR · alerte CERTFR-2026-ALE-014
• Red Hat · bulletin RHSB-2026-013 et avis RHSA associés
• PHP · avis de sécurité des 20, 21 et 23 octobre
• W3Techs, VirusTotal · mesures d'exposition
• Cloudflare · règles WAF
• ELLIO · observations et indicateurs
• Hunt.io · dossiers ouverts

Ce guide est mis à jour au fil des publications. Les informations datent du 27 octobre 2026 ; un indicateur ou un état de correctif peut avoir évolué depuis. Vérifiez toujours auprès de l'éditeur de votre distribution.