Rétrospective PHP2Shell : la sécurité logicielle au-delà des avis d’atteinte

Que s’est-il passé et comment?

Les deux vulnérabilités, CVE-2026-109618 et CVE-2026-109619, concernaient la gestion de la mémoire dans PHP.

Dans un cas, un manque de mémoire pouvait interrompre l’initialisation et laisser des données de requête invalides que les routines de nettoyage devaient traiter. Dans l’autre, un état interne pouvait subsister après la libération de la mémoire qui le contenait, permettant à une requête ultérieure d’interagir avec cet état périmé. Ces conditions pouvaient permettre l’exécution de code à distance. ^[1]

La faiblesse se situait dans l’environnement d’exécution sur lequel reposait l’application. Mettre à jour WordPress ou ses extensions, par exemple, ne permettait pas d’établir que l’installation PHP sous-jacente avait été corrigée.

Le calendrier a compliqué la réponse. Amazon a signalé une tentative d’exploitation contre son infrastructure de surveillance le 17 octobre, avant la divulgation publique, puis d’autres tentatives autour de la publication des correctifs. Ces observations n’établissaient pas la compromission réussie de chaque système ciblé, mais elles rendaient la période précédant la remédiation pertinente pour l’enquête. ^[2]

L’application de correctifs et l’enquête répondaient donc à des questions différentes. La première visait à déterminer si la vulnérabilité subsistait. La seconde examinait si un attaquant l’avait déjà exploitée.

La classification précède les conclusions sur les avis

Une vulnérabilité est une faiblesse susceptible d’être exploitée. Sa présence n’établit pas automatiquement un incident de confidentialité. Son exploitation peut néanmoins entraîner un accès non autorisé, une divulgation, une modification, une interruption de service ou d’autres conséquences.

Déterminer ce qui s’est produit exige de comprendre l’utilisation de la technologie touchée. PHP utilisé pour un site Web public présente un contexte factuel différent de PHP utilisé pour un portail documentaire ou une application reliée à des systèmes internes. Même un site Web public peut contenir des identifiants ou donner accès à autre chose que les pages visibles par les visiteurs.

Les renseignements concernés, leur sensibilité, les connexions du système et les éléments de preuve d’activité éclairent tous la classification.

Les contrats introduisent d’autres distinctions. Selon leur formulation, ils peuvent exiger un avis concernant une vulnérabilité importante, une menace potentielle pour la sécurité, une compromission soupçonnée, un incident de sécurité confirmé ou une atteinte à la confidentialité. Des obligations d’évaluation et d’application de correctifs peuvent s’appliquer indépendamment de ces avis.

Une organisation pourrait donc conclure qu’aucun incident de confidentialité n’a été identifié tout en étant tenue de transmettre un avis de vulnérabilité ou une mise à jour sur la remédiation.

Les spécialistes techniques établissent les faits et leurs limites. L’avocat en réponse aux incidents évalue ces conclusions au regard des définitions contractuelles, des exigences réglementaires et des délais applicables. L’analyse évolue à mesure que les éléments de preuve apparaissent; elle ne peut se réduire à la seule question de savoir si des renseignements personnels ont été volés.

Les pratiques connues de cybersécurité fournissent les faits juridiques

PHP2Shell a illustré l’importance de tenir des inventaires technologiques, de cartographier les dépendances et les flux d’information, et de vérifier que la maintenance est réellement effectuée.

Comme l’explique Jaspreet Kaur :

Il s’agit de disciplines établies en cybersécurité. Une divulgation critique révèle les conséquences de leur mise en œuvre incomplète.

Un inventaire utile relie une application à ses dépendances, à son responsable métier, à son fournisseur et à ses modalités de maintenance. La cartographie de l’information identifie ce qu’elle contient ou ce à quoi elle peut accéder. La cartographie contractuelle relie cet environnement aux obligations des fournisseurs et aux engagements pris envers les clients.

Sans ces liens, les équipes juridiques et de sécurité peuvent chacune ne détenir qu’une partie de la réponse. Le juriste peut connaître une clause de notification sans disposer des faits nécessaires pour l’appliquer. Les spécialistes de la sécurité peuvent comprendre la vulnérabilité sans savoir qu’un contrat client exige un avis avant même la confirmation d’une compromission.

Les dossiers doivent aussi rester à jour lorsque les applications, les fournisseurs et les engagements envers les clients changent.

La vérification diligente doit examiner la maintenance des logiciels

L’approvisionnement logiciel exige de comprendre comment un fournisseur identifie, évalue et corrige les vulnérabilités pendant toute la période de prise en charge de son produit.

Cet examen doit déterminer si le fournisseur suit les dépendances pertinentes, identifie les versions touchées, indique aux clients si leur environnement est concerné et fournit des correctifs ou des mesures de protection provisoires. Il doit aussi établir quelles activités dépendent du client ou d’un autre fournisseur.

Un fournisseur qui concède une licence de logiciel destiné à être déployé dans l’environnement du client peut publier un correctif tandis que le client contrôle son installation. Un fournisseur SaaS peut contrôler les deux. Un hébergeur peut assurer la maintenance de PHP tandis qu’une agence assure celle de l’application qui repose sur PHP.

La vérification diligente doit rendre ces limites visibles avant qu’elles ne soient contestées lors d’un incident. Le Software Acquisition Guide de la CISA encourage également les acheteurs à examiner les pratiques des fournisseurs concernant les composants tiers et la gestion des vulnérabilités. ^[3]

L’utilité d’une nomenclature logicielle

Une nomenclature logicielle, ou SBOM, identifie les composants inclus dans un produit logiciel. Elle peut soutenir l’évaluation de vulnérabilités nouvellement divulguées, à condition de comprendre sa couverture, son exactitude et son lien avec la version déployée. ^[4]

Pour les approvisionnements pertinents, les clients devraient envisager des exigences concernant la remise et la mise à jour d’une SBOM, ainsi que les explications du fournisseur sur l’incidence des vulnérabilités divulguées sur le produit.

La couverture importe. La SBOM d’un produit peut ne pas identifier un environnement d’exécution hébergé géré séparément ou l’ensemble de l’environnement opérationnel. Sa réception n’établit pas non plus la possibilité d’exploitation ni la réussite de la remédiation. Ses informations doivent alimenter la cartographie des dépendances, l’évaluation des vulnérabilités et les processus d’application de correctifs.

La sécurité logicielle mérite des dispositions contractuelles spécifiques

Les annexes de protection des données traitent de questions importantes, mais ne régissent pas entièrement la sécurité logicielle. Un produit peut contenir une vulnérabilité grave avant tout incident touchant les données. Le client peut avoir besoin d’un correctif, que des renseignements personnels soient concernés ou non.

Un contrat logiciel devrait traiter expressément de ce cycle de vie et refléter le modèle de prestation.

Les définitions et les délais doivent fonctionner ensemble. La connaissance d’un avis public, la confirmation qu’un produit est touché et la disponibilité d’un correctif sont des événements différents. Une disposition devrait préciser ce qui déclenche le délai et quelle prestation permet de respecter l’obligation.

Jaspreet explique pourquoi un délai fixe d’application de correctifs ne suffit pas :

Le cadre devrait traiter de l’évaluation, de la protection provisoire, de la correction, du déploiement et de la validation. Il devrait aussi prévoir un processus d’exception, incluant les justifications, les mesures compensatoires et les dates de révision.

L’automatisation peut améliorer la découverte, le déploiement et la production de rapports. Les mises à jour échouées, les actifs exclus et les systèmes qui ne sont plus pris en charge exigent néanmoins une supervision. Le contrat devrait tenir compte des circonstances où la remédiation nécessite une intervention du client, des tests de compatibilité ou une mise à niveau achetée séparément.

Rendre vérifiables les correctifs et la gestion des vulnérabilités

Les contrats devraient distinguer les responsabilités de sécurité propres à l’organisation des preuves qu’elle attend de ses fournisseurs.

Dans les systèmes qu’elle contrôle et qu’elle est autorisée à évaluer, une organisation peut valider la remédiation au moyen de registres de correctifs, de vérifications de configuration et d’évaluations des vulnérabilités. Lorsque le fournisseur contrôle l’environnement, le client devrait obtenir des preuves par les mécanismes convenus de rapports, de coopération et d’audit. Les tests techniques de l’infrastructure du fournisseur exigent une autorisation appropriée et un périmètre convenu.

Jaspreet identifie plusieurs moyens de soutenir la vérification :

La personne qui effectue ces activités dépend du service. Pour un logiciel hébergé par le client, un fournisseur peut démontrer la publication d’un correctif tandis que le client vérifie son déploiement. Pour un service hébergé, le fournisseur devrait remettre des preuves couvrant le service touché et la remédiation effectuée.

Les engagements de gestion des vulnérabilités et les droits d’audit doivent donc être rédigés ensemble. Un droit général d’audit peut laisser sans réponse des questions importantes : la vérification peut-elle avoir lieu en dehors d’un cycle annuel, quelles preuves doivent être fournies, dans quel délai et comment les constats non résolus sont-ils traités?

Les preuves devraient correspondre à l’obligation. Publier un correctif, l’installer et confirmer son déploiement effectif constituent des étapes distinctes. Les versions logicielles peuvent nécessiter une interprétation lorsque les distributeurs rétroportent des correctifs, et les résultats d’analyse doivent être lus dans les limites de leur périmètre.

Les deux parties devraient conserver des dossiers suffisants pour démontrer les activités dont elles sont responsables.

Relier les événements contractuels à un processus de communication fonctionnel

Une clause de notification est difficile à exécuter si personne ne sait quels contrats s’appliquent ou où transmettre l’avis.

Un registre contractuel pratique devrait relier les événements de sécurité pertinents aux relations avec les clients et les fournisseurs. Il devrait consigner :

• La définition de l’événement et le déclencheur lié à sa connaissance.
• Le délai et le contenu requis de l’avis.
• Le destinataire contractuel, l’adresse et le mode de transmission.
• La personne interne responsable de l’évaluation, de l’approbation et de la transmission.
• Toute exigence continue de mise à jour, de coopération ou de remédiation.

Un courriel de gestion de compte peut ne pas satisfaire à une disposition exigeant un avis à une adresse juridique ou de sécurité désignée. Les coordonnées doivent être tenues à jour, et les équipes ont besoin d’un processus utilisable en dehors des heures normales de travail.

Les communications réglementaires, contractuelles et avec les assureurs devraient être identifiées séparément. Leurs objectifs, leurs déclencheurs et leur calendrier peuvent différer.

Un exercice de simulation peut tester le processus à partir d’un scénario incertain : un fournisseur signale une vulnérabilité critique, l’incidence sur le client reste à l’étude et aucune compromission n’a été confirmée. Les équipes de sécurité et juridiques peuvent-elles identifier les obligations pertinentes, établir les faits manquants et joindre les bons destinataires dans les délais applicables?

Cela permet de vérifier si l’organisation peut reconnaître et traiter des événements juridiquement significatifs au-delà d’une atteinte classique aux données.

Ce que la rétrospective devrait changer

PHP2Shell a révélé l’importance de relier les faits techniques, les obligations contractuelles et les décisions de réponse. Une rétrospective utile devrait transformer les lacunes rencontrées en changements dans la façon dont ces fonctions travaillent ensemble.

Les lacunes d’inventaire devraient orienter la cartographie des dépendances et de l’information. Les réponses imprécises des fournisseurs devraient éclairer la vérification diligente et les droits de rapport et de vérification. Les décisions tardives devraient éclairer les pouvoirs d’urgence. Les parcours de notification incertains devraient mener à un registre contractuel tenu à jour et à un processus de communication éprouvé.

Ces améliorations reposent sur une équipe intégrée qui partage l’information sous une forme utilisable par les autres. Les spécialistes de la sécurité doivent savoir quels événements contractuels exigent une escalade. Les juristes ont besoin de conclusions qui expliquent les systèmes touchés, l’information et les incertitudes. Les équipes d’approvisionnement ont besoin de retours sur les engagements des fournisseurs qui se sont révélés utiles et sur ceux qui étaient absents ou impraticables.

Un vCISO peut établir les responsabilités, les priorités et les rapports. Une équipe de sécurité en tant que service peut offrir la capacité nécessaire pour tenir les inventaires, coordonner la remédiation et valider son achèvement. Le juriste en approvisionnement relie ces activités aux engagements envers les fournisseurs et les clients, tandis que l’avocat en réponse aux incidents évalue les conséquences juridiques des constats émergents.

Les processus deviennent plus utiles lorsqu’ils s’éclairent mutuellement. Les constats techniques soutiennent la classification juridique; les exigences juridiques façonnent l’escalade et la collecte de preuves; l’expérience opérationnelle améliore le prochain contrat. Cette coordination aide une organisation à gérer la prochaine vulnérabilité avec des faits plus clairs, des droits applicables et moins de retards évitables.