PHP2Shell : deux failles critiques dans PHP, que faire maintenant

Deux failles critiques dans PHP lui-même permettent à un attaquant d’exécuter ses propres commandes sur un serveur web, sans mot de passe ni connexion. Elles concernent potentiellement tous les sites WordPress, Laravel ou PHP sur mesure dont le serveur n’a pas encore été mis à jour.

• Gravité : critique (CVSS v4.0 9.2), tentatives d’exploitation déjà observées ;
• Identifiants : CVE-2026-109618 et CVE-2026-109619 ;
• Correctifs : publiés le 21 octobre 2026.

Ce qui s’est passé

Le 21 octobre 2026, le projet PHP a publié des correctifs d’urgence pour deux failles graves dans le moteur PHP — le logiciel qui fait tourner la quasi-totalité des sites WordPress, Laravel et PHP sur mesure du web.

Ces failles, surnommées PHP2Shell, permettent à un attaquant d’envoyer une requête web d’apparence banale et, sans mot de passe ni connexion, d’exécuter les commandes de son choix sur le serveur. Comme la faiblesse se situe dans PHP lui-même — et non dans une extension, un thème ou une application précise — tout site PHP non corrigé est potentiellement exposé, quelle que soit la qualité de sa conception.

L’urgence est réelle. Les détails ont fuité en ligne le 20 octobre, avant la divulgation coordonnée prévue, ce qui a forcé PHP à avancer la publication des correctifs. Le matin du 21 octobre, avant même leur sortie, Cloudflare observait déjà des tentatives d’exploitation contre ses clients. Aucune compromission réussie n’a été confirmée publiquement à l’heure où j’écris, mais plusieurs organisations (administrations néerlandaises, services en ligne) ont préféré mettre leurs sites hors ligne en attendant de corriger.

La bonne nouvelle : les versions corrigées sont déjà disponibles. Mettre PHP à jour est le vrai remède, et il referme complètement la brèche.

Suis-je concerné ?

Première étape : connaître la version de PHP qui fait tourner votre site. Pas besoin d’être technicien pour la trouver.

Votre site est sous WordPress : connectez-vous à l’administration avec un compte administrateur, ouvrez le menu Outils → Santé du site, puis l’onglet Informations. Dépliez la section Serveur : la ligne Version de PHP affiche le numéro exact, par exemple 8.4.26.

Autre site, ou pas d’accès à l’administration : l’espace client de votre hébergeur indique souvent la version de PHP, dans une rubrique « PHP » ou « Configuration ». S’il n’affiche que la branche (« 8.4 ») sans le numéro complet, ou si un prestataire gère le serveur pour vous, posez-lui simplement la question : « Quelle version exacte de PHP fait tourner mon site, et comprend-elle les correctifs pour PHP2Shell ? »

Si vous avez un accès au serveur, exécutez php -v sur le serveur. Attention, cette commande donne la version de PHP en ligne de commande, qui peut différer de celle qui sert le site : vérifiez aussi php-fpm -v (le binaire porte parfois le numéro de branche, comme php-fpm8.4) ou la version affichée par phpinfo().

Comparez ensuite ce numéro à la version corrigée de votre branche :

• PHP 8.5 : vulnérable jusqu’à 8.5.11, installez 8.5.12 ;
• PHP 8.4 : vulnérable jusqu’à 8.4.26, installez 8.4.27 ;
• PHP 8.3 : vulnérable jusqu’à 8.3.35, installez 8.3.36 ;
• PHP 8.2 : vulnérable jusqu’à 8.2.34, installez 8.2.35.

Attention : les paquets des distributions Linux et des éditeurs LTS peuvent embarquer le correctif sous un numéro de version plus ancien. Vérifiez le changelog du paquet pour les CVE, pas seulement le numéro.

Toutes les façons de servir PHP sont concernées : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Les serveurs en mod_php sont les plu

Comment l’attaque fonctionne

Aucun fichier n’est téléversé et aucune extension n’est en cause. Une requête spécialement forgée — parfois suivie d’une seconde, traitée par le même processus — place la gestion mémoire de PHP dans un état corrompu, et le moteur finit par exécuter le code de l’attaquant sous l’identité de l’utilisateur du serveur web.

Le même défaut permet aussi de lire la mémoire du processus PHP, où peuvent traîner mots de passe, jetons et clés d’API d’autres requêtes — sans même aller jusqu’à l’exécution de code.

Anatomie d’une attaque

Imaginez une boutique en ligne utilisant WordPress et WooCommerce tournant avec PHP 8.3.35 — une version en retard sur le correctif — servie par Apache en mod_php, sans pare-feu en amont.

1. Le balayage. En milieu de matinée, des outils automatisés ratissent internet et identifient les serveurs par leur version de PHP. La boutique, encore sur une version vulnérable, est repérée.
2. La requête. L’attaquant envoie une requête d’apparence normale vers une page publique. Aucun fichier suspect, aucune URL étrange : rien qu’une personne relisant les logs d’accès n’entourerait.
3. L’intrusion. La requête place la mémoire de PHP dans l’état corrompu. Le moteur suit une référence qu’il ne devrait pas, et exécute le code de l’attaquant. Aucun mot de passe n’a été vérifié : la faille se situe sous l’application.
4. La charge utile. L’attaquant dispose désormais d’un shell sous l’identité de l’utilisateur du serveur web. Il lit le fichier .env de Laravel pour récupérer identifiants de base de données et clés d’API, exfiltre la table des clients, et dépose une porte dérobée invisible qui survivra au correctif.
5. Le signe révélateur. Dans les heures précédant l’intrusion, les processus PHP ont planté à répétition. Puis l’indice qui trahit tout : un processus du serveur web a lancé un shell, chose qu’il n’a aucune raison légitime de faire.

Pourquoi le code de l’application n’a rien pu faire. Une validation des entrées irréprochable, des requêtes préparées et des jetons CSRF partout n’auraient servi à rien ici. Le composant vulnérable est PHP lui-même : le correctif est une mise à jour de l’environnement d’exécution, pas une modification de l’application.

Que faire maintenant

1. En premier : mettre PHP à jour vers la version corrigée de votre branche. Reportez-vous à la liste des versions ci-dessus. C’est le vrai correctif.
2. Redémarrer les processus PHP-FPM ou Apache après la mise à jour. Le correctif ne prend effet qu’une fois les processus recyclés, y compris les workers PHP longue durée. Mettre à jour WordPress ou Laravel ne met pas à jour le moteur PHP en dessous : il vient du paquet système, de l’hébergeur ou de l’image de conteneur.
3. Après la mise à jour, revoir memory_limit et post_max_size. Le correctif ajoute une limite mémoire dure : l’atteindre termine le processus et empêche les handlers de shutdown de s’exécuter. Vérifiez que ces valeurs correspondent aux besoins réels de l’application.
4. Impossible de corriger tout de suite ? Mesures provisoires pour la CVE-2026-109618. Définissez memory_limit=-1 de façon non surchargeable par l’application (php_admin_value dans le pool FPM ou la configuration Apache), et vérifiez qu’aucun réglage de pool, de répertoire ou d’application ne remet une limite finie. Abaissez post_max_size : 8M sans téléversement de fichiers, 32M sinon, avec upload_max_filesize en dessous. Limitez la taille des requêtes au niveau du serveur web ou du proxy. Utilisez une limite cgroup ou conteneur comme garde-fou de disponibilité, jamais RLIMIT_AS ni RLIMIT_DATA, qui peuvent déclencher le chemin vulnérable.
5. Mesures provisoires pour la CVE-2026-109619. Définissez session.upload_progress.enabled=0 dans php.ini, le pool FPM ou la configuration du serveur — pas via ini_set() ni .user.ini, qui s’appliquent trop tard — puis redémarrez tous les workers. Sur PHP 8.5, ajoutez fatal_error_backtraces=0. Supprimez les réglages invalides ou dépréciés appliqués par requête qui émettent des diagnostics avant l’initialisation : les masquer avec error_reporting, display_errors ou @ ne sert à rien. Corrigez les erreurs fatales et les timeouts atteignables par un attaquant.
6. Important : ne pas considérer ces mesures comme une protection. PHP le dit explicitement : elles réduisent l’exposition à certains chemins d’attaque mais ne rendent pas l’installation sûre. Seule la mise à jour est complète. Si vous ne pouvez ni corriger ni isoler, le CERT-EU et le NCSC britannique recommandent d’envisager de mettre le service hors ligne.
7. Vérifier les logs pour des plantages répétés de processus. Cherchez des segfaults PHP-FPM ou Apache, des redémarrages de workers inexpliqués, des requêtes multipart inhabituelles suivies d’erreurs de limite mémoire ou de HTTP 500 en rafale, et des cookies PHPSESSID de réponse anormalement longs : autant de signes de tentatives d’exploitation.
8. Surveiller un serveur web qui lance un shell, par exemple apache2 ou php-fpm lançant sh -c id. C’est le signe le plus clair d’une attaque réussie.
9. En cas de signes de compromission, renouveler les secrets. Changez les mots de passe de base de données et les clés d’API, passez en revue les comptes administrateurs, et recherchez des fichiers .php inconnus.

Besoin d’un coup de main ?

Si vous ne savez pas quelle version de PHP fait tourner votre site, ou si votre hébergeur ne vous laisse pas la main sur le serveur, c’est le moment de poser la question. Je peux vérifier votre version, appliquer la mise à jour et contrôler les journaux dans le cadre d’une maintenance ou d’une sécurisation. Et si vous voyez déjà des signes de compromission, écrivez à urgence@jehan.dev : vous aurez une réponse sous 24h, week-end compris.

Sources

• Avis de sécurité PHP.net
• Cloudflare
• BleepingComputer
• Help Net Security
• Huntress
• The Hacker News
• Plesk

Ces informations reflètent l’état des connaissances au 21 octobre 2026, date de la divulgation. Vérifiez les versions sur vos propres serveurs avant d’agir.