PHP2Shell (CVE-2026-109618 et CVE-2026-109619) : de quoi s'agit-il et comment corriger votre serveur

Le 21 octobre 2026, le projet PHP a publié en urgence des versions corrigeant deux failles critiques, CVE-2026-109618 et CVE-2026-109619, désormais connues sous le nom de PHP2Shell. Combinées, elles permettent à un attaquant d'exécuter du code sur un serveur à l'aide d'une seule requête HTTP forgée. L'attaquant n'a besoin ni d'identifiants, ni d'une extension vulnérable, ni d'une erreur de configuration. Si PHP répond aux requêtes web sur votre serveur, celui-ci reste exposé tant qu'il n'est pas mis à jour.

Des attaquants testaient la faille plusieurs jours avant la sortie du correctif, et l'exploitation massive a débuté quelques heures après sa publication. Selon les chercheurs en sécurité, entre 1,3 et 1,9 million d'hôtes accessibles depuis Internet étaient exposés. Ce guide explique en quoi consistent ces vulnérabilités, quelles versions sont corrigées, comment mettre à jour un serveur privé étape par étape et comment vérifier si quelqu'un s'y est introduit avant vous.

À retenir

PHP2Shell désigne deux bugs PHP critiques (CVSS 9.2) qui permettent l'exécution de code à distance sans authentification, avec une seule requête HTTP.
Toutes les versions de PHP à partir de la 5.4 sont concernées dès lors qu'elles servent du trafic web : mod_php, PHP-FPM, CGI, FrankenPHP et LiteSpeed.
Les versions corrigées sont 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Redémarrez tous les workers PHP après la mise à jour.
Tous les serveurs WebGee cPanel et WordPress infogéré sont déjà corrigés ; les clients n'ont rien à faire.
L'exploitation a commencé avant la sortie du correctif : vérifiez vos journaux et vos fichiers à la recherche de signes de compromission, même après la mise à jour.

Clients WebGee : vous êtes déjà protégés Nos ingénieurs ont mis à jour chaque serveur WebGee cPanel mutualisé et revendeur ainsi que chaque serveur d'hébergement WordPress infogéré vers les versions corrigées de PHP, puis ont redémarré tous les workers PHP. Vous n'avez rien à faire. Ce guide s'adresse aux serveurs que vous gérez vous-même, comme un VPS, un serveur dédié ou un serveur cloud avec accès root.

Qu'est-ce que PHP2Shell ?

PHP2Shell désigne deux bugs de sécurité mémoire situés dans le traitement des requêtes au cœur de PHP. Tous deux se trouvent dans du code exécuté avant que votre application (WordPress, Laravel, Magento ou toute autre) ne reçoive la requête. C'est pourquoi maintenir votre CMS et vos extensions à jour ne vous protège pas dans ce cas.

CVE-2026-109618 : corruption liée à un manque de mémoire lors de l'analyse des requêtes

Lorsque PHP analyse un corps multipart/form-data (le format utilisé par les formulaires et les envois de fichiers), un manque de mémoire en cours de traitement laisse des structures internes à moitié initialisées. Le code de nettoyage de PHP considère ensuite cet état défectueux comme valide. Une requête forgée peut provoquer cette situation, même sur des serveurs dotés de limites de mémoire normales.

CVE-2026-109619 : état global obsolète et use-after-free

PHP gère les erreurs fatales avec longjmp(), qui sort du code défaillant sans le dérouler. Après l'erreur mémoire décrite ci-dessus, l'état global propre à la requête peut continuer de pointer vers une zone mémoire déjà libérée. La requête suivante traitée par le même worker PHP peut alors utiliser cette mémoire. Les chercheurs ont confirmé à la fois une fuite de mémoire et une exécution complète de code à distance.

Ensemble, ces deux bugs transforment une simple requête POST malformée en un shell exécuté sous l'utilisateur de votre serveur web (www-data, apache ou nobody). À partir de là, un attaquant peut lire votre wp-config.php et vos identifiants de base de données, installer des portes dérobées, envoyer du spam ou progresser plus loin dans votre réseau.

Schéma de la chaîne d'attaque PHP2Shell : une requête multipart forgée épuise la mémoire, laisse un état corrompu dans le worker PHP et aboutit à un shell distant — Une seule requête non authentifiée suffit. La faille se déclenche avant l'exécution de tout code applicatif.

Quelle est sa gravité ?

Gravité : les deux CVE sont notées CVSS v4.0 9.2 (critique). Les premiers bulletins mentionnaient un score de 10.0.
Authentification : aucune n'est requise. La faille est accessible sur n'importe quelle URL traitée par PHP.
Exploitation : confirmée dans la nature, et du code de preuve de concept public circule.
Applications : l'exécution de code avant authentification a été démontrée sur WordPress, Drupal, Joomla et Magento.
Ancienneté : le code vulnérable remonte à PHP 5.4.0, si bien que les serveurs très anciens sont eux aussi concernés.

Chronologie de PHP2Shell en octobre 2026 : première tentative d'exploitation le 17 octobre, fuite des CVE le 20 octobre, versions corrigées le 21 octobre, exploitation massive du 21 au 22 octobre, rétroportages CloudLinux le 22 octobre — Du premier signalement sur un honeypot à l'exploitation massive en moins d'une semaine.

Qui est concerné ?

Toutes les installations PHP qui servent du trafic web, quelle que soit l'API serveur utilisée :

Apache avec mod_php : le risque le plus élevé, car l'analyse vulnérable s'exécute à l'intérieur même du worker Apache.
PHP-FPM derrière nginx, Apache ou Caddy.
php-cgi, FrankenPHP et LiteSpeed (LSAPI).

PHP utilisé uniquement en ligne de commande (tâches cron, workers qui n'analysent jamais de corps HTTP) n'est pas directement accessible, mais le même binaire est généralement installé pour le web. Mettez tout à jour.

Versions de PHP corrigées

Passez au minimum à la version indiquée ci-dessous pour votre branche :

PHP 8.5 : 8.5.12 ou ultérieure
PHP 8.4 : 8.4.27 ou ultérieure
PHP 8.3 : 8.3.36 ou ultérieure
PHP 8.2 : 8.2.35 ou ultérieure
PHP 7.4 à 8.1 : aucune version officielle. Les correctifs existent uniquement sous forme de rétroportages dans le code source et via des fournisseurs comme CloudLinux (alt-php) et certaines distributions Linux.
PHP 5.4 à 7.3 : en fin de vie, sans correctif. Mettez à niveau ou retirez le site de l'internet public.

Tableau des versions de PHP corrigées : 8.5.12, 8.4.27, 8.3.36 et 8.2.35 ; 7.4 à 8.1 uniquement via des rétroportages ; 5.4 à 7.3 sans correctif — Si votre branche n'est pas en vert, planifiez dès maintenant une mise à niveau.

Étape 1 : vérifier la version de PHP de votre serveur

Vérifiez à la fois le binaire en ligne de commande et la version réellement utilisée par votre serveur web. Elles sont souvent différentes.

# Command-line PHP
php -v

# Every PHP binary installed on the server
ls /usr/bin/php* /usr/sbin/php-fpm* /opt/cpanel/ea-php*/root/usr/bin/php /opt/alt/php*/usr/bin/php 2>/dev/null

# The version your web server serves: drop a temporary file, fetch it, then delete it
echo '<?php echo PHP_VERSION;' | sudo tee /var/www/html/v.php >/dev/null
curl -s https://your-domain.com/v.php; echo
sudo rm /var/www/html/v.php

Ne laissez pas traîner de fichiers phpinfo() Si vous utilisez un fichier phpinfo() ou un fichier de version pour cette vérification, supprimez-le immédiatement après. Les attaquants recherchent ces fichiers pour identifier les serveurs vulnérables.

Étape 2 : mettre à jour PHP sur votre serveur

Choisissez la section correspondant à votre plateforme. Après la mise à jour, vous devez redémarrer tous les processus PHP. Les anciens workers continuent d'exécuter le code vulnérable tant qu'ils ne sont pas remplacés.

Ubuntu et Debian

sudo apt update
sudo apt install --only-upgrade 'php*-common' 'php*-cli' 'php*-fpm' 'libapache2-mod-php*'

# Restart PHP-FPM (repeat for each installed version)
sudo systemctl restart php8.3-fpm

# Using mod_php? Restart Apache instead
sudo systemctl restart apache2

# Confirm
php -v

Si vous installez PHP depuis le PPA ondrej/php ou un dépôt tiers similaire, assurez-vous que ce dépôt a bien publié les versions corrigées avant de considérer votre serveur comme à jour.

AlmaLinux, Rocky Linux et RHEL

sudo dnf clean all
sudo dnf upgrade 'php*'

# Restart PHP-FPM and the web server
sudo systemctl restart php-fpm
sudo systemctl restart httpd   # or nginx

php -v

Serveurs cPanel et WHM (EasyApache ea-php)

cPanel fournit PHP sous forme de paquets ea-php. Mettez-les tous à jour en une seule fois :

# CloudLinux / CentOS 7
yum clean all && yum update "ea-php*"

# AlmaLinux / CloudLinux 8, 9 and 10
dnf clean all && dnf upgrade "ea-php*"

# Restart PHP-FPM for all accounts, then Apache or LiteSpeed
/scripts/restartsrv_apache_php_fpm
/scripts/restartsrv_httpd

# Check each installed version
for p in /opt/cpanel/ea-php*/root/usr/bin/php; do echo -n "$p: "; $p -r 'echo PHP_VERSION, PHP_EOL;'; done

CloudLinux alt-php (PHP Selector)

CloudLinux rétroporte le correctif dans toutes les branches alt-php, y compris les versions en fin de vie comme 5.6 et 7.4. Le numéro de version ne change pas : consultez donc le journal des modifications du paquet plutôt que php -v :

yum clean all && yum update 'alt-php*' 'ea-php*' -y

# Confirm the fix is in the installed package (example: alt-php 7.4)
rpm -q --changelog alt-php74 | grep -m1 -i 'CVE-2026-109618'

Docker et conteneurs

Les conteneurs ne se mettent pas à jour tout seuls. Récupérez l'image officielle corrigée, reconstruisez et redéployez :

# Pin to a fixed release (or newer)
FROM php:8.3.36-fpm

# ...your existing build steps

docker pull php:8.3.36-fpm
docker compose build --pull
docker compose up -d

# Confirm inside the running container
docker compose exec app php -v

Étape 3 : mesures provisoires si vous ne pouvez pas mettre à jour aujourd'hui

Ces réglages réduisent l'exposition mais ne corrigent pas la faille. Utilisez-les uniquement pour gagner du temps en attendant de planifier la mise à niveau, par exemple sur PHP 7.3 ou antérieur, pour lesquels aucun correctif n'existe.

Renforcer php.ini

L'exploit repose sur le dépassement de la limite de mémoire propre à PHP pendant l'analyse. Désactiver cette limite au niveau de PHP (et imposer une limite stricte ailleurs, voir ci-dessous) neutralise le principal déclencheur. Le suivi de progression des envois de fichiers constitue un autre point d'entrée vers le code vulnérable.

; /etc/php/8.3/fpm/conf.d/99-php2shell.ini  (adjust the path to your version)
; Interim mitigation for CVE-2026-109618 / CVE-2026-109619

memory_limit = -1
session.upload_progress.enabled = 0
post_max_size = 1M

; PHP 8.5 only
fatal_error_backtraces = 0

Des applications comme WordPress augmentent elles-mêmes memory_limit à l'exécution. Verrouillez les valeurs dans le pool PHP-FPM pour que le code ne puisse pas les modifier :

; /etc/php/8.3/fpm/pool.d/www.conf
php_admin_value[memory_limit] = -1
php_admin_flag[session.upload_progress.enabled] = off

Associez toujours memory_limit = -1 à une limite stricte Sans limite de mémoire PHP, un seul script incontrôlé peut consommer toute la RAM du serveur. Plafonnez plutôt la mémoire au niveau du processus, avec un MemoryMax systemd pour le service PHP-FPM ou une limite mémoire de conteneur, afin que ce soit le noyau, et non PHP, qui arrête un worker incontrôlé.

# Cap PHP-FPM memory with systemd
sudo systemctl edit php8.3-fpm
#   [Service]
#   MemoryMax=2G

# Or, for Docker:
docker update --memory 2g --memory-swap 2g <container>

Limiter la taille du corps des requêtes au niveau du serveur web

Rejetez les corps trop volumineux avant même qu'ils n'atteignent PHP. Cela bloque les charges utiles volumineuses forgées utilisées dans les exploits publics, mais aussi les envois légitimes de gros fichiers : n'augmentez donc la limite que sur les chemins qui en ont besoin.

# nginx: inside http {} or server {}
client_max_body_size 1m;

# Allow bigger uploads only where needed, e.g. the WordPress media uploader
location = /wp-admin/async-upload.php {
    client_max_body_size 64m;
    include fastcgi_params;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}

# Apache: in the vhost or .htaccess (bytes)
LimitRequestBody 1048576

Redémarrez ensuite tous les workers PHP afin qu'aucun ne conserve un état corrompu :

sudo systemctl restart php8.3-fpm
sudo systemctl reload nginx   # or: sudo systemctl restart apache2

Si votre site est derrière Cloudflare, activez ses règles WAF gérées pour cette vulnérabilité ; Cloudflare a rendu cette protection disponible y compris sur l'offre gratuite. Considérez toutefois le WAF comme une couche supplémentaire, et non comme un substitut à la mise à jour. Le CERT-EU recommande également d'isoler les applications PHP exposées sur Internet qui ne peuvent pas être corrigées immédiatement.

Étape 4 : vérifier si vous avez déjà été compromis

L'exploitation a commencé avant que la plupart des administrateurs aient pu mettre à jour : la mise à jour ne marque donc pas la fin du travail. Recherchez les signes suivants.

Erreurs de mémoire insuffisante à la ligne 0

Les tentatives, qu'elles aient échoué ou réussi, laissent une erreur fatale de mémoire sans fichier ni ligne réels, généralement à côté d'une requête POST anormalement volumineuse :

sudo grep -R "Allowed memory size of .* exhausted .* in Unknown on line 0" \
  /var/log/php*-fpm.log /var/log/apache2/error.log /var/log/httpd/error_log \
  /var/log/nginx/error.log 2>/dev/null | tail -n 50

Plantages de workers

# Apache children dying with segfaults
sudo grep -R "AH00052: child pid .* exit signal Segmentation fault" /var/log/apache2/ /var/log/httpd/ 2>/dev/null

# PHP-FPM workers killed by signals
sudo grep -R "exited on signal" /var/log/php*-fpm.log 2>/dev/null

Shells lancés par l'utilisateur du serveur web

# A shell running under apache, www-data or php-fpm is a red flag
ps aux | grep -E "(apache|www-data|php-fpm|nobody)" | grep -E "\b(sh|bash|dash)\b" | grep -v grep

# Unexpected outbound connections from the web user
sudo ss -tunp | grep -E "php|apache|httpd|nginx"

Portes dérobées et persistance

# PHP files changed in the last 7 days
sudo find /var/www -type f -name "*.php" -mtime -7 -printf "%TY-%Tm-%Td %TH:%TM  %p\n" | sort -r | head -n 50

# PHP files in upload folders (they should never be there)
sudo find /var/www -path "*uploads*" -name "*.php"

# Cron jobs added for the web user
sudo crontab -u www-data -l 2>/dev/null; sudo crontab -u apache -l 2>/dev/null

Dans vos journaux d'accès, recherchez des requêtes POST contenant des noms de champs de formulaire gigantesques (plus de 1 MB), des octets binaires ou nuls dans le corps, ou une structure du type =[binary]&a=1&[long field][x]=1.

Un exploit réussi ne provoque pas toujours de plantage : des journaux propres ne prouvent donc pas que vous êtes en sécurité. Si vous constatez l'un de ces signes, partez du principe que le serveur est compromis :

mettez le site hors ligne ou en mode maintenance ;
renouvelez les mots de passe de base de données, les clés d'API et les clés de salage WordPress ;
restaurez une sauvegarde effectuée avant le 17 octobre 2026 ;
puis appliquez le correctif avant de remettre le site en ligne.

Liste de contrôle de réponse à PHP2Shell

Recenser toutes les versions de PHP du serveur, en ligne de commande et web
Passer à 8.2.35, 8.3.36, 8.4.27, 8.5.12 ou à un rétroportage fournisseur
Redémarrer PHP-FPM, Apache ou LiteSpeed pour qu'aucun ancien worker ne subsiste
Reconstruire et redéployer les conteneurs à partir d'images corrigées
Appliquer les réglages provisoires de php.ini et les limites de taille des requêtes partout où la mise à jour n'est pas encore possible
Rechercher dans les journaux les erreurs de mémoire à la ligne 0 et les segfaults
Vérifier la présence de shells lancés par l'utilisateur web, de nouveaux fichiers PHP et de nouvelles tâches cron
Renouveler les identifiants au moindre élément suspect

Pourquoi cela se reproduit sans cesse, et comment l'hébergement infogéré vous aide

PHP2Shell est passé du premier signalement sur un honeypot à l'exploitation massive en moins d'une semaine, et l'essentiel s'est produit avant même l'existence d'un correctif. Pour une entreprise qui gère son propre serveur, se défendre face à cela suppose que quelqu'un surveille les flux de sécurité en permanence, teste les mises à jour et les déploie sur chaque version de PHP et chaque worker dès leur publication. Bien souvent, cela doit se faire à 2 heures du matin, un week-end, alors que des exploits publics sont déjà utilisés.

C'est précisément ce que notre équipe fait pour les clients WebGee. Pour PHP2Shell, nos ingénieurs ont :

appliqué les versions corrigées de PHP sur tous les serveurs cPanel mutualisés et revendeurs ;
mis à jour tous les serveurs d'hébergement WordPress infogéré vers la dernière version corrigée de PHP ;
redémarré chaque worker PHP afin qu'aucun processus vulnérable ne reste actif ;
fait tout cela sans aucune intervention de la part des clients.

En plus des mises à jour, l'hébergement WebGee comprend une analyse antimalware au niveau du serveur, un pare-feu applicatif web et des sauvegardes quotidiennes. Si une attaque parvient malgré tout à passer quelque part, vous disposez d'un point de restauration sain.

Si vous faites tourner WordPress, WooCommerce ou une autre application PHP sur un serveur que vous devez mettre à jour vous-même, pensez à nous confier cette tâche. Nous migrerons votre site gratuitement, sans aucune interruption de service.

Laissez-nous gérer le prochain PHP2Shell à votre placeHébergement WordPress infogéré et cPanel, mis à jour par nos ingénieurs avant même que vous n'entendiez parler de la prochaine vulnérabilité. Migration gratuite incluse.

Passer gratuitement chez WebGee

Vous préférez garder votre propre serveur ?

Si vous avez besoin d'un accès root, un serveur cloud WebGee vous offre un contrôle total, et nos ingénieurs support peuvent vous aider à le mettre à jour, à le sécuriser et à le surveiller. Pour les sites qui doivent simplement rester rapides et sûrs, l'hébergement WordPress infogéré et l'hébergement cloud cPanel maintiennent PHP à jour pour vous. Vous hésitez ? Parlez-en à notre équipe.

Questions fréquentes

Mon site est hébergé chez WebGee. Dois-je faire quelque chose ?

Non. Nous avons mis à jour tous les serveurs WebGee cPanel mutualisés et revendeurs ainsi que tous les serveurs d'hébergement WordPress infogéré vers les versions corrigées de PHP, puis redémarré chaque worker PHP. Si vous gérez votre propre serveur cloud ou dédié avec un accès root, suivez les étapes de ce guide ou contactez notre équipe support pour obtenir de l'aide.

Mettre à jour WordPress ou mes extensions corrige-t-il PHP2Shell ?

Non. Les vulnérabilités se trouvent dans PHP lui-même et se déclenchent avant l'exécution de WordPress ou de tout autre code applicatif. Vous devez mettre à jour les paquets PHP du serveur et redémarrer PHP.

Quelles versions de PHP corrigent CVE-2026-109618 et CVE-2026-109619 ?

PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12, ou toute version ultérieure. Pour PHP 7.4 à 8.1, il n'existe que des rétroportages dans le code source et des builds fournisseurs comme CloudLinux alt-php. PHP 5.4 à 7.3 ne disposent d'aucun correctif.

J'utilise une ancienne version de PHP sans correctif. Que faire ?

Passez à une branche de PHP maintenue dès que possible. En attendant, appliquez les réglages provisoires de php.ini et les limites de taille des requêtes décrits dans ce guide, placez le site derrière un WAF ou retirez-le de l'internet public. CloudLinux alt-php inclut également des correctifs rétroportés pour de nombreuses versions en fin de vie.

Un pare-feu applicatif web suffit-il ?

Non. Un WAF peut bloquer les schémas d'exploitation connus et vous faire gagner du temps, mais les attaquants modifient leurs charges utiles. Mettre à jour PHP est la seule véritable solution.

Comment savoir si mon serveur a été piraté ?

Recherchez des erreurs « Allowed memory size ... in Unknown on line 0 », des workers qui plantent en segfault, des shells exécutés par l'utilisateur du serveur web, des fichiers PHP modifiés récemment, des fichiers PHP dans les dossiers d'upload et de nouvelles tâches cron. Une attaque réussie peut ne provoquer aucun plantage : en cas de doute, renouvelez vos identifiants et restaurez une sauvegarde antérieure au 17 octobre 2026.