Deux failles dans PHP permettent d'exécuter du code sur un site pourtant à jour

PHP est le langage qui fait tourner une grande partie du web. Quand un visiteur ouvre une fiche produit sur une boutique en ligne, le serveur transmet la demande à un processus PHP, qui lit les fichiers du site, interroge la base de données et renvoie la page. La faille se trouve dans PHP lui-même. Elle concerne CVE-2026-109618 et CVE-2026-109619 (un CVE est l'identifiant public d'une vulnérabilité connue), que les chercheurs surnomment PHP2Shell, du nom de la ligne de commande qu'un attaquant obtient sur la machine.

Concrètement, l'attaquant envoie à une page du site une requête web piégée. Dans le premier cas, PHP manque de mémoire et nettoie des données qu'il n'avait préparées qu'à moitié. Dans le second, il garde en mémoire un élément qu'il aurait dû oublier, et la requête suivante le réutilise. À l'arrivée, l'attaquant exécute du code avec les droits du serveur web, c'est-à-dire ceux du compte système sous lequel tourne le site, sans avoir besoin du moindre mot de passe. Avec ces droits, il peut lire la base de données d'une boutique, donc les commandes et les adresses des clients, ou y ajouter un script qui copie les numéros de carte sur la page de paiement. Un pare-feu applicatif ou une extension de sécurité n'arrête pas l'opération : l'attaque passe avant que le code du site ne s'exécute.

Correctifs publiés le 21 octobre, exploits publics deux jours plus tard

Les versions à jour sont 8.5.12, 8.4.27, 8.3.36 et 8.2.35, comme le détaille l'annonce officielle de l'équipe PHP. Toutes les versions antérieures qui servent des requêtes web sont concernées, y compris les branches en fin de vie jusqu'à PHP 5, qui ne recevront aucun correctif. Les deux failles obtiennent 9,2 sur 10 au barème CVSS 4.0 (Common Vulnerability Scoring System), l'échelle qui mesure la gravité d'une vulnérabilité. Ce score dit qu'une faille est grave et facile à exploiter. Un site qui tourne sur une version non corrigée est donc exposé, ce qui ne signifie pas qu'il a été piraté. La publication était prévue le 22 octobre ; une fuite survenue le 20 a obligé l'équipe à avancer l'annonce d'un jour, et les sources consultées n'en précisent pas l'origine. Les hébergeurs ont eu un jour de moins pour se préparer.

L'agence de cybersécurité singapourienne CSA (Cyber Security Agency) signale des tentatives d'exploitation à grande échelle et plusieurs exploits de démonstration publics dès le 23 octobre. Le cabinet Wiz, qui a participé à la découverte avec Calif.io, OpenAI et Quarkslab sans que le rôle de chacun soit détaillé, compare la portée potentielle à celle de Heartbleed (2014, une faille d'OpenSSL qui permettait de lire la mémoire de serveurs) et de Log4Shell (2021, une faille d'une bibliothèque Java très répandue, exploitable à distance). PHP ferait tourner environ 70 % des sites web, ce qui mesure une part de marché et non un nombre de sites compromis. Shodan, le moteur de recherche qui recense les machines accessibles depuis Internet, compte de son côté près de 884 000 hôtes exposés dont la réponse annonce PHP 8.1 ou une version plus ancienne, sans correctif à venir.

Le correctif ne s'installe pas depuis l'administration du site

Les fils de support WordPress et PrestaShop se remplissent de questions sur le patch à installer. L'équipe PrestaShop répond dans une note publiée le 21 octobre : il n'y a aucun patch PrestaShop à installer. La correction est une mise à jour de PHP, que l'hébergeur effectue dans la plupart des cas, puis un redémarrage des processus PHP pour que la nouvelle version soit réellement chargée. Un site WordPress ou PrestaShop à jour reste donc vulnérable si le serveur qui l'exécute ne l'est pas.

Ce qu'il faut relever pour chaque site

Le premier relevé est la version exacte de PHP. Celle qu'affiche la page d'accueil du panneau d'hébergement n'est pas toujours celle qui sert le site ; un fichier de test qui appelle phpversion() donne la réponse en dix secondes. Le second est le mode d'exécution, qui décide du chemin d'attaque. Avec mod_php, PHP est intégré au serveur Apache, c'est la configuration la plus risquée. Avec PHP-FPM, PHP tourne comme un service séparé auquel le serveur web transmet les requêtes. FrankenPHP (un serveur web qui embarque PHP), php-cgi et LiteSpeed sont également touchés.

Reste à savoir qui peut changer la version, et quand. Sur un mutualisé, la décision appartient à l'hébergeur. Sur un serveur dédié ou un conteneur, elle revient à celui qui exploite la machine, et sur un conteneur il faut reconstruire l'image, relancer le service ne suffit pas. Même une version à jour sur le disque peut rester inactive : avec PHP-FPM, un paquet mis à jour ne recharge pas forcément le nouveau programme, et l'ancien reste en mémoire tant que le service n'a pas été redémarré.

Passer de PHP 8.1 à 8.3 peut casser un module mal écrit, un thème ou une dépendance abandonnée. Cette crainte explique pourquoi des hébergeurs retardent la migration, et pourquoi la faille trouve des serveurs à prendre. La question à poser est donc de savoir combien de temps un site peut rester sur une version qui ne reçoit plus de correctifs.

Ce que l'on ne sait pas encore

Personne ne publie de décompte fiable des sites réellement touchés, et les hébergeurs mutualisés communiquent peu. Certains annoncent un correctif appliqué au niveau du système sans dire si les processus ont été relancés, ce qui laisse le doute entier.

Le rapport de XM Cyber, un éditeur de solutions de cybersécurité, affirme que des modèles d'IA de pointe ont aidé les chercheurs à trouver les failles. L'entreprise a un intérêt commercial à décrire une menace qui s'accélère, et aucun détail méthodologique public ne permet de mesurer la part réelle de ces outils. Si l'affirmation se confirme, des failles anciennes, que l'on ne trouvait autrefois que par hasard, pourraient être recherchées de façon systématique.

En attendant, une démarche simple s'impose pour un studio ou un indépendant : demander par écrit à l'hébergeur de chaque site la version de PHP en service, et la date et l'heure du dernier redémarrage des processus après le correctif. Une réponse datée vaut preuve ; une réponse vague indique qu'il faut relancer la question.