PHP2Shell : mettez à jour dès maintenant vers la version PHP corrigée

Le correctif pour PHP2Shell est disponible. Depuis le mercredi 21 octobre 2026, à 16 h 00, heure néerlandaise, les versions PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 sont accessibles. Elles colmatent deux failles critiques permettant à un attaquant d’exécuter du code sur votre serveur sans authentification. L’équipe PHP est claire : seule la mise à jour garantit votre sécurité, et elle doit être effectuée immédiatement.

PHP2Shell: is jullie website al gepatcht?

Les détails circulaient déjà publiquement depuis un jour et la société de sécurité Sansec prévoyait des attaques massives dans les quinze minutes suivant la sortie. Chaque heure où un serveur reste non corrigé compte.

Dans cet article, vous découvrirez précisément la nature de la faille, vers quelle version migrer, comment effectuer la mise à jour en toute sécurité, que faire si la mise à jour est impossible aujourd’hui et comment vérifier si une intrusion a déjà eu lieu.

Mis à jour le 21 octobre 2026 après la sortie officielle de PHP.

Qu’est-ce que PHP2Shell ?

PHP2Shell est le surnom donné à deux vulnérabilités de PHP lui-même, affichant toutes deux un score de 9,2 sur 10 (CVSS v4.0). Le nom provient d’un outil d’exploitation apparu dans une capture d’écran fuitée. PHP a désormais confirmé la situation :

CVE	Problème rencontré
CVE-2026-109618 — RCE via manque de mémoire	Si PHP vient à manquer de mémoire lors de la construction d’une requête, celle-ci peut être interrompue en cours de route. Lors du nettoyage, PHP traite ensuite ces données incomplètes comme étant valides.
CVE-2026-109619 — RCE via état résiduel	Les données internes d’une requête persistent après la libération de la mémoire. Une requête suivante dans le même worker peut utiliser ces données avant qu’elles ne soient correctement réinitialisées.

Qui est à risque ?

Selon PHP : toute installation PHP traitant des requêtes web. Cela concerne PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le risque est maximal avec mod_php : il a été démontré qu’une seule requête sans authentification lance l’attaque avant même l’exécution de la moindre ligne de code applicatif.

La faille se situe donc dans PHP, et non dans WordPress, Laravel, WooCommerce ou une extension. Mettre à jour votre CMS ne résoudra pas le problème, et un site sans formulaire de téléchargement est tout aussi vulnérable.

Vers quelle version devez-vous migrer ?

Votre version de PHP	Mettre à jour vers	Remarque
8.5	8.5.12	Sortie officielle de php.net
8.4	8.4.27	Sortie officielle de php.net
8.3	8.3.36	Sortie officielle de php.net
8.2	8.2.35	Version officielle ; la version 8.2 arrive en fin de vie le 31 décembre 2026, planifiez votre mise à niveau dès maintenant
8.1, 8.0, 7.4 et antérieures	Mise à niveau vers 8.2 ou supérieure	Aucune version de php.net. Certaines distributions et fournisseurs LTS proposent un backport ; PHP a également publié des correctifs sources minimaux pour 7.4, 8.0 et 8.1 pour ceux qui compilent eux-mêmes

Si vous utilisez des paquets d’une distribution Linux, vous n’avez pas besoin de vous fier à ce numéro de version. Les distributions ont reçu les correctifs à l’avance et les appliquent souvent à leur propre version (backport). Vous découvrirez ci-dessous comment vérifier cela.

Attention si vous obtenez PHP via le dépôt Remi maintenu par des bénévoles (rpms.remirepo.net) : celui-ci ne recevra pas de mises à jour aujourd’hui. PHP recommande de passer aux paquets de distribution ou de compiler soi-même.

Étape 1 : identifiez ce qui doit être corrigé

Mettez d’abord à jour vos serveurs accessibles depuis Internet, en priorité les serveurs mod_php. Avant de commencer, conservez une copie de vos journaux (logs) de serveur web et PHP à partir du 20 octobre : vous en aurez besoin à l’étape 3, et un déploiement ou une rotation des logs pourrait les effacer.

Sachez ce que vous devez corriger

N’oubliez pas les environnements de staging, les anciens sites de campagne, les outils d’administration comme phpMyAdmin et les conteneurs. Sur un serveur Debian ou Ubuntu :

# Welke PHP-versies zijn geïnstalleerd?
ls /etc/php

# Welke PHP-processen draaien er (FPM, Apache mod_php, LiteSpeed)?
ps -eo pid,comm,args | grep -E '[p]hp-fpm|[a]pache2|[h]ttpd|[l]sphp'

# Welke sites geven verzoeken door aan PHP?
sudo nginx -T | grep -E 'server_name|fastcgi_pass'

php -v en ligne de commande ne dit rien sur la version qui dessert votre site web : les pools FPM et Apache peuvent charger un PHP différent. Ne mettez jamais une page phpinfo() publique en ligne pour vérifier cela.

Étape 2 : comment mettre à jour PHP sur Linux

La méthode de mise à jour de PHP dépend de sa provenance. Vérifiez cela en premier, car c’est de là que viendra votre correctif :

Source	Reconnaissable par	D’où vient le correctif
Paquets Debian ou Ubuntu	`apt-cache policy` affiche `deb.debian.org`, `security.debian.org` ou `security.ubuntu.com`	Dépôt de sécurité de votre distribution (backport)
PPA / dépôt d’Ondřej Surý	`apt-cache policy` affiche `ppa.launchpadcontent.net/ondrej` ou `packages.sury.org`	Nouvelle version amont (upstream) dans le PPA
RHEL, AlmaLinux, Rocky	`dnf info php-fpm` affiche `appstream`	Red Hat / Alma / Rocky (backport)
Dépôt Remi	Noms de paquets comme `php83-php-fpm` ou dépôt `remi-*`	Pas de mise à jour aujourd’hui
Alpine	Noms de paquets comme `php83-fpm`	Dépôt Alpine
Panneau de contrôle (cPanel, DirectAdmin, Plesk)	PHP sous `/opt/cpanel/`, `/usr/local/php*` ou `/opt/plesk/php/`	Mécanisme de mise à jour du panneau

Avant de commencer, créez un instantané (snapshot) ou une sauvegarde du serveur. Une mise à jour de sécurité se déroule généralement sans problème, mais si vous avez beaucoup de retard, vous importerez également d’autres modifications.

Debian et Ubuntu

# 1. Pakketlijsten verversen
sudo apt update

# 2. Staat er een PHP-pakket op 'hold'? Dan wordt het stilletjes overgeslagen.
apt-mark showhold
# eventueel: sudo apt-mark unhold php8.3-fpm

# 3. Welke versie staat er en welke is beschikbaar? (doe dit per PHP-versie)
apt-cache policy php8.3-fpm

# 4. Alleen PHP bijwerken
sudo apt install --only-upgrade 'php8.3*'

# of gewoon alles bijwerken
sudo apt upgrade

Répétez les étapes 3 et 4 pour chaque version dans /etc/php, pas seulement pour la version indiquée par la commande php.

Vous utilisez les paquets de la distribution ? Dans ce cas, le numéro de version amont ne change souvent pas : Debian et Ubuntu appliquent le correctif à leur propre version. Le numéro de paquet et le journal des modifications (changelog) indiquent si le correctif est inclus :

dpkg -l | grep php8.3-fpm
zcat /usr/share/doc/php8.3-fpm/changelog.Debian.gz | grep -m3 -E 'CVE-2026-10961[89]'

Si vous n’obtenez aucun résultat, le correctif n’est pas encore arrivé. Consultez alors l’avis de sécurité de votre distribution (Debian, Ubuntu) et maintenez les mesures d’urgence jusqu’à ce que le paquet soit disponible.

Vous utilisez le PPA d’Ondřej Surý ? Dans ce cas, apt-cache policy doit afficher la nouvelle version amont après la mise à jour, par exemple 8.3.36. Le PPA ne construit que pour les versions Ubuntu supportées (22.04 et 24.04). Si vous tournez encore sous Ubuntu 20.04 ou antérieur, rien ne viendra par cette voie : planifiez une migration vers un nouveau serveur.

RHEL, AlmaLinux et Rocky Linux

# 1. Welke PHP-pakketten en welke bron?
dnf list installed 'php*'
dnf module list php        # welke PHP-stream staat aan (bijv. 8.2)?

# 2. Zijn er updates?
sudo dnf check-update 'php*'

# 3. Bijwerken
sudo dnf upgrade 'php*'

# 4. Zit de fix erin?
rpm -q --changelog php-fpm | grep -m3 -E 'CVE-2026-10961[89]'

Red Hat, AlmaLinux et Rocky effectuent également des backports : le numéro de version reste identique, mais le numéro de paquet (la release) augmente. Le changelog fait foi. Si le correctif n’y figure pas encore, suivez les alertes de sécurité de votre distribution et maintenez les mesures d’urgence.

Vous utilisez le dépôt Remi ? PHP avertit que rpms.remirepo.net n’a pas de mises à jour aujourd’hui. Vous pouvez alors :

appliquer les mesures d’urgence et surveiller les mises à jour Remi (sudo dnf check-update --enablerepo='remi*') ;
passer au flux PHP de votre distribution (dnf module reset php et dnf module enable php:8.2), à condition que votre application fonctionne avec cette version ;
ou compiler PHP vous-même (voir ci-dessous).

Alpine Linux

sudo apk update
sudo apk upgrade 'php83*'      # vervang 83 door jouw versie
php83 -v

Panneaux de contrôle

Sur les serveurs dotés d’un panneau de contrôle, PHP provient du panneau et non de votre distribution. Mettez-le à jour via le panneau :

cPanel/WHM (EasyApache) : sudo dnf upgrade 'ea-php*' (sur les anciens systèmes yum), ou via WHM → EasyApache. Mettez à jour chaque ea-phpXX installé.
DirectAdmin (CustomBuild) : da build update puis da build php.
Plesk : via Tools & Settings → Updates, mettre à jour les composants PHP.

Vérifiez ensuite par domaine quelle version de PHP est active et s’il s’agit de la version corrigée. Si vous êtes sur un hébergement mutualisé, vous ne pouvez pas le faire vous-même : demandez confirmation à votre hébergeur.

Compiler soi-même

S’il n’y a pas de paquet, par exemple avec Remi ou une installation sur mesure, vous pouvez construire PHP à partir des sources. Ne faites cela que si vous savez comment votre PHP actuel a été construit :

# Hoe is de huidige PHP gecompileerd?
php -i | grep 'Configure Command'

# Broncode van php.net halen (pas de versie aan)
wget https://www.php.net/distributions/php-8.3.36.tar.gz
tar xzf php-8.3.36.tar.gz && cd php-8.3.36

# Met dezelfde opties bouwen en installeren
./configure <opties van hierboven>
make -j"$(nproc)"
sudo make install

Vérifiez le téléchargement avec les signatures sur la page de téléchargement de php.net. Pour PHP 7.4, 8.0 et 8.1, l’équipe PHP a publié des correctifs sources séparés ; ils sont liés dans l’avis de sécurité.

Vérifiez quel PHP votre site utilise réellement

Après la mise à jour et le redémarrage (voir ci-dessous), vous voulez être certain que votre site utilise la version corrigée, et pas seulement la ligne de commande.

# Versie van de geïnstalleerde FPM-binary
php-fpm8.3 -v

# Is de service ná de update gestart? Kijk naar 'Active: … since'
systemctl status php8.3-fpm

Si vous voulez le voir depuis le serveur web lui-même, placez temporairement un fichier avec un nom aléatoire dans la racine web, ouvrez-le une fois dans votre navigateur et supprimez-le immédiatement :

<?php echo PHP_VERSION, ' ', PHP_SAPI;

Pour une version amont, vous verrez ici 8.5.12, 8.4.27, 8.3.36 ou 8.2.35. Pour les paquets de distribution avec un backport, l’ancien numéro de version peut subsister ; dans ce cas, la commande changelog ci-dessus constitue votre preuve.

Redémarrer, et vraiment tout

La faille CVE-2026-109619 concerne des données qui persistent dans un worker. Une mise à jour sans redémarrage est donc inefficace.

Redémarrez PHP-FPM pour chaque version, par exemple sudo systemctl restart php8.3-fpm, ou Apache si PHP fonctionne en tant que module.
Redémarrez les processus PHP de longue durée : queue workers, Laravel Horizon, planificateurs, Reverb, Octane.
Recherchez les processus qui tournent encore sur l’ancien binaire PHP :

ls -l /proc/*/exe 2>/dev/null | grep -i 'php.*deleted'

Docker, FrankenPHP et hébergement

Docker : un hôte mis à jour ne répare pas le PHP dans vos conteneurs. Récupérez l’image de base corrigée, reconstruisez et déployez. Vérifiez avec docker run --rm jouw-image php -v.
FrankenPHP : PHP est intégré au binaire lui-même, vous avez donc besoin d’une nouvelle version de FrankenPHP.
Hébergement mutualisé ou infogéré, cPanel, Plesk, DirectAdmin : demandez à votre hébergeur de confirmer que votre domaine tourne sur une version corrigée. Changer de version PHP dans le panneau ne garantit rien à ce sujet.
PHP 8.1 ou antérieur : demandez un backport à votre distribution ou fournisseur LTS, ou mettez à niveau. D’ici là : appliquez les mesures ci-dessous, ou mettez le site hors ligne.

La mise à jour est impossible aujourd’hui ?

PHP énumère un certain nombre de mesures qui réduisent les voies d’attaque connues. Elles ne sécurisent explicitement pas votre installation ; considérez-les comme une solution temporaire pour quelques heures, pas pour des semaines. Appliquez-les dans php.ini, le pool FPM (php_admin_value / php_admin_flag) ou la configuration Apache, et non via ini_set() ou un .user.ini, puis redémarrez tous les workers.

Contre CVE-2026-109619 (état résiduel)

; in php.ini, of per FPM-pool:
; php_admin_flag[session.upload_progress.enabled] = off
session.upload_progress.enabled = 0

; alleen op PHP 8.5:
fatal_error_backtraces = 0

De plus, PHP conseille :

Supprimez les paramètres PHP invalides ou obsolètes qui génèrent un avertissement par requête. Masquer les avertissements avec error_reporting, display_errors ou @ n’aide pas.
Résolvez les erreurs fatales et les délais d’attente (timeouts) qu’un attaquant peut provoquer, par exemple dans le code de téléchargement, d’importation ou de nettoyage.

Contre CVE-2026-109618 (manque de mémoire)

Réglez memory_limit = -1 via php_admin_value et vérifiez qu’aucun pool, dossier ou application ne définit à nouveau une limite. Gérez ensuite l’utilisation de la mémoire avec une limite de conteneur ou de cgroup qui arrête uniquement le worker concerné. N’utilisez pas RLIMIT_AS ou RLIMIT_DATA pour cela : ils peuvent justement provoquer l’erreur vulnérable.
Abaissez post_max_size : 8M si vous n’avez pas besoin de téléchargements, 32M si c’est nécessaire. Maintenez upload_max_filesize en dessous.
Limitez également au niveau du serveur web ou du proxy la taille des requêtes, le nombre de champs, les parties multipart et les en-têtes, y compris pour les requêtes sans Content-Length valide.

; per FPM-pool, bijvoorbeeld /etc/php/8.3/fpm/pool.d/www.conf
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
php_admin_flag[session.upload_progress.enabled] = off

Couche supplémentaire : bloquer les requêtes multipart

Ceci n’est pas un conseil officiel de PHP, mais une mesure que de nombreux administrateurs ont déjà mise en œuvre hier. Si vous n’avez pas besoin de téléchargements, vous pouvez refuser les requêtes multipart avant qu’elles n’atteignent PHP. Faites-le dans chaque bloc serveur ou hôte virtuel qui redirige vers PHP, y compris le catch-all.

Nginx (dans le contexte http, plus le if en haut de chaque bloc serveur) :

map $http_content_type $block_multipart {
    default       0;
    "~*multipart" 1;
}

# in elke server block:
if ($block_multipart) { return 403; }

Apache 2.4 (hôte virtuel ou en haut de .htaccess) :

<If "req('Content-Type') =~ /multipart/i">
    Require all denied
</If>

Tant que cela est actif, les téléchargements de fichiers, les formulaires avec pièces jointes et certaines extensions de formulaire (comme Contact Form 7) ne fonctionneront pas.

Réduisez votre surface d’attaque

Mettez hors ligne les sites de staging et les applications PHP dont vous n’avez pas un besoin immédiat jusqu’à ce qu’ils soient corrigés. Le CERT-EU conseille d’isoler si nécessaire les applications vulnérables exposées sur Internet.
Limitez les outils d’administration comme phpMyAdmin à votre propre adresse IP.
Assurez-vous que votre serveur n’est pas accessible en contournant votre CDN ou WAF.

Hébergement mutualisé ? Vous ne pouvez généralement pas définir ces paramètres vous-même de manière fiable. Demandez à votre hébergeur quand votre domaine tournera sur un PHP corrigé.

Ce qui n’aide PAS

Mettre à jour WordPress, Laravel ou les extensions. La faille est dans PHP, pas dans votre application.
Les extensions de sécurité comme Wordfence. Elles ne s’exécutent qu’après que PHP a déjà traité la requête.
Les réglages via ini_set() ou un .user.ini FPM. Ils arrivent trop tard ; PHP le mentionne explicitement.
Masquer les messages d’erreur avec error_reporting, display_errors ou @.
RLIMIT_AS ou RLIMIT_DATA comme limite de mémoire. Ils peuvent justement provoquer l’erreur vulnérable.
Uniquement un WAF ou un CDN. Cela n’aide que si votre serveur n’est pas directement accessible via son adresse IP.
Mettre à jour sans redémarrer les workers. Les processus en cours utilisent l’ancien PHP jusqu’au redémarrage.

Étape 3 : vérifiez si une intrusion a déjà eu lieu

Appliquer le correctif ferme la porte, mais ne dit rien sur qui l’a déjà franchie. Les détails ont fuité le mardi 20 octobre vers 17 h 20, heure néerlandaise ; examinez l’historique à partir de 17 h 00 ce jour-là jusqu’au moment de votre correction.

Recherchez dans vos journaux de serveur web et de PHP des requêtes multipart inhabituelles et des plantages de workers PHP-FPM.
Recherchez des fichiers nouveaux ou modifiés dans les racines web, les dossiers de téléchargement, les extensions et les mu-plugins : find /var/www -type f -newermt '2026-10-20 15:00 UTC' (attendez-vous à du bruit provenant des caches et des logs).
Vérifiez les modifications des fichiers .user.ini et du paramètre auto_prepend_file.
Passez en revue les tâches cron, les unités systemd et Supervisor pour de nouvelles tâches, et vérifiez les nouvelles clés SSH.
Surveillez les processus PHP qui lancent un shell, Python ou curl/wget, ainsi que les connexions sortantes inattendues de l’utilisateur PHP.
Vérifiez dans vos applications si de nouveaux comptes administrateurs ont été créés.

Vous trouvez quelque chose ? Isolez le serveur et conservez les logs. Si les preuves indiquent une intrusion, reconstruisez le serveur et modifiez chaque secret auquel l’utilisateur PHP avait accès : fichiers .env, mots de passe de base de données, clés API et clés d’application. Un contrôle vierge n’est pas une garantie, mais c’est un bon signe.

Après la mise à jour : supprimer les mesures temporaires

Le PHP corrigé tourne-t-il de manière prouvée sur tous vos sites et tous les workers ont-ils été redémarrés ? Annulez alors les mesures d’urgence :

Remettez memory_limit à une valeur normale. Sans limite, un seul script défaillant peut paralyser tout le serveur.
Rétablissez post_max_size et upload_max_filesize si vos sites nécessitent des téléchargements plus volumineux.
Supprimez tout blocage multipart éventuel sur votre serveur web et dans votre CDN, puis testez un téléchargement de fichier et vos formulaires principaux.

session.upload_progress.enabled peut rester désactivé, à moins que votre application n’utilise cette fonction.

Besoin d’aide ?

Les clients bénéficiant de la gestion de serveur n’ont rien à faire : nous avons déjà mis en œuvre les mesures temporaires et appliquerons le correctif dès que la mise à jour sera disponible.

Vous n’avez pas de contrat de maintenance ou vous n’êtes pas sûr que votre serveur soit bien protégé ? Contactez Servermeister via [email protected] ou au 020 895 0045. Nous examinerons votre situation dès aujourd’hui.