Faille PHP2Shell (CVE-2026-109618) : comprendre et corriger

Le 21 octobre 2026 à 14 h UTC (16 h à Paris), l'équipe PHP a publié en urgence PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Ces versions corrigent deux failles critiques, CVE-2026-109618 et CVE-2026-109619, notées 9,2 sur 10 (CVSS v4.0). Combinées, elles permettent d'exécuter du code sur le serveur à distance, sans compte et sans mot de passe. L'outil d'exploitation qui les enchaîne circule sous le nom de PHP2Shell.

PHP fait tourner la majorité des sites dont on connaît le langage serveur : WordPress, Magento, PrestaShop, Drupal, Joomla, Laravel, Symfony, Nextcloud, phpMyAdmin. Si votre site, votre boutique ou votre outil interne est en PHP, cet article vous dit ce qui se passe, comment savoir si vous êtes exposé et comment corriger, dans l'ordre.

Faille PHP2Shell : ce qui s'est passé

Les deux failles ont été signalées à l'équipe PHP en août 2026 par des chercheurs en sécurité (Calif, puis Wiz Research). Leur publication était prévue sous embargo. Le 20 octobre, des informations ont fuité ; l'équipe PHP a avancé l'annonce et fixé la sortie des correctifs au lendemain. Le 21 octobre au matin, avant même la sortie des correctifs, Cloudflare signalait les premières attaques contre des sites PHP et déployait des règles de filtrage pour tous ses clients.

Le point important pour un dirigeant : la faille est dans PHP lui-même, pas dans votre application. Un code applicatif propre ne protège pas. Les chercheurs ont confirmé l'exploitation sur des versions récentes de WordPress, Magento, Drupal, Joomla, Nextcloud, Laravel ou Symfony, en configuration par défaut.

Comment fonctionne la faille, sans jargon

PHP traite chaque requête HTTP en préparant des données internes (le formulaire envoyé, les fichiers, la session), puis en les nettoyant à la fin. Les deux failles exploitent un moment précis : une erreur fatale qui interrompt PHP au milieu de cette préparation, typiquement un dépassement de la limite mémoire (memory_limit) provoqué par une requête volontairement énorme.

CVE-2026-109618, corruption après un manque de mémoire. L'erreur interrompt PHP alors que certaines données internes ne sont qu'à moitié initialisées. Le nettoyage de fin de requête les traite ensuite comme valides. Selon Sansec, cette faille permet aussi de faire fuiter de la mémoire du serveur dans un cookie de session, et donc potentiellement des mots de passe, des jetons ou des clés.
CVE-2026-109619, état global périmé. Une donnée liée à une requête survit alors que sa mémoire a déjà été libérée. La requête suivante, traitée par le même processus PHP, la réutilise avant qu'elle soit réinitialisée.

Dans les deux cas, un attaquant prépare la mémoire du serveur avec une première requête et en prend le contrôle avec la suivante. D'après l'avis officiel, le risque est le plus élevé avec Apache et mod_php : une requête anonyme y déclenche l'attaque avant même que votre code s'exécute.

Qui est concerné

L'avis de l'équipe PHP est sans ambiguïté : toutes les installations PHP qui répondent à des requêtes web, quel que soit le mode d'exécution : PHP-FPM (le cas le plus courant derrière nginx), Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le code fautif remonte à PHP 5.4, sorti en 2012.

PHP 8.2 à 8.5 : corrigé dans 8.2.35, 8.3.36, 8.4.27 et 8.5.12.
PHP 8.1 et plus ancien : plus maintenu par le projet PHP, donc pas de version officielle corrigée. L'équipe PHP a exceptionnellement publié des correctifs minimaux à compiler pour 7.4, 8.0 et 8.1, et certaines distributions Linux en proposent des rétroportages.
Hébergement mutualisé : c'est l'hébergeur qui met PHP à jour, mais c'est souvent vous qui choisissez la version dans le panneau d'administration. Un site resté sur une version abandonnée ne recevra rien.

Un script PHP lancé uniquement en ligne de commande, sans exposition web, n'est pas la cible de cette attaque. Mais la plupart des serveurs qui ont un PHP en ligne de commande ont aussi un PHP-FPM ou un mod_php qui répond au web.

Vérifier sa version de PHP, au bon endroit

Le piège classique : vérifier la version en ligne de commande, alors que le site est servi par un autre binaire. Sur un même serveur Debian ou Ubuntu cohabitent souvent plusieurs versions.

# Version de la ligne de commande (pas forcément celle du site)
php -v

# Version de PHP-FPM, celle qui sert le site derrière nginx
php-fpm8.3 -v        # adaptez au numéro installé : ls /usr/sbin/php-fpm*

# Paquets PHP installés sur Debian ou Ubuntu
dpkg -l | grep -E '^ii +php[0-9.]+-(fpm|cli|common)'

# Image Docker : version embarquée dans le conteneur
docker exec <conteneur> php -v

Sur un hébergement mutualisé, la version se lit dans le panneau d'administration de l'hébergeur. Côté applicatif, WordPress l'affiche dans Outils, puis Santé du site, onglet Informations, section Serveur.

Corriger : mettre à jour PHP

L'équipe PHP le répète dans chaque annonce : il n'existe aucune protection complète, la mise à jour est la seule solution sûre. Le correctif ne change pas le comportement de vos applications : c'est une version de maintenance de la même branche.

Debian, Ubuntu et autres distributions Linux. Les éditeurs ont reçu les correctifs en avance. Installez les paquets de sécurité de votre distribution, puis redémarrez les services : un PHP-FPM ou un Apache qui n'a pas redémarré continue d'exécuter l'ancien code en mémoire.

sudo apt update
sudo apt install --only-upgrade 'php8.3*'      # adaptez à votre branche
sudo systemctl restart php8.3-fpm               # ou : sudo systemctl restart apache2
php-fpm8.3 -v                                    # vérifiez la version réellement servie

Docker. Mettre à jour PHP dans un conteneur qui tourne ne sert à rien : il sera remplacé au prochain déploiement. Reconstruisez l'image depuis une base à jour (php:8.3-fpm ou la version exacte corrigée), sans cache, puis redéployez. Vérifiez ensuite la version dans le conteneur en service.
Hébergement mutualisé. Vérifiez dans le panneau que la version choisie est une branche maintenue (8.2 au minimum) et consultez la page d'état de l'hébergeur. Si vous êtes encore en 7.x ou 8.0, c'est le moment de passer à une version récente.
PHP 8.1 et plus ancien. Trois options, de la meilleure à la moins bonne : passer à une branche maintenue ; appliquer le rétroportage de votre distribution ou d'un éditeur de support étendu ; compiler PHP avec le correctif minimal publié par l'équipe PHP. Attention, PHP 8.2 ne recevra plus de correctifs de sécurité après le 31 décembre 2026 : une montée de version planifiée maintenant vous évite de revivre cette urgence dans quelques mois.

Après la mise à jour, testez les parcours qui comptent : connexion, formulaire de contact, envoi de fichier, paiement. Sur une boutique, passez une commande test.

Si vous ne pouvez pas mettre à jour tout de suite

Ces mesures réduisent l'exposition à certains chemins d'attaque connus. Aucune ne rend l'installation sûre, et l'équipe PHP précise que d'autres variantes existent. Elles servent à tenir quelques heures, pas à remplacer le correctif.

Passer derrière Cloudflare ou un pare-feu applicatif. Cloudflare a déployé des règles contre les vecteurs connus pour tous ses clients, y compris gratuits. Elles ne protègent que le trafic qui passe par Cloudflare : le pare-feu du serveur doit alors refuser les connexions directes qui ne viennent pas de ses adresses.
Désactiver la progression d'envoi de session. session.upload_progress.enabled = 0 dans php.ini ou dans le pool PHP-FPM (php_admin_flag), puis redémarrez tous les processus. Un ini_set() dans le code ou un fichier .user.ini ne suffisent pas : le réglage doit s'appliquer avant l'analyse de la requête.
Sur PHP 8.5, fatal_error_backtraces = 0, avec le même redémarrage.
Réduire la taille des requêtes acceptées. post_max_size = 8M si le site n'accepte pas d'envoi de fichiers, 32M sinon, avec upload_max_filesize en dessous. Limitez aussi la taille des corps de requête au niveau du serveur web ou du proxy.
En dernier recours, bloquer les formulaires multipart au niveau du serveur web, ou ne laisser passer que les lectures (GET et HEAD). Les envois de fichiers, la connexion et les commandes ne fonctionnent plus : c'est une mise en lecture seule, à réserver à un site qui ne peut pas être corrigé dans la journée. Un mode maintenance WordPress ou Magento ne protège pas, puisque PHP analyse quand même chaque requête.

Une mesure est à manier avec précaution : l'avis officiel mentionne memory_limit = -1 pour supprimer la limite mémoire. C'est efficace contre un chemin d'attaque, mais une seule requête peut alors consommer toute la mémoire du serveur. À ne faire qu'avec une limite mémoire au niveau du conteneur ou du service, et une surveillance active.

Après la mise à jour : vérifier que rien ne s'est passé

Des attaques ont été observées avant la publication des correctifs. Un site corrigé le 22 octobre a pu être visé la veille. Sansec liste des signaux à chercher dans les journaux depuis le 20 octobre :

des requêtes multipart/form-data inhabituelles suivies d'erreurs de limite mémoire ou de séries de réponses 500 ;
des cookies PHPSESSID anormalement longs ou malformés dans les réponses du serveur ;
des redémarrages inexpliqués de processus PHP, et un pic d'erreurs fatales autour de memory_limit.

Si ces signaux apparaissent, partez du principe que le serveur a pu être compromis : cherchez des fichiers PHP récemment modifiés ou ajoutés dans les dossiers d'envoi, des comptes administrateurs inconnus, des tâches planifiées nouvelles. La faille pouvant faire fuiter de la mémoire, changez les secrets que le serveur manipule : mots de passe de base de données, clés d'API, clés de paiement, et déconnectez toutes les sessions. Une sauvegarde antérieure au 20 octobre, testée, est votre filet de sécurité.

Ce que cette faille dit de votre maintenance

PHP2Shell n'est pas un cas isolé. PHP a déjà connu des failles exploitées massivement, comme CVE-2019-11043 sur PHP-FPM ou CVE-2024-4577 sur php-cgi, utilisées ensuite par des groupes de rançongiciels. Entre la fuite et les premières attaques, il s'est écoulé moins d'une journée. La question n'est donc pas « mon site sera-t-il visé », mais « en combien d'heures puis-je le mettre à jour ».

Mes propres produits tournent sous Node.js et ne sont pas concernés par cette faille. Mais la même discipline s'applique à n'importe quelle pile, et c'est elle qui fait la différence le jour où une faille de ce niveau tombe :

Savoir ce qui tourne. Quelle version de PHP, sur quel serveur, dans quel conteneur. Une ligne par application, tenue à jour. Sans cet inventaire, on perd la première heure à chercher.
Pouvoir redéployer vite. Une image Docker qu'on reconstruit et redéploie en une commande se corrige en minutes. Un serveur configuré à la main il y a cinq ans se corrige en jours.
Rester sur une version maintenue. Un site en PHP 7.4 ou 8.0 n'a reçu cette fois qu'un correctif minimal à compiler soi-même. La prochaine fois, il n'aura peut-être rien.
Avoir des sauvegardes restaurées au moins une fois. Une sauvegarde jamais testée n'est pas une sauvegarde. Une restauration complète, testée sur un serveur vierge, est le seul moyen de le savoir.
Surveiller. Des alertes sur les erreurs 500 et les redémarrages de processus auraient signalé cette attaque. C'est le rôle d'une supervision même légère.

Ce que j'en retiens

La faille est dans PHP, pas dans votre code : tout site PHP exposé au web est concerné, WordPress et boutiques compris.
La seule correction est la mise à jour vers 8.2.35, 8.3.36, 8.4.27 ou 8.5.12, suivie d'un redémarrage de PHP-FPM ou d'Apache, et d'une vérification de la version réellement servie.
Les réglages temporaires et le pare-feu font gagner des heures, pas davantage.
Après le correctif, cherchez des traces d'attaque depuis le 20 octobre et changez les secrets si le doute existe.
Une version de PHP non maintenue est une dette de sécurité qui finit par se payer en urgence.

Votre site ou votre application tourne en PHP et vous ne savez pas qui s'occupe de la mise à jour, ni sur quelle version vous êtes ? Je peux faire le point avec vous, appliquer le correctif et mettre en place la maintenance qui évite la prochaine urgence. Décrivez-moi votre installation, je vous réponds rapidement.

Sources : avis de sécurité de l'équipe PHP du 21 octobre 2026 (php.net), analyses de Sansec et de Tenable. Article à jour au 21 octobre 2026 ; les recommandations de votre distribution et de votre hébergeur priment.

← Tous les articles