PHP2Shell : ce que la faille PHP signifie pour ISO 27001 et NIS2

L'essentiel en bref

• PHP2Shell désigne deux vulnérabilités critiques de l'interpréteur PHP, CVE-2026-109618 et CVE-2026-109619, toutes deux notées 9,2 selon CVSS v4.0. Elles permettent à un attaquant d'exécuter du code sur un serveur web sans s'authentifier.
• Les failles sont corrigées dans PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Pour PHP 7.4 à 8.1, le projet PHP n'a publié que des correctifs de code source, et les versions plus anciennes ne reçoivent aucun correctif.
• L'office fédéral allemand de la sécurité informatique (BSI) a publié le 21 octobre 2026 une alerte de niveau « 3 / Orange ». Amazon a observé une première tentative d'exploitation dès le 17 octobre, quatre jours avant les correctifs.
• Sous NIS2, la vulnérabilité seule ne déclenche aucune notification. Si elle conduit à un incident important, une alerte précoce est due dans les 24 heures là où la directive est déjà transposée, comme en Allemagne.
• Dans un SMSI conforme à ISO 27001, la réponse relève de la mesure A.8.8 (gestion des vulnérabilités techniques). Lors du prochain audit, vous devez pouvoir montrer quels systèmes vous avez vérifiés et quand vous les avez corrigés.

Le 21 octobre 2026, le projet PHP a publié des mises à jour d'urgence pour deux failles critiques désormais connues sous le nom de PHP2Shell. Cette faille PHP ne se trouve pas dans un plugin ou un framework, mais dans l'interpréteur lui-même. Toute application qui tourne sous PHP est donc concernée : WordPress, Drupal, Typo3, Joomla, Magento, PrestaShop, Moodle et de nombreuses applications internes. Selon le BSI, la faille ne concerne pas seulement les sites web, mais aussi les pare-feu, répartiteurs de charge et autres équipements réseau dotés d'une interface web basée sur PHP.

En Allemagne, le BSI a parlé d'un « potentiel de menace exceptionnel ». Des universités, des administrations municipales et des hôpitaux ont mis leurs sites hors ligne par précaution, et la plupart étaient de nouveau accessibles le lendemain.

Cet article s'adresse aux responsables informatiques, aux RSSI et aux équipes conformité. Il explique ce qui s'est passé sur le plan technique, ce que vous devez faire maintenant et ce que PHP2Shell signifie pour les entreprises certifiées ISO 27001 ou concernées par NIS2.

Qu'est-ce que PHP2Shell ?

PHP2Shell est le nom donné à deux vulnérabilités de l'interpréteur PHP qui permettent à un attaquant d'exécuter son propre code sur un serveur web, à distance et sans identifiants. On parle d'exécution de code à distance (RCE). Un attaquant qui y parvient peut voler des données et des mots de passe, défigurer un site, déposer un logiciel malveillant ou utiliser le serveur pour d'autres attaques.

Les deux vulnérabilités

CVE-2026-109618 survient lorsque PHP manque de mémoire pendant le traitement d'une requête. La requête s'interrompt alors que certaines données internes ne sont que partiellement construites. La routine de nettoyage qui suit traite ces données incomplètes comme valides, et c'est là que l'attaque intervient.

CVE-2026-109619 concerne l'état entre deux requêtes. Des données internes d'une requête subsistent alors que la mémoire correspondante a déjà été libérée. Lorsque le même processus traite la requête suivante, il peut utiliser cet état obsolète avant qu'il ne soit réinitialisé.

Pourquoi votre application ne peut pas bloquer l'attaque

L'attaque se déroule avant même le démarrage de votre application. Les chercheurs en sécurité de Datadog ont reproduit les deux failles : une seule requête HTTP POST non authentifiée vers n'importe quel script PHP suffit, même si ce script se contente d'afficher une page.

Une page de connexion, un plugin de sécurité ou un code applicatif soigneusement audité ne protègent donc pas. Tous les modes d'exécution courants sont concernés : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. L'équipe PHP estime le risque le plus élevé pour mod_php.

Comment la situation a évolué

Selon Amazon Threat Intelligence, une première tentative d'exploitation a touché le réseau de honeypots d'Amazon dès le 17 octobre 2026, alors que les failles étaient encore sous embargo. Le 20 octobre, le projet PHP a annoncé les correctifs, après la fuite de détails techniques. Les versions corrigées sont parues l'après-midi du 21 octobre.

Selon Matthew Prince, PDG de Cloudflare, le nombre de tentatives d'exploitation a atteint des centaines de milliers dans les deux heures suivant la publication, puis des millions peu après. Les spécialistes s'attendent à ce que les attaques automatisées se poursuivent pendant des semaines, voire des mois. Au 22 octobre, le BSI indiquait n'avoir reçu aucun signalement de systèmes compromis dans les secteurs réglementés ou l'administration fédérale allemande, sans pour autant exclure des attaques réussies.

Quelles versions de PHP sont concernées

Toutes les versions de PHP antérieures aux mises à jour d'urgence du 21 octobre 2026 sont concernées, jusqu'à PHP 5. La protection d'un serveur dépend de sa branche de version et de la source de ses mises à jour.

Une idée reçue fréquente : le numéro de version ne suffit pas à savoir si un serveur est protégé. Les distributions Linux appliquent souvent les correctifs de sécurité par rétroportage, sans modifier la version de PHP affichée. Consultez donc les bulletins de sécurité de votre distribution, ou demandez à votre hébergeur de confirmer par écrit que les deux CVE sont corrigées.

Avant les correctifs, un conseil largement relayé consistait à désactiver session.upload_progress. Datadog a montré que cette mesure n'empêche pas l'attaque. Les nouvelles règles de pare-feu applicatif (WAF), comme celles que Cloudflare a déployées pour toutes ses offres, ne font que gagner du temps jusqu'à la mise à jour. Seul le correctif protège.

Ce que vous devez faire maintenant

La tâche la plus importante est d'obtenir une vue complète des endroits où PHP tourne dans votre entreprise. En pratique, il y a presque toujours plus de systèmes que l'équipe IT ne peut en citer de mémoire.

1. Établir un inventaire (jour 1, exploitation IT). Recensez chaque serveur, chaque image de conteneur et chaque offre d'hébergement qui utilise PHP. Pensez aux environnements de préproduction, aux anciens sites de campagne, à l'intranet et aux sites gérés par une agence. Cela inclut les pare-feu, répartiteurs de charge, NAS et autres équipements dotés d'une interface d'administration basée sur PHP. Pour ces équipements, la correction arrive sous forme de mise à jour du micrologiciel par le fabricant, et non de mise à jour de PHP.
2. Corriger ou obtenir une confirmation (jours 1 à 2, exploitation IT ou hébergeur). Installez les versions corrigées sur vos propres serveurs. Pour chaque site hébergé, faites-vous confirmer la correction par écrit.
3. Isoler les systèmes obsolètes (jours 1 à 2, direction informatique). Tout ce qui tourne sous PHP 8.1 ou une version plus ancienne et ne peut pas être mis à jour rapidement doit être mis hors ligne ou isolé. C'est notamment la recommandation du NCSC britannique. En attendant la mise à jour, les interfaces d'administration des pare-feu, NAS et autres équipements réseau ne doivent pas être accessibles depuis Internet.
4. Analyser les journaux (jours 2 à 3, sécurité). Examinez les journaux à partir du 17 octobre. Soyez attentif aux envois de formulaires très volumineux, aux erreurs de mémoire au début d'une requête, aux processus shell lancés par PHP, aux nouveaux comptes administrateur et aux modifications de fichiers inattendues.
5. Déclencher le processus de gestion des incidents (immédiatement en cas de soupçon, RSSI). En cas d'indices de compromission, votre processus de réponse aux incidents s'applique, y compris l'examen d'éventuelles obligations de notification.
6. Documenter (en continu, RSSI). Consignez quand vous avez eu connaissance de la faille, quels systèmes étaient concernés, quand vous avez corrigé et ce qu'a révélé l'analyse des journaux.

Une autre idée reçue concerne WordPress. De nombreux exploitants comptent sur les mises à jour automatiques. Celles-ci mettent à jour WordPress, les plugins et les thèmes, mais pas la version de PHP du serveur. La correction doit venir de l'hébergeur ou de l'exploitation des serveurs.

Ce que PHP2Shell signifie pour NIS2

Sous NIS2, la gestion des vulnérabilités est une obligation explicite. L'article 21, paragraphe 2, point e) de la directive exige des mesures de sécurité dans l'acquisition, le développement et la maintenance des systèmes, y compris le traitement et la divulgation des vulnérabilités. Vous trouverez une vue d'ensemble de toutes les obligations dans notre guide des exigences NIS2.

La situation en France

À la date du 22 octobre 2026, la France n'a pas encore transposé NIS2. Le projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité a été adopté par le Sénat en mars 2025, mais son examen en séance à l'Assemblée nationale a de nouveau été reporté début octobre 2026. Les obligations de NIS2 ne s'appliquent donc pas encore aux entreprises françaises au titre du droit national.

Cela ne rend pas le sujet théorique. Les entreprises françaises qui exercent des activités dans des États membres ayant déjà transposé la directive, comme l'Allemagne, y sont soumises. Et les opérateurs de services essentiels restent tenus par le régime NIS 1 de 2018, sous la supervision de l'ANSSI.

Notification : quand elle s'applique et quand elle ne s'applique pas

Beaucoup d'entreprises pensent devoir notifier PHP2Shell parce que leurs serveurs étaient vulnérables. Ce n'est pas le cas. Une vulnérabilité seule n'est pas un incident de sécurité. L'obligation de notification porte sur un incident important, par exemple si des attaquants ont exploité la faille pour voler des données ou perturber un service.

Dans ce cas, l'article 23 de NIS2 prévoit une alerte précoce dans les 24 heures suivant la prise de connaissance de l'incident important, une notification d'incident dans les 72 heures et un rapport final au plus tard un mois après cette notification. Analysez donc vos journaux sans attendre.

Les organes de direction sont responsables

NIS2 rend les organes de direction responsables de la mise en œuvre des mesures de gestion des risques en matière de cybersécurité. Face à une faille de cette ampleur, la direction générale doit savoir combien de systèmes étaient concernés et dans quel délai ils seront corrigés. Notre article sur les obligations NIS2 des dirigeants détaille ce que cela implique concrètement.

Ce que PHP2Shell signifie pour ISO 27001

Dans un SMSI fondé sur ISO 27001:2022, PHP2Shell met à l'épreuve plusieurs mesures de l'annexe A. Au centre se trouve A.8.8, la gestion des vulnérabilités techniques : vous devez obtenir à temps les informations sur les vulnérabilités, évaluer votre exposition et prendre les mesures appropriées.

D'autres mesures sont concernées. A.5.9 exige un inventaire des actifs, sans lequel vous ne savez pas partout où PHP tourne, y compris dans les équipements réseau. A.5.7 porte sur le renseignement sur les menaces, c'est-à-dire la rapidité avec laquelle vous avez eu connaissance de l'alerte. A.8.16 encadre la surveillance dont vous avez besoin pour analyser les journaux, et A.5.24 à A.5.28 couvrent la gestion des incidents. La façon dont ces mesures de l'annexe A d'ISO 27001 s'articulent est expliquée dans un article dédié.

Ce que les auditeurs voudront voir

Lors de votre prochain audit de surveillance, attendez-vous à la question de savoir comment votre entreprise a réagi à PHP2Shell. Un auditeur n'attend pas la perfection, mais un processus traçable : quand avez-vous eu connaissance de la faille ? Qui a évalué l'exposition ? Quels systèmes ont été corrigés, et dans quel délai ? Où est-ce documenté ?

Un exemple : une entreprise SaaS de 60 personnes fait tourner sa plateforme sous PHP 8.3 dans 14 images de conteneur, ainsi qu'un site marketing chez un hébergeur et un ancien portail client sous PHP 7.4. Les conteneurs sont mis à jour en six heures, et l'hébergeur confirme la correction du site le lendemain matin. L'équipe met le portail client hors ligne et planifie sa migration. Si chaque étape est consignée dans un ticket horodaté, la preuve pour A.8.8 se rassemble en quelques minutes. Sans ces tickets, l'équipe reconstitue le déroulé des semaines plus tard à partir de fils de discussion et de souvenirs.

RGPD : lorsque des données personnelles sont concernées

Le RGPD s'applique indépendamment de NIS2. Si des attaquants ont utilisé PHP2Shell pour accéder à des données clients, des mots de passe ou des coordonnées, il s'agit d'une violation de données à caractère personnel. Selon l'article 33 du RGPD, vous devez la notifier à l'autorité de contrôle compétente, en France la CNIL, dans les 72 heures, sauf si la violation n'est pas susceptible d'engendrer un risque pour les personnes concernées. Examinez cette question en parallèle de l'analyse technique, et non après.

Corriger et prouver les vulnérabilités sans collecter de captures d'écran

Après une faille comme PHP2Shell, il ne suffit pas de corriger : vous devez aussi pouvoir le prouver lors de l'audit. Kertos relie ces deux étapes grâce à l'intégration entre Aikido et Kertos. Aikido Security détecte les composants vulnérables dans le code, les images de conteneur et les environnements cloud. Kertos lit chaque jour ces résultats et leurs délais de correction puis enregistre le résultat comme preuve pour les exigences correspondantes d'ISO 27001, NIS2 et SOC 2.

Pour votre audit, cela signifie que la preuve de la date de détection et de correction d'une vulnérabilité naît là où le travail se fait. Les experts certifiés de Kertos vous aident à mettre en place vos processus de gestion des vulnérabilités et des incidents pour qu'ils tiennent face à la prochaine faille critique.

Si vous souhaitez voir comment cela fonctionne dans votre environnement, réservez une démo.

Questions fréquentes

Qu'est-ce que PHP2Shell ?

PHP2Shell est le nom de deux vulnérabilités critiques de l'interpréteur PHP, CVE-2026-109618 et CVE-2026-109619, toutes deux notées 9,2 selon CVSS v4.0. Elles permettent à un attaquant d'exécuter du code sur un serveur web sans s'authentifier. Le projet PHP a publié des versions corrigées le 21 octobre 2026.

Quelles versions de PHP sont concernées par PHP2Shell ?

Toutes les versions antérieures aux mises à jour d'urgence du 21 octobre 2026 sont concernées, jusqu'à PHP 5. PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 ou plus récentes sont protégées. PHP 7.4 à 8.1 ne reçoivent que des correctifs rétroportés par les distributions et les fournisseurs de support étendu, et les versions plus anciennes aucun correctif.

Mon site WordPress est-il concerné par la faille PHP ?

Oui, si le serveur utilise une version de PHP non corrigée. Les mises à jour automatiques de WordPress n'y changent rien, car elles ne mettent à jour que WordPress, les plugins et les thèmes. La version de PHP s'affiche sous Outils, Santé du site, Infos, Serveur, et la correction doit venir de votre hébergeur ou de l'exploitation des serveurs.

Dois-je notifier PHP2Shell au titre de NIS2 ?

Pas du seul fait que vos serveurs étaient vulnérables. L'obligation porte sur un incident important, comme une fuite de données ou une perturbation de vos services, dans les États membres où NIS2 est transposée. Une alerte précoce est alors due dans les 24 heures, une notification dans les 72 heures et un rapport final au plus tard un mois après cette notification.

Un pare-feu applicatif web protège-t-il contre PHP2Shell ?

Seulement de façon temporaire. Des fournisseurs comme Cloudflare ont déployé des règles contre les schémas d'attaque connus, qui font gagner du temps jusqu'à la mise à jour. Des variantes de l'attaque peuvent contourner ces règles, et seule la mise à jour de PHP protège durablement.