Failles PHP2Shell : deux brèches critiques dans PHP font tomber des sites, voici comment protéger le vôtre

Le 21 octobre 2026, des préfectures, la CNIL, le Parlement néerlandais ou DeviantArt ont coupé leur site par précaution. En cause : deux failles critiques dans le moteur PHP, présentes depuis 2012, qui donnent la main sur un serveur avec une seule requête et sans mot de passe. Voici ce qui s’est passé, qui est exposé et ce qu’il faut faire, que vous ayez un site sur un hébergement mutualisé ou votre propre serveur.

L’essentiel

• Deux vulnérabilités, CVE-2026-109618 et CVE-2026-109619, surnommées PHP2Shell, ouvrent l’exécution de code à distance sans authentification. Elles sont notées 9,2 sur 10.
• Toutes les versions de PHP depuis la 5.4 sont touchées. Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, publiées le 21 octobre à 16 h (heure de Paris).
• Les serveurs Apache avec mod_php sont les plus exposés, mais PHP-FPM, LiteSpeed et FrankenPHP sont aussi concernés selon la configuration.
• Des tentatives d’attaque ont été repérées avant même la sortie des correctifs. Les installations en PHP 8.1 ou plus ancien n’auront pas de mise à jour officielle complète.
• Les failles ont été trouvées et exploitées avec l’aide de modèles d’IA, qui ont transformé en quelques semaines un vieux défaut connu en attaque fonctionnelle.

Une journée de coupures en chaîne

Les coupures ont commencé en fin de matinée. Le Parlement néerlandais a mis son site hors ligne vers midi, suivi du centre néerlandais de cybersécurité lui-même, d’universités, d’un club de football et d’associations professionnelles. En France, le ministère de l’Intérieur a placé les sites des préfectures en « maintenance préventive » à la demande de l’ANSSI. Le site de la CNIL affichait une page de maintenance à partir de 12 h 30, et des sites comme celui de la Banque de France, une partie du portail des impôts ou celui de l’ADEME ont suivi. DeviantArt et 4chan ont fermé ou basculé en lecture seule.

Aucun de ces sites n’a été signalé comme piraté. Ces fermetures répondaient aux consignes des autorités de cybersécurité. Le CERT-FR, dans son alerte CERTFR-2026-ALE-014, recommandait d’isoler les systèmes concernés en attendant de pouvoir les mettre à jour. Son homologue néerlandais allait plus loin : tant que les correctifs n’étaient pas installés, tout système PHP accessible depuis Internet devait être considéré comme vulnérable, et l’arrêt complet du serveur faisait partie des options.

L’ampleur s’explique par la place de PHP sur le web. Selon W3Techs, le langage fait tourner 69,3 % des sites dont la technologie côté serveur est identifiable, dont tous les sites WordPress, Drupal, Joomla ou Magento. Une recherche sur le moteur Shodan recensait plus de 1,9 million de serveurs PHP directement exposés sur Internet.

Deux failles au cœur du moteur PHP

Les deux vulnérabilités ne se trouvent pas dans un CMS ou une extension, mais dans PHP lui-même. Mettre à jour WordPress ne change donc rien : WordPress.org a indiqué qu’aucune mise à jour du CMS n’était prévue, le correctif devant venir de PHP.

La première, CVE-2026-109618, exploite la gestion du manque de mémoire. Quand une requête atteint la limite de mémoire autorisée au mauvais moment, PHP interrompt son traitement alors que certaines données internes ne sont qu’à moitié initialisées. Lors du nettoyage, il les traite comme valides. Une requête de formulaire ou d’envoi de fichier spécialement construite (le format multipart) suffit à provoquer ce scénario, avant même que le code du site ne s’exécute.

La seconde, CVE-2026-109619, repose sur un état laissé par une requête précédente. Un processus PHP traite les requêtes les unes après les autres. Si une erreur fatale ou un manque de mémoire interrompt une requête, certaines informations internes continuent de pointer vers de la mémoire déjà libérée. La requête suivante, traitée par le même processus, peut alors réutiliser cette mémoire. Ce type de défaut, appelé use-after-free, ouvre la porte à l’exécution de code.

Combinées, les deux failles donnent à l’attaquant les droits du compte qui fait tourner PHP sur le serveur : lire les fichiers du site, y déposer une porte dérobée, puiser dans la base de données.

Qui est exposé ?

Selon l’avis de sécurité publié par l’équipe de PHP, toutes les installations qui traitent des requêtes web sont concernées. Le degré de risque varie selon la façon dont PHP est branché au serveur web.

Côté versions, la situation dépend de la branche installée.

Les chercheurs ont confirmé l’exécution de code sur les dernières versions de WordPress, Drupal et Joomla, et l’ont décrite sur Magento, MediaWiki, phpMyAdmin, Nextcloud, Roundcube, Laravel, Symfony ou WHMCS. Une simple page PHP sur une version vulnérable suffit, puisque la faille se déclenche avant le code de l’application.

L’IA a transformé un vieux défaut en arme

Le défaut n’est pas nouveau. Un bug d’allocation mémoire avait été signalé en 2020, et la PHP Foundation reconnaît que les premiers signes du problème avaient été repérés en 2024, lors d’un audit de sécurité mené par Quarkslab. Faute de piste d’exploitation concrète et d’accord sur la manière de le corriger, le chantier avait été mis en pause à plusieurs reprises. La fondation parle elle-même d’une « défaillance structurelle ».

Tout a basculé l’été dernier, avec l’arrivée de chercheurs équipés de modèles d’IA. La société Calif, qui participe au programme Patch the Planet d’OpenAI, a signalé le 11 août une exécution de code à distance de même origine. OpenAI a fait le même signalement le même jour, en indiquant que la faille avait été identifiée avec GPT-5.6 Sol. De son côté, l’éditeur de sécurité Wiz a confirmé l’attaque sur Drupal le 20 août, puis sur WordPress le 21, avant de la signaler à PHP le 24.

Dans son rapport technique, Wiz détaille la part prise par les modèles d’IA (Gemini 4 Argon, GPT-5.6 Sol et son propre outil Wiz Atlas) dans la découverte, l’écriture de l’exploit, la détection des attaques et la validation du correctif. Selon l’entreprise, un seul chercheur a fait en une semaine un travail qui aurait demandé plusieurs mois à une équipe de haut niveau. « Ce que l’IA a changé, c’est la capacité à comprendre les faiblesses et à les transformer en exploit fonctionnel », résument ses chercheurs.

Calif nuance : ses chercheurs disent n’avoir utilisé que des modèles accessibles au public, et rappellent qu’aucun modèle ne trouve « tous les bugs » avec de simples requêtes. Le travail reste guidé par des experts. Mais la barrière d’entrée a baissé, et c’est ce qui inquiète : les mêmes outils sont à la portée des attaquants. Ce n’est pas un cas isolé. En juillet, la chaîne de failles wp2shell, dans le cœur de WordPress, avait été trouvée avec GPT-5.6 Sol Ultra en une dizaine d’heures de travail, pour environ 25 dollars de calcul.

Une divulgation qui a dérapé

Le calendrier prévoyait une publication coordonnée le 22 octobre, le temps que les distributions Linux et les hébergeurs préparent leurs mises à jour. Il n’a pas tenu.

Des tentatives d’exploitation ont été rapportées par Cloudflare, Patchstack, watchTowr ou Hadrian, certaines avant la sortie des correctifs. La plupart visent le chemin de la progression d’envoi de session. Le 21 octobre au soir, watchTowr n’avait observé aucune attaque réussie, tout en jugeant que cela ne durerait pas. Amazon estime de son côté que la faille est désormais largement exploitée et recommande de faire remonter les investigations au 17 octobre.

Votre site est-il concerné ? Ce qu’il faut faire selon votre hébergement

La marche à suivre dépend surtout de qui gère PHP sur votre serveur.

OVHcloud indique par exemple que ses clients en hébergement mutualisé reçoivent automatiquement un PHP corrigé, mais que les clients VPS et serveurs dédiés doivent agir eux-mêmes.

Pour connaître la version utilisée par un site WordPress, ouvrez Outils > Santé du site > Informations > Serveur. Attention à deux pièges. D’abord, les distributions Linux corrigent fréquemment leurs paquets sans changer le numéro de version : un serveur Debian peut afficher PHP 8.2.x et être protégé. Ensuite, la commande php -v donne la version en ligne de commande, qui peut différer de celle qui sert réellement le site. En cas de doute, déposez temporairement un fichier version.php contenant <?php echo PHP_VERSION; à la racine du site, ouvrez-le dans le navigateur, puis supprimez-le aussitôt.

Mettre à jour un VPS pas à pas

Sur un serveur que vous administrez, la mise à jour prend quelques minutes. Le piège le plus courant est d’oublier le redémarrage : sans lui, l’ancienne version reste chargée en mémoire.

1. Faites une sauvegarde ou un instantané du serveur.
2. Mettez à jour les paquets :

bash

# Debian / Ubuntu
sudo apt update && sudo apt upgrade

# AlmaLinux / Rocky Linux
sudo dnf upgrade

3. Redémarrez PHP et le serveur web :

bash

# PHP-FPM sur Debian / Ubuntu (remplacez 8.3 par votre version)
sudo systemctl restart php8.3-fpm

# Apache
sudo systemctl restart apache2   # Debian / Ubuntu
sudo systemctl restart httpd     # AlmaLinux / Rocky Linux

4. Vérifiez la version réellement servie avec le fichier version.php décrit plus haut, puis contrôlez que le site fonctionne. Si Nginx renvoie une erreur 502 Bad Gateway après le redémarrage, c’est en général que PHP-FPM n’est pas reparti : son statut s’affiche avec sudo systemctl status php8.3-fpm.

Si vous utilisez le dépôt Remi sur une distribution Red Hat, sachez qu’il est maintenu par des bénévoles et n’avait pas de mise à jour disponible le jour même. Pour PHP 7.4, 8.0 ou 8.1, le projet PHP fournit seulement des correctifs minimaux à compiler soi-même : la vraie solution reste la migration vers PHP 8.4 ou 8.5, après un test des thèmes et extensions sur un site de préproduction.

Impossible de mettre à jour tout de suite ?

Le projet PHP propose des réglages qui réduisent la surface d’attaque, sans la supprimer. Ils se placent dans php.ini ou dans la configuration du pool PHP-FPM, jamais via ini_set() ou un fichier .user.ini, qui interviennent trop tard.

ini

; Désactive le chemin d'attaque par la progression d'envoi de session
session.upload_progress.enabled = 0

; PHP 8.5 uniquement : désactive les traces des erreurs fatales
fatal_error_backtraces = 0

; Limite la taille des requêtes (32M si le site reçoit des fichiers)
post_max_size = 8M
upload_max_filesize = 6M

Redémarrez ensuite tous les processus PHP. Le projet PHP suggère aussi de lever la limite de mémoire (memory_limit = -1, imposée via php_admin_value), mais ce réglage expose le serveur à des requêtes qui consomment toute sa mémoire. Le CERT-FR recommande par ailleurs de bloquer ou de surveiller les requêtes de type multipart au niveau du serveur web ou d’un pare-feu applicatif, au prix de casser les formulaires d’envoi de fichiers. Évitez enfin les limites système RLIMIT_AS et RLIMIT_DATA, qui peuvent déclencher la faille.

Après le correctif : chercher des traces d’intrusion

Mettre à jour ferme la porte, mais ne dit pas si quelqu’un est déjà entré. Puisque des tentatives remontent au 17 octobre, une vérification s’impose sur les serveurs restés exposés.

Commencez par conserver les journaux avant toute modification. Recherchez ensuite les fichiers PHP créés ou modifiés depuis le 17 octobre, les tâches planifiées inattendues et les comptes inconnus :

bash

# Fichiers PHP modifiés depuis le 17 octobre dans le dossier du site
sudo find /var/www -name "*.php" -newermt "2026-10-17" -ls

# Tâches planifiées du compte qui fait tourner PHP
sudo crontab -l -u www-data

Wiz cite plusieurs signaux d’attaque : des requêtes multipart inhabituelles suivies d’erreurs de mémoire ou d’erreurs 500 répétées, des cookies de session PHPSESSID anormalement longs ou mal formés, et des redémarrages inexpliqués de processus PHP. Les journaux de l’application peuvent rester muets, puisque l’attaque se joue sous le code du site. Sur WordPress, vérifiez aussi la liste des administrateurs et appliquez les réflexes de sécurité habituels, comme le changement des mots de passe et des clés de sécurité.

Dernier point, côté visiteurs : les coupures de sites publics sont propices aux arnaques. Des messages imitant une préfecture ou les impôts peuvent circuler en profitant de la confusion. Mieux vaut taper soi-même l’adresse officielle en .gouv.fr plutôt que de cliquer sur un lien reçu par SMS ou e-mail, un réflexe détaillé dans notre article sur le phishing.

Après PHP2Shell, des serveurs oubliés et d’autres failles en embuscade ?

La PHP Foundation a annoncé une équipe dédiée à la sécurité de l’écosystème, un processus de décision plus rapide et l’usage systématique d’outils d’IA pour auditer son code, dont Claude Mythos et Daybreak Red d’OpenAI. Elle appelle aussi les entreprises et les administrations qui vivent de PHP à financer ce travail.

Le plus dur reste à venir. Des centaines de milliers de serveurs tournent sur des versions que plus personne ne corrige, et l’expert en analyse forensique Hal Pomeranz prévient déjà : « Il y aura une longue traîne pour celle-ci. » Avec des modèles d’IA capables de transformer une vieille faille en attaque en quelques semaines, combien d’autres défauts dorment encore dans le code qui fait tourner le web ?