PHP2Shell : deux failles critiques de PHP trouvées grâce à l’IA, comment protéger son site

Le message publié sur le site officiel de PHP le 21 octobre 2026 tient en trois mots : « update now », mettez à jour maintenant. Le projet qui maintient ce langage, utilisé côté serveur par la grande majorité des sites web dont la technologie est connue, y annonce des correctifs pour deux failles critiques. Leur particularité tient autant à leur gravité qu’à la façon dont elles ont été découvertes : des chercheurs les ont dénichées avec l’aide de modèles d’intelligence artificielle, dans du code présent depuis plus de dix ans.

Que sont les failles PHP2Shell ?

Les deux vulnérabilités portent les identifiants CVE-2026-109618 et CVE-2026-109619. Chacune est notée 9,2 sur 10 sur l’échelle CVSS 4.0, le barème international qui mesure la gravité d’une faille informatique. Les chercheurs de la société de cybersécurité Wiz les ont surnommées PHP2Shell, en référence à un « shell », c’est-à-dire un accès en ligne de commande à la machine visée.

Le problème se situe dans le cœur du langage, pas dans un logiciel particulier. Selon l’avis de sécurité de PHP, la première faille vient de la gestion des erreurs de mémoire : quand un script dépasse la mémoire qui lui est allouée, PHP peut s’interrompre alors que certaines données internes ne sont qu’à moitié préparées, puis les traiter comme valides au moment du nettoyage. La seconde concerne des données internes qui survivent à la fin d’une requête alors que la mémoire correspondante a été libérée : la requête suivante, traitée par le même processus, peut alors les réutiliser.

Concrètement, un attaquant peut envoyer des requêtes spécialement préparées pour exécuter son propre code sur le serveur, sans compte ni mot de passe. Wiz affirme avoir démontré ces attaques contre des installations de WordPress, Drupal et Joomla, et précise qu’une simple page « Hello World » peut suffire à exposer un serveur, puisque la faille ne dépend pas de l’application.

Qui est concerné ?

L’avis du projet PHP vise toutes les installations qui répondent à des requêtes web : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le projet juge le risque le plus élevé avec mod_php, pour lequel une attaque a été démontrée avant même l’exécution du code de l’application. Selon Wiz, toutes les versions publiées depuis une dizaine d’années, en remontant jusqu’à PHP 5.4, sont touchées par au moins l’une des failles.

L’exposition est massive. D’après CyberScoop, les chercheurs estiment à plus de 1,3 million le nombre de serveurs accessibles sur Internet potentiellement vulnérables, et une recherche sur le moteur Shodan en recense environ 1,9 million. Parmi les serveurs qui affichent leur version, environ 758 000 tournent sur des branches de PHP qui ne sont plus maintenues, contre 272 000 sur des branches encore suivies, selon des chiffres de VirusTotal cités par le média.

Le projet PHP rappelle que les branches 8.1 et antérieures ne reçoivent plus de mises à jour. Son équipe de sécurité a toutefois publié, exceptionnellement, des correctifs minimaux pour PHP 7.4, 8.0 et 8.1, destinés à ceux qui compilent eux-mêmes le langage. Certaines distributions Linux et certains prestataires de support à long terme intègrent aussi ces corrections dans leurs propres paquets.

Comment l’IA a permis de les trouver

Selon le récit publié par Wiz, la première faille a été repérée le 19 août 2026 à l’aide de son outil maison Wiz Atlas et de deux modèles de pointe, Gemini 4 Argon de Google et GPT-5.6 Sol d’OpenAI. Le 20 août, les chercheurs confirmaient une prise de contrôle à distance d’un site Drupal, puis d’un site WordPress le 21 août. Le signalement à l’équipe de sécurité de PHP date du 24 août, et la publication coordonnée des correctifs a eu lieu le 21 octobre.

Wiz attribue au modèle de Google un rôle dans la découverte de la faille, la mise au point de l’attaque de démonstration, la détection des tentatives d’exploitation et la validation du correctif. Les modèles de langage ont aussi servi à adapter l’attaque aux différentes versions et configurations de PHP, en analysant chaque échec pour corriger le tir. Ce travail illustre les capacités que Google mettait en avant lors du lancement de Gemini 4 Argon, réservé d’abord aux spécialistes de la cyberdéfense.

Wiz n’est pas seul à revendiquer la découverte. Selon CyberScoop, OpenAI attribue la trouvaille initiale à Calif, une entreprise de cybersécurité qui a utilisé GPT-5.6 Sol, Wiz ayant découvert et signalé le problème de son côté. La découverte a donné lieu à deux mois de travail commun entre OpenAI, les mainteneurs de PHP, des chercheurs et des fournisseurs de sécurité.

Les grands laboratoires d’IA présentent depuis 2024 la recherche de failles comme un usage phare de leurs modèles, à l’image de l’agent Big Sleep de Google, qui avait trouvé une faille avant sa diffusion. PHP2Shell montre que ces outils peuvent désormais exhumer des erreurs vieilles de dix ans dans un logiciel parmi les plus examinés au monde.

Les failles sont-elles déjà exploitées ?

À la date de publication des correctifs, l’agence américaine de cybersécurité CISA indiquait ne pas avoir observé d’exploitation, selon CyberScoop. Plusieurs équipes de chercheurs signalaient seulement des activités de reconnaissance, c’est-à-dire des robots qui sondent les serveurs pour repérer les versions vulnérables. La société watchTowr affirme néanmoins avoir reproduit l’une des failles, et une vidéo de démonstration circule en ligne.

Le calendrier a d’ailleurs été accéléré. PHP avait publié un préavis le 20 octobre, annonçant les correctifs pour le 21 octobre à 14 heures (heure de Greenwich), en se réservant la possibilité d’agir plus tôt si des détails fuitaient ou si des attaques apparaissaient. Avec des modèles d’IA capables d’aider à écrire une attaque à partir d’un correctif publié, le délai entre l’annonce d’une faille et son exploitation tend à se réduire.

Attention aux faux outils : des codes d’attaque présentés comme des démonstrations circulent, et les sociétés de sécurité rappellent qu’ils peuvent contenir des logiciels malveillants. Il ne faut pas les exécuter pour « tester » son propre serveur.

Comment savoir si son site est vulnérable

La première étape consiste à connaître la version de PHP utilisée. Plusieurs méthodes existent selon la situation :

• Sur un serveur que l’on administre, la commande php -v affiche la version en ligne de commande. Attention, la version utilisée par le serveur web peut différer : une page temporaire appelant phpinfo(), à supprimer aussitôt après, donne la version réellement servie.
• Sur un site WordPress, le menu Outils, puis Santé du site, onglet Informations, section Serveur, indique la version de PHP.
• Sur un hébergement mutualisé, l’espace client de l’hébergeur affiche généralement la version de PHP choisie pour chaque site, et permet souvent d’en changer.

Si la version affichée est antérieure à 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 selon la branche, le site est concerné. Une version 8.1 ou plus ancienne l’est aussi, sauf si l’hébergeur ou la distribution a intégré les correctifs : seul le fournisseur peut le confirmer.

Que faire si la mise à jour est impossible tout de suite ?

Le projet PHP liste plusieurs réglages qui réduisent l’exposition à certaines attaques, tout en prévenant qu’ils ne rendent pas une installation sûre :

• fixer memory_limit=-1, de préférence dans la configuration du serveur (directive php_admin_value du pool FPM ou d’Apache) pour que les applications ne puissent pas l’annuler. Ce réglage supprime la limite de mémoire des scripts, ce qui expose à d’autres problèmes : il ne peut être que temporaire ;
• désactiver le suivi de progression des envois de fichiers avec session.upload_progress.enabled=0, puis redémarrer les processus PHP ;
• sur PHP 8.5, régler fatal_error_backtraces=0 ;
• abaisser post_max_size, par exemple à 8 Mo sur un site sans envoi de fichiers ou à 32 Mo avec.

Le projet précise que ces réglages ne doivent pas passer par ini_set() ni par un fichier .user.ini, et que masquer les messages d’erreur ne sert à rien. Selon Wiz, des fournisseurs de réseaux de diffusion comme Cloudflare, Fastly et Vercel ont aussi déployé des protections automatiques pour les sites qui passent par eux. Les autorités européennes et britanniques de cybersécurité, citées par CyberScoop, conseillent d’isoler les applications exposées sur Internet lorsque la correction immédiate n’est pas possible.

Enfin, Wiz recommande de surveiller dans les journaux du serveur les signes suivants : des envois de formulaires inhabituels suivis d’erreurs de dépassement de mémoire ou d’une série d’erreurs 500, des cookies de session PHPSESSID anormalement longs ou malformés, et des redémarrages inexpliqués des processus PHP.

Un signal pour toute la filière du logiciel

PHP2Shell concentre plusieurs tendances qui vont peser sur la sécurité des sites web. La première est l’accélération de la découverte de failles par l’IA : des erreurs restées invisibles pendant une décennie, malgré des milliers de contributeurs et d’audits, ont été trouvées en quelques semaines par des équipes équipées de modèles de pointe. Les défenseurs en profitent pour l’instant, mais rien ne garantit que les attaquants n’obtiendront pas les mêmes résultats à leur tour.

La seconde est le poids des logiciels vieillissants. Avec une majorité de serveurs visibles encore sous des versions de PHP sans support, une partie du web dépend du bon vouloir des distributions ou de correctifs publiés à titre exceptionnel. La fin de vie de PHP 8.2, fixée au 31 décembre 2026, rendra la question encore plus pressante pour les sites qui repoussent les migrations.

Pour les propriétaires de sites, la leçon est simple : connaître la version de PHP de chacun de ses sites, vérifier que l’hébergeur applique les correctifs et planifier une montée de version dès qu’une branche approche de sa fin de vie. Les autres articles de la rubrique cybersécurité d’Actu.ai suivent la façon dont l’IA transforme à la fois l’attaque et la défense.