PHP2Shell : vérifier et corriger les failles RCE de PHP
Le 21 octobre 2026, le projet PHP a publié les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35 pour corriger deux failles dans PHP lui-même, surnommées PHP2Shell. Toutes deux permettent à une requête envoyée par une personne non connectée d'exécuter du code avec les droits du worker PHP. Le bug se trouve dans le runtime, pas dans WordPress, Drupal ou Joomla : mettre à jour le CMS ou ses plugins ne le corrige donc pas. Ce guide montre qui est concerné, comment vérifier un serveur en une commande, quoi faire dès aujourd'hui si vous ne pouvez pas encore mettre à jour, et comment mettre à jour sans risque.
Les deux failles
- CVE-2026-109618, corruption en cas de mémoire insuffisante - quand une allocation mémoire échoue, PHP peut interrompre une requête alors que ses données internes ne sont qu'à moitié initialisées, et le nettoyage qui suit fait confiance à ces données cassées. Une requête multipart forgée peut la déclencher même en respectant les limites de taille que vous avez configurées.
- CVE-2026-109619, état global périmé - un état propre à une requête peut survivre à la mémoire qui le porte. La requête suivante traitée par le même worker peut utiliser cette mémoire libérée avant sa réinitialisation (un use-after-free). Le chemin confirmé passe par la fonction session upload progress et les erreurs fatales.
Les deux sont notées 9.2 (critique) en CVSS 4.0. L'annonce de PHP indique qu'un exploit fonctionnel a été construit pendant les recherches et que le risque est le plus élevé avec Apache et mod_php, où l'attaque s'exécute avant tout code applicatif. Plusieurs preuves de concept publiques sont apparues en quelques jours ; Rapid7 indique que chacune ne fonctionne que pour une seule combinaison de système, de version de PHP et de serveur web, et a observé des tentatives d'exploitation. Traitez-la comme un correctif d'urgence.
Qui est concerné
Toute installation PHP qui sert des requêtes web : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Cela couvre presque tous les serveurs WordPress, WooCommerce, Drupal, Joomla, Magento, Laravel et Nextcloud.
| Branche PHP | Versions touchées | Première version corrigée |
|---|---|---|
| 8.5 | 8.5.0 - 8.5.11 | 8.5.12 |
| 8.4 | 8.4.0 - 8.4.26 | 8.4.27 |
| 8.3 | 8.3.0 - 8.3.35 | 8.3.36 |
| 8.2 | 8.2.0 - 8.2.34 | 8.2.35 |
| 7.4, 8.0, 8.1 | toutes | aucune version sur php.net ; backports dans les sources, paquets de la distribution ou d'un éditeur LTS |
| 7.3 et antérieures | toutes | aucun correctif |
Les distributions gardent souvent l'ancien numéro de version et rétroportent le correctif (par exemple un paquet Debian ou Ubuntu qui affiche toujours 8.2.x). Avec un PHP issu de paquets, consultez donc le paquet dans le security tracker de votre distribution, pas seulement le numéro.
Vérifier un serveur en une commande
Enregistrez ceci sous php2shell-check.php et lancez-le avec le même PHP que celui qui sert votre site. Il affiche la version, indique si elle est antérieure au correctif et montre les deux paramètres que modifient les mesures d'attente ci-dessous.
<?php
// PHP2Shell check: is this PHP build older than the October 21, 2026 fixes?
$fixed = ['8.5' => '8.5.12', '8.4' => '8.4.27', '8.3' => '8.3.36', '8.2' => '8.2.35'];
$branch = PHP_MAJOR_VERSION . '.' . PHP_MINOR_VERSION;
echo "PHP " . PHP_VERSION . " (" . PHP_SAPI . ")\n";
if (!isset($fixed[$branch])) {
echo "Branch $branch gets no php.net release: check your distro or LTS vendor, or upgrade to 8.4.\n";
} elseif (version_compare(PHP_VERSION, $fixed[$branch], '<')) {
echo "VULNERABLE: upgrade to {$fixed[$branch]} or later (or a distro build with the backport).\n";
} else {
echo "Patched upstream version ({$fixed[$branch]}+).\n";
}
echo "session.upload_progress.enabled = " . (ini_get('session.upload_progress.enabled') ? 'On' : 'Off') . "\n";
echo "post_max_size = " . ini_get('post_max_size') . ", memory_limit = " . ini_get('memory_limit') . "\n";
php php2shell-check.php
Sortie vérifiée le 2026-10-24 dans les images Docker officielles php :
PHP 8.3.30 (cli)
VULNERABLE: upgrade to 8.3.36 or later (or a distro build with the backport).
session.upload_progress.enabled = On
post_max_size = 8M, memory_limit = 128M
PHP 8.4.27 (cli)
Patched upstream version (8.4.27+).
PHP 7.2.34 (cli)
Branch 7.2 gets no php.net release: check your distro or LTS vendor, or upgrade to 8.4.
Le php en ligne de commande peut être un autre build que celui qui sert votre site. Pour vérifier côté web, lancez php-fpm -v (ou php-fpm8.3 -v sous Debian et Ubuntu), ou placez le script à la racine web le temps d'une requête et supprimez-le tout de suite après.
Si vous ne pouvez pas mettre à jour aujourd'hui : mesures d'attente
L'équipe PHP est claire : il n'existe pas de contournement complet et la mise à jour est le seul choix sûr. Ces réglages réduisent la surface d'attaque pendant que vous planifiez la mise à jour. Définissez-les là où l'application ne peut pas les écraser - dans php.ini ou dans le pool FPM avec php_admin_value -, car ini_set() et .user.ini s'appliquent trop tard. Redémarrez ensuite tous les workers.
; FPM pool, e.g. /etc/php/8.3/fpm/pool.d/zz-php2shell.conf (the [www] section of your pool)
[www]
php_admin_value[session.upload_progress.enabled] = 0
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 30M
php-fpm8.3 -t && systemctl restart php8.3-fpm
Nous avons vérifié ce fichier de pool avec php-fpm -t sous PHP 8.4 (configuration test successful). Ce que fait chaque ligne :
session.upload_progress.enabled = 0bloque le chemin confirmé de CVE-2026-109619, pas toutes les variantes. Désactivez-le sauf si une barre de progression d'upload en dépend.post_max_sizeà 8M sans uploads, ou 32M si le site accepte des fichiers, avecupload_max_filesizeen dessous, comme le recommande l'équipe PHP. Limitez aussi la taille des requêtes dans nginx (client_max_body_size 32m;) ou Apache (LimitRequestBody).- Sous PHP 8.5 uniquement, ajoutez
fatal_error_backtraces = 0. - PHP suggère aussi
memory_limit = -1fixé par l'administrateur, pour que la limite mémoire elle-même ne puisse pas servir à déclencher CVE-2026-109618. Ne le faites qu'avec une limite mémoire de conteneur ou de cgroup autour de PHP, sinon une seule requête malveillante peut occuper toute la RAM du serveur. N'utilisez pasRLIMIT_ASniRLIMIT_DATApour cela : ils peuvent déclencher la faille.
Masquer les erreurs (display_errors, error_reporting, @) n'aide pas, et un journal d'erreurs vide ne prouve pas qu'un serveur n'a pas été attaqué.
Comment mettre à jour
- PHP en paquets (Debian, Ubuntu, RHEL, AlmaLinux). Installez la mise à jour de sécurité (
apt update && apt upgrade, oudnf upgrade 'php*'), puis redémarrez PHP-FPM ou Apache, car les workers en cours gardent l'ancien code. Vérifiez que le changelog du paquet mentionne CVE-2026-109618. - Images Docker. Reconstruisez sur un tag corrigé (
php:8.4-fpmpointe désormais vers 8.4.27) avecdocker compose build --pull, puis recréez les conteneurs. Un conteneur en cours d'exécution garde l'ancien PHP jusqu'à son remplacement. - PHP 7.4 - 8.1. Utilisez le paquet rétroporté de votre éditeur, ou passez à 8.4. PHP 7.3 et antérieures ne recevront jamais de correctif : placez le site derrière une liste d'autorisation ou un VPN jusqu'à sa migration.
- Après la mise à jour, relancez le script de vérification et parcourez le journal du serveur web à la recherche de requêtes POST multipart inhabituelles et de plantages de workers PHP depuis le 21 octobre.
Si vous avez besoin d'aide, l'administration de serveurs infogérée couvre ce type de correctif, et notre guide du serveur cloud pour WordPress présente une configuration PHP-FPM qui garde ces réglages dans le pool. Avant de mettre à jour un site en production, prenez un snapshot : sauvegarde et restauration d'une VM explique comment faire.
Ce que nous avons fait
La même semaine, nous avons vérifié chaque service DCXV qui utilise PHP et appliqué les mesures de ce guide. Les serveurs des clients sont gérés par leurs propriétaires : si vous faites tourner PHP sur un serveur cloud ou dédié DCXV, lancez la vérification ci-dessus dès aujourd'hui. Un nouveau serveur cloud reçoit les paquets à jour dès son premier apt upgrade.
Sources (consultées le 2026-10-24) : l'annonce des versions de sécurité PHP 8.x du 21 octobre 2026, les avis PHP GHSA-w8hw-w9fx-j79w et GHSA-6wmf-4rv5-p3rp, et l'analyse de Rapid7.
