Cybersécurité · 27 octobre 2026 · L'équipe NgNeer

Failles PHP2Shell : sans correctif hors support, isoler puis migrer

Le CERT-FR constate des tentatives d'exploitation des failles PHP2Shell. Les branches PHP 5 à 8.1 restent sans correctif. Les DSI doivent décider de l'inventaire, de l'isolation, de la migration et des clauses de contrat.

À retenir

  • Le CERT-FR a publié le 21 octobre 2026 une alerte sur CVE-2026-109618 et CVE-2026-109619, deux failles PHP qui permettent d'exécuter du code à distance. Depuis le 26 octobre, il constate des tentatives d'exploitation.
  • Les correctifs ne couvrent que les branches 8.2 à 8.5 (versions 8.2.35, 8.3.36, 8.4.27 et 8.5.12). Les branches 5.x à 8.1.x, hors support, doivent être isolées puis migrées.
  • L'inventaire doit aussi couvrir les conteneurs, les produits tiers qui embarquent PHP et les installations gérées par des hébergeurs. Les contrats de ces hébergeurs gagnent à fixer une branche PHP maintenue.

Le 21 octobre 2026, le CERT-FR a publié une alerte sur deux vulnérabilités du moteur PHP, CVE-2026-109618 et CVE-2026-109619. Surnommées PHP2Shell, elles permettent d'exécuter du code arbitraire à distance. Les correctifs sont sortis le jour même, mais seulement pour les branches encore maintenues. Pour les installations en PHP 5, 7, 8.0 ou 8.1, il n'y a aucun correctif à appliquer. Le CERT-FR recommande de les isoler, puis de migrer. Plusieurs organisations publiques et privées ont coupé leurs sites le temps de faire le tri.

Ce que dit l'alerte du CERT-FR, mise à jour le 26 octobre

Le bulletin CERTFR-2026-ALE-014 sépare les versions en deux groupes. Les branches 5.x, 7.x, 8.0.x et 8.1.x sont affectées en totalité, et l'éditeur n'en assure plus le support. Les branches 8.2 à 8.5 ne sont affectées qu'en deçà des versions corrigées : 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Le Monde Informatique rapporte un score CVSS de 9,2 pour les deux failles, exploitables sans identifiants.

La menace s'est précisée en quelques jours. Le 22 octobre, le CERT-FR avait connaissance de preuves de concept « pour des déploiements spécifiques de PHP ». Le 26, il constate des tentatives d'exploitation. Selon LeMagIT, l'équipe de renseignement sur les menaces d'Amazon en avait relevé dès le 17 octobre, avant la sortie des correctifs. Une troisième faille, CVE-2026-115560, a fait l'objet d'un avis de PHP le 23 octobre. L'éditeur juge son exploitation peu probable et renvoie son correctif au prochain cycle de mises à jour.

Hors support, la migration reste la seule issue

Pour une application restée en PHP 7.4 ou 8.1, il n'y a pas d'échappatoire. LeMagIT écrit que les correctifs sont disponibles « mais uniquement pour les versions supportées ». Le Monde Informatique résume que les branches 8.1 et antérieures n'ont pas d'autre option que la migration. Le CERT-FR fixe l'ordre : isoler les équipements affectés, puis migrer vers une version maintenue qui intègre les derniers correctifs. L'isolation fait gagner du temps, mais ne corrige rien.

Situation de l'application Exposition selon l'alerte Décision à prendre
Branche 8.2 à 8.5, version corrigée Hors du périmètre des deux CVE Vérifier la version réellement déployée, suivre CVE-2026-115560
Branche 8.2 à 8.5, version antérieure au correctif Affectée Mettre à jour dans la prochaine fenêtre de changement
Branche 5.x à 8.1.x Affectée, sans correctif Isoler, puis financer la migration
PHP embarqué dans un produit tiers Selon la version intégrée Obtenir une réponse écrite de l'éditeur

Quitter une branche ancienne impose des tests de non-régression, et parfois une reprise du code, des extensions ou du CMS. Il faut aussi un budget, rarement prévu pour ce trimestre. Le sujet sort alors de l'exploitation et devient un arbitrage de direction.

L'isolation fait gagner du temps, mais ne corrige rien.

Un inventaire qui va au-delà des serveurs web connus

L'alerte rappelle que PHP « est utilisé dans de nombreux produits ». Selon Le Monde Informatique, des produits commerciaux et open source l'embarquent sans que les équipes informatiques le sachent toujours. Une console d'administration d'équipement, une appliance métier, un intranet installé par un prestataire parti depuis : ces cas manquent souvent dans la liste tenue par l'équipe web.

Le même article demande de vérifier aussi les conteneurs, les dépendances logicielles et les installations gérées par des hébergeurs. Une image de conteneur construite sur une base ancienne peut embarquer une branche hors support, même si les serveurs sont à jour. Pour un site infogéré, la version installée dépend de l'offre souscrite. La DSI ne la connaît souvent que si elle la demande. Le Monde Informatique juge particulièrement exposées les entreprises qui n'ont pas d'inventaire fiable de leurs actifs.

Isoler, contourner, surveiller : les arbitrages des prochains jours

Couper un service exposé reste la mesure la plus sûre. LeMagIT cite Orange, qui a suspendu certains services le temps de déployer les correctifs et de faire les vérifications. Il cite aussi plusieurs préfectures, Météo France, la CNIL, Santé publique France et l'Ademe, qui ont fermé temporairement leurs sites. L'arbitrage se fait application par application : un site vitrine peut rester hors ligne quelques jours, un portail de paiement beaucoup moins. Pour les cas intermédiaires, le CERT-FR décrit deux contournements provisoires, qu'il dit ne pas avoir qualifiés. Le premier consiste à désactiver le suivi de progression des téléversements dans PHP, et ne vaut que pour CVE-2026-109619. Le second consiste à bloquer les requêtes HTTP de type multipart, par exemple sur un pare-feu applicatif, ou à défaut à les surveiller. Ce blocage peut gêner l'envoi de fichiers par formulaire : il se décide avec les métiers.

Le risque réel dépend aussi de la configuration. Pour le chercheur Daniel Card, cité par LeMagIT, une exploitation fiable et à grande échelle est difficile. Pour une large part du web, la menace se limiterait à un déni de service, selon la façon dont PHP est exécuté. Cette analyse aide à fixer les priorités, mais ne dispense pas de traiter les versions sans correctif. En cas de doute sur une compromission, l'alerte renvoie à la fiche réflexe du CERT-FR sur l'endiguement d'une compromission d'équipement de bordure réseau.

Ce que laisse une tentative ratée Selon LeMagIT, une exploitation qui échoue provoque des plantages de workers, des erreurs 500 et des processus redémarrés en boucle, avec des traces dans les journaux. Si ces signaux augmentent brusquement sur un serveur PHP exposé, il faut les analyser avant toute remise en service.

Faire de la version PHP un sujet de contrat et de budget

La crise révèle une dette que beaucoup de DSI connaissaient sans l'avoir chiffrée. Pour les semaines qui viennent, les décisions se suivent :

  1. Tenir un inventaire unique des composants PHP, avec la branche et la version, conteneurs, produits tiers et sites hébergés compris.
  2. Demander par écrit à chaque hébergeur, infogérant et éditeur la version déployée, la date d'application des correctifs et le plan de migration des branches hors support.
  3. Classer chaque application selon sa branche et son exposition, et documenter chaque décision d'isolation ou de maintien en ligne.
  4. Chiffrer les migrations des branches 5.x à 8.1.x et les inscrire au budget, avec un calendrier partagé avec les métiers.
  5. Lancer une revue de sécurité des services exposés, en commençant par ceux restés en ligne pendant la crise.

Dans bien des contrats, rien n'oblige l'hébergeur ou l'infogérant à rester sur une branche PHP supportée, ni à prévenir le client quand elle sort du support. Au prochain renouvellement, une clause peut fixer la branche minimale, le délai d'application des correctifs critiques et un préavis avant toute fin de support. Pour les produits qui embarquent PHP, la question se pose aussi à l'éditeur : sous quel délai livre-t-il une version qui intègre les correctifs du 21 octobre, et que prévoit-il pour CVE-2026-115560 ?

Sources

Avant d'engager un budget, l'audit d'infrastructure de NgNeer établit l'inventaire des composants PHP, y compris embarqués ou hébergés. Il chiffre les scénarios d'isolation et de migration. Audit d'infrastructure