Faille PHP2Shell : comment elle a été trouvée et comment protéger votre site

Que s'est-il passé avec PHP fin octobre ?

Le projet PHP a publié le 21 octobre 2026 les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35, qui corrigent deux failles critiques permettant d'exécuter du code à distance sans être connecté. Les chercheurs les ont baptisées PHP2Shell, parce qu'une simple requête bien construite peut suffire à obtenir un accès au serveur.

PHP, c'est le langage qui tourne derrière une grande partie du Web : WordPress, PrestaShop, Drupal, Joomla, Laravel, Symfony, et une foule d'outils métier développés sur mesure. Selon W3Techs, il est utilisé par 69,2 % des sites dont on connaît le langage côté serveur. Autant dire qu'une faille dans PHP lui-même, et pas dans une extension ou un thème, concerne énormément de monde.

Le calendrier a été chaotique. Le 20 octobre, des informations ont fuité avant la date prévue, dont une partie était d'ailleurs fausse. L'équipe de PHP a alors annoncé une version d'urgence pour le lendemain, 14 h (heure UTC). Dans la foulée, le CERT-FR, le centre d'alerte de l'ANSSI, a publié son alerte CERTFR-2026-ALE-014, mise à jour plusieurs fois depuis. Le 26 octobre, l'agence américaine CISA a ajouté les deux failles à son catalogue des vulnérabilités activement exploitées.

Pour un non-développeur, retenez ceci : ce n'est pas votre code qui est en cause, c'est le moteur sur lequel il tourne. Un site parfaitement entretenu peut être vulnérable si le serveur n'a pas été mis à jour.

Comment cette faille PHP a-t-elle été découverte ?

Le défaut avait été entrevu dès 2024, sans qu'on trouve comment l'exploiter. Il a été redécouvert à l'été 2026 par plusieurs équipes de chercheurs, en partie avec l'aide d'outils d'intelligence artificielle, puis signalé discrètement à PHP pour laisser le temps de préparer un correctif.

L'histoire est instructive. Selon le récit publié par ActuIA, un développeur du cœur de PHP avait repéré dès 2024, pendant un audit de sécurité externe, les premiers signes d'un problème dans la gestion des erreurs de mémoire épuisée. Faute de scénario d'attaque concret, et faute d'accord au sein de l'équipe, la correction a traîné. La PHP Foundation a elle-même qualifié ce retard d'échec structurel.

Le sujet est revenu par plusieurs portes à la fois :

• Fin juillet 2026, la société de recherche Calif lance un audit de PHP dans le cadre d'un programme de sécurisation des logiciels libres soutenu par OpenAI.
• Le 11 août, un chercheur de Calif signale une exécution de code à distance. Le même jour, l'équipe Codex Security d'OpenAI rapporte la même cause.
• Fin août, Wiz Research, qui avait trouvé les failles de son côté, signale d'autres façons de les exploiter et confirme des attaques possibles sur Drupal puis WordPress.

Les avis officiels publiés sur GitHub créditent ces différentes équipes. Ce qui frappe, c'est la place de l'IA. Calif explique ne pas s'attendre à trouver grand-chose, tant PHP avait déjà été passé au crible, y compris par des audits assistés par IA. Wiz affirme de son côté que la démonstration complète, presque hors de portée d'un humain seul selon l'entreprise, a été bouclée en une semaine par un seul chercheur aidé de modèles d'IA. C'est leur version, et elle n'a pas été vérifiée de façon indépendante, mais la tendance est nette.

Les outils d'IA qui aident à trouver les failles pour les corriger aident aussi ceux qui veulent les exploiter.

C'est d'ailleurs ce qui m'inquiète le plus dans cette affaire : le délai entre la publication d'une faille et les premières attaques se compte désormais en heures. La société watchTowr a vu des tentatives d'exploitation sur ses serveurs pièges dès le jour du correctif, et Datadog rapporte qu'AWS avait observé des tentatives dès le 17 octobre, avant même la publication.

Quel impact sur les sites internet ?

Potentiellement énorme, parce que PHP est partout, mais très variable d'un site à l'autre. Un serveur à jour et bien hébergé ne risque plus rien sur ces failles ; un serveur oublié sous une vieille version de PHP est une porte ouverte.

Si un attaquant réussit à exploiter PHP2Shell, il peut exécuter ses propres commandes sur le serveur. Concrètement, cela peut vouloir dire :

Il faut quand même garder la tête froide. Rapid7 indique que les preuves de concept qui circulent ne fonctionnent que sur des combinaisons précises de système, de version et de serveur web, et qu'aucune n'est fiable partout. Mais le CERT-FR a observé des tentatives d'exploitation ciblant certains déploiements, et des balayages larges et automatisés ont été signalés. Les attaquants testent tout ce qui répond, pas seulement les grands sites.

L'impact a aussi été très concret côté organisations. ActuIA rapporte que le ministère de l'Intérieur a mis ses sites exposés en maintenance, et l'agence américaine de cybersécurité a conseillé aux administrateurs qui ne pouvaient pas mettre à jour de couper temporairement leurs serveurs. Les grands hébergeurs, de leur côté, ont déployé les correctifs et des filtres en urgence.

Comment savoir si mon site est concerné par la faille PHP ?

Votre site est concerné s'il utilise PHP pour afficher ses pages et que la version de PHP est antérieure à 8.2.35, 8.3.36, 8.4.27 ou 8.5.12. Tout dépend ensuite de votre type d'hébergement : sur un hébergement mutualisé, c'est l'hébergeur qui corrige ; sur un serveur à vous, c'est à vous de le faire.

Premier réflexe : regarder la version réellement utilisée par le site. Dans WordPress, l'écran Outils › Santé du site › Informations › Serveur l'indique. Chez la plupart des hébergeurs, le panneau de gestion affiche la version de PHP choisie pour chaque site.

Attention à un piège classique : sur un serveur, la commande php -v donne la version de PHP en ligne de commande, qui n'est pas forcément celle qui sert les pages web. Et certaines distributions Linux appliquent le correctif sans changer le numéro de version visible. Dans ce cas, c'est l'avis de sécurité de la distribution qui fait foi.

Un dernier chiffre pour mesurer le problème : d'après W3Techs, plus d'un site PHP sur trois tourne encore sous PHP 7 ou PHP 5, des versions qui ne reçoivent plus de mise à jour officielle depuis longtemps. Si votre site en fait partie, cette faille est le bon moment pour régler la question une bonne fois pour toutes.

Comment corriger la faille PHP2Shell sur un serveur ?

La seule vraie correction est la mise à jour de PHP vers 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 (ou une version plus récente), suivie du redémarrage de tous les processus PHP. Les réglages de configuration qui circulent réduisent le risque, mais l'équipe de PHP rappelle qu'ils ne rendent pas le serveur sûr.

Voici la méthode que je suis sur un serveur Linux classique :

1. Faire l'inventaire. Lister tous les sites et toutes les versions de PHP installées, y compris les vieilles versions oubliées et celles qui tournent dans des conteneurs.
2. Sauvegarder. Fichiers, base de données et configuration, avant de toucher à quoi que ce soit.
3. Mettre à jour les paquets depuis la source utilisée sur le serveur : dépôt de la distribution, dépôt de Sury sur Debian et Ubuntu, ou images Docker officielles. Le dépôt Remi, très utilisé sur les serveurs Red Hat, n'avait pas été mis à jour le jour même.
4. Redémarrer PHP. Tant que les anciens processus tournent, l'ancien code reste en mémoire. Il faut redémarrer PHP-FPM, ou Apache si PHP y est intégré.
5. Vérifier. Contrôler la version servie par le site et le changelog du paquet, puis tester les pages importantes : formulaires, paiement, espace client.

Sur Debian ou Ubuntu avec PHP-FPM, cela ressemble à ceci (à adapter à votre version) :

sudo apt update
apt list --upgradable | grep php
sudo apt install --only-upgrade 'php8.3*'
sudo systemctl restart php8.3-fpm
php-fpm8.3 -v

Et si le site tourne encore sous PHP 7.4, 8.0 ou 8.1 ? PHP a publié des correctifs minimaux pour ces branches, réservés à ceux qui compilent PHP eux-mêmes, et certains éditeurs de distributions à support long les reprendront. Mais ce n'est qu'un sursis. Le CERT-FR recommande clairement de migrer vers une version maintenue. C'est souvent là que le travail commence vraiment : un vieux thème ou une vieille extension qui refuse PHP 8, un développement maison à adapter, des fonctions dépréciées à remplacer. Rien d'insurmontable, mais il vaut mieux le faire posément que dans l'urgence.

Que faire si vous ne pouvez pas mettre à jour PHP tout de suite ?

Isoler le site si c'est possible, et appliquer les réglages temporaires recommandés par PHP et le CERT-FR. Ils compliquent nettement l'attaque, mais ils ne remplacent pas la mise à jour, qui doit rester la priorité.

Les mesures recommandées par l'avis officiel de PHP sont à placer dans le fichier php.ini ou dans la configuration du pool PHP-FPM, pas dans le code du site ni dans un fichier .user.ini : elles arriveraient trop tard.

; mesures temporaires PHP2Shell (avis php.net du 21/10/2026)
session.upload_progress.enabled = 0
post_max_size = 8M        ; 32M si le site reçoit des fichiers
memory_limit = -1         ; idéalement via php_admin_value
; PHP 8.5 uniquement :
fatal_error_backtraces = 0

Ensuite, redémarrer tous les processus PHP. Quelques précisions utiles :

• La limite de mémoire illimitée supprime le chemin d'attaque connu de la première faille, mais un serveur peut toujours manquer de mémoire. Il faut alors compenser par une limite au niveau du conteneur ou du serveur, sans utiliser les limites système RLIMIT_AS ou RLIMIT_DATA, que PHP déconseille explicitement.
• Un pare-feu applicatif (Cloudflare, le filtre de votre hébergeur, un proxy bien configuré) peut bloquer une partie des requêtes malveillantes en amont. Cloudflare a déployé des protections, mais vérifiez ce que votre outil inspecte réellement.
• Masquer les erreurs ne protège de rien : la faille ne dépend pas de ce qui est affiché à l'écran.

Comment savoir si votre site a déjà été attaqué ?

En cherchant des signes précis dans les journaux du serveur et dans les fichiers du site. Mettre à jour ferme la porte, mais ne chasse pas un intrus déjà entré : si le serveur est resté exposé plusieurs jours, la vérification fait partie de la correction.

Les équipes de Datadog et de Rapid7 ont publié les signes à surveiller. Les principaux, traduits en langage courant :

• Des erreurs de mémoire épuisée en rafale dans les journaux PHP, souvent avec la mention « Unknown on line 0 », ou des plantages répétés des processus Apache (code AH00052). Une attaque peut ne laisser que deux à quatre lignes.
• Des envois de formulaires anormaux : énormément de champs, des noms très imbriqués, des champs inhabituels comme PHP_SESSION_UPLOAD_PROGRESS, ou des noms de fichiers contenant du code.
• Des cookies de session anormalement longs renvoyés par le serveur.
• Un processus PHP qui lance un terminal ou se connecte à l'extérieur : c'est le signe le plus grave.
• Des fichiers PHP récents que personne n'a déposés, dans les dossiers d'images ou de téléchargements.

Rapid7 rappelle un point important : l'absence de traces ne prouve pas qu'un serveur est sain, surtout si les journaux sont conservés peu de temps. En cas de doute sérieux, la démarche prudente consiste à changer les mots de passe (base de données, accès FTP et SSH, comptes administrateurs), à comparer les fichiers du site avec une version saine, et dans les cas graves à reconstruire le serveur à partir d'une sauvegarde antérieure à l'attaque.

Ce que PHP2Shell change pour la sécurité des sites en 2026

Cette affaire confirme qu'un site internet n'est jamais « fini » : le serveur et le langage qui le font tourner doivent être suivis et mis à jour, et ce suivi doit être plus rapide qu'avant, parce que l'IA accélère autant la découverte des failles que leur exploitation.

Honnêtement, je n'ai pas été surpris par la faille elle-même. Les logiciels complexes ont des défauts, et PHP a été correctement réactif une fois l'alerte donnée. Ce qui change, c'est le rythme. Quand des modèles d'IA aident à trouver en une semaine ce qui demandait des mois, il faut s'attendre à des alertes plus fréquentes, et à des attaques qui démarrent le jour même.

Pour une entreprise, j'en tire trois leçons simples :

1. Savoir qui s'occupe du serveur. Beaucoup de dirigeants ne savent pas si c'est l'hébergeur, l'agence qui a fait le site, ou personne. Le jour d'une alerte, ce flou coûte cher.
2. Ne pas laisser vieillir la version de PHP. Passer d'une version maintenue à la suivante est un petit chantier régulier. Rattraper cinq ans de retard en pleine urgence est un gros chantier stressant.
3. Avoir des sauvegardes vérifiées et une surveillance minimale. Savoir restaurer un site en une heure change complètement la gravité d'un incident.

L'IA n'est pas que du côté des attaquants : bien utilisée, elle aide aussi à relire du code, repérer des configurations risquées ou trier les alertes. C'est un sujet que j'aborde dans mes projets d'agents IA pour les entreprises et d'automatisation, avec toujours la même règle : un humain valide ce qui compte.

Faire vérifier et corriger votre site par un développeur

Si vous ne savez pas quelle version de PHP fait tourner votre site, ou si vous n'avez pas la main sur le serveur, je peux m'en charger : diagnostic, mise à jour, migration vers une version maintenue et vérification de l'absence d'intrusion, avec un devis gratuit sous 24 h.

Je développe des sites et des applications en PHP depuis une vingtaine d'années et j'administre moi-même des serveurs qui hébergent des sites et des applications en production. Pour ce type d'intervention, voici ce que je propose aux professionnels :

Pour éviter de revivre ça à la prochaine alerte, l'hébergement, les sauvegardes, les mises à jour de sécurité et le support sont aussi proposés en forfait mensuel, sans engagement : vous savez qui s'occupe de votre serveur, et c'est fait le jour même quand une faille sort. C'est ce que je mets en place pour les sites que je crée (voir la création de site internet) et pour les applications et CRM sur mesure.

Le plus simple : envoyez-moi l'adresse de votre site par le formulaire de contact ou appelez le 06 37 29 19 67. Je vous dis rapidement s'il est exposé et ce qu'il faut faire, que vous me confiiez la suite ou non.

Vos questions

Article publié le 27 octobre 2026.