La correction relève de la DSI et des éditeurs. Le rôle du DPO consiste à obtenir en quelques heures une réponse écrite à une question simple : nos traitements reposent-ils sur un composant PHP exposé, et si oui, que s’est-il passé depuis le 17 octobre ?
Les faits à connaître
Les deux vulnérabilités, CVE-2026-109618 et CVE-2026-109619, sont notées 9,2 sur 10 (CVSS v4.0) et permettent une exécution de code à distance sans authentification (CISA). Elles se logent dans le moteur PHP lui-même : une application bien écrite reste vulnérable si le PHP qui l’exécute n’est pas à jour.
| Point | État au 22 octobre 2026 |
|---|---|
| Versions vulnérables | PHP 5.4 à 8.5.11 (Google Cloud) |
| Versions corrigées | 8.5.12, 8.4.27, 8.3.36, 8.2.35 |
| PHP 8.1 et antérieurs | Plus de version officielle ; correctifs source à compiler pour 7.4, 8.0 et 8.1 (Les Joies du Code) |
| Configuration la plus exposée | Apache avec mod_php (Noolya) |
| Exploitation | Première tentative observée par Amazon le 17 octobre ; exploitation large signalée depuis le 21 (Tenable) |
| Position du CERT-FR | Isoler les équipements touchés, puis migrer vers une version corrigée (CERTFR-2026-ALE-014) |
Le projet PHP rappelle qu’aucune mesure de contournement n’est complète, et le CERT-FR ne qualifie pas les paramétrages provisoires qui circulent. L’ANSSI a recommandé la mise hors ligne des serveurs non corrigés ; le ministère de l’Intérieur a coupé ses sites exposés, dont ceux des préfectures (Actu IA).
La place du DPO dans la crise
L’article 38.1 du RGPD impose d’associer le DPO, d’une manière appropriée et en temps utile, à toute question relative à la protection des données. Une faille exploitée sur des serveurs qui traitent des données personnelles en fait partie dès la première heure.
Ses missions de l’article 39 (informer, conseiller, contrôler) le conduisent à alerter la direction et le responsable de traitement, à poser par écrit les bonnes questions à la DSI et aux éditeurs, puis à tracer chaque décision. Les choix techniques restent ceux de la DSI ; la décision de couper un service reste celle de la direction.
À retenir. Un DPO qui attend d’être sollicité arrive trop tard. Sa première action porte sur l’information de la direction, le jour même.
Les 48 premières heures
- Informer la direction par écrit. Un message court : nature de la faille, exploitation en cours, recommandation du CERT-FR, demande d’un point avec la DSI dans la journée.
- Obtenir l’inventaire des composants PHP. Le registre des traitements et la cartographie des applications servent de point de départ : site internet, extranet adhérents ou usagers, portail de résultats, prise de rendez-vous en ligne, outils RH hébergés, interfaces d’administration d’équipements.
- Classer chaque composant selon deux critères. Exposé sur Internet ou accessible seulement en interne ; données ordinaires ou données de santé et autres catégories de l’article 9. Le couple « exposé et données sensibles » passe en tête de liste.
- Demander à la DSI, pour chaque composant prioritaire, la version de PHP, le mode d’exécution (mod_php, PHP-FPM, autre), la date de correction prévue et, à défaut, la mesure d’isolement retenue.
- Faire conserver les journaux. Les journaux des serveurs web et pare-feu depuis le 17 octobre au moins doivent être préservés avant toute réinstallation : sans eux, impossible d’écarter une compromission.
- Ouvrir une fiche d’incident. Même sans violation avérée, la fiche date l’alerte, liste les questions posées, les réponses reçues et les décisions prises.
Un serveur en PHP 8.1 ou antérieur pose un problème à part : il n’aura pas de mise à jour officielle. Le DPO doit alors obtenir une date de migration, et rappeler à la direction que le maintien en ligne d’un composant non corrigé relève d’une décision qu’elle assume au regard de l’article 32.
Éditeurs et sous-traitants
Une grande partie des composants PHP d’un organisme appartient à ses éditeurs et hébergeurs. L’article 28.3.f oblige le sous-traitant à aider le responsable de traitement à respecter ses obligations de sécurité et de notification : le DPO est fondé à exiger des réponses précises, dans un délai court.
Les courriels d’éditeurs reçus depuis le 21 octobre recommandent souvent de restreindre l’exposition (VPN, filtrage d’adresses IP) sans nommer de produit ni de date de correctif. Ces consignes réduisent la surface d’attaque ; elles laissent le serveur vulnérable depuis le réseau interne. Les questions à adresser par écrit :
- quels modules utilisés par l’organisme reposent sur PHP, et dans quelle version ;
- quel mode d’exécution, et si Apache avec mod_php est en jeu ;
- quelle date de déploiement du correctif, et qui l’applique en cas d’installation locale ;
- pour la partie hébergée par l’éditeur, quelles vérifications de journaux depuis le 17 octobre, et avec quel résultat ;
- l’engagement de notifier sans délai toute violation constatée, conformément à l’article 33.2.
Secteur santé. Logiciels métiers, dossiers médicaux, portails de résultats et hébergeurs de données de santé méritent la relance la plus rapide. Dans un SPST, le dossier médical en santé au travail et l’extranet adhérents figurent en tête de liste ; dans un centre d’imagerie, le RIS, le PACS et le portail de diffusion des comptes rendus.
Vulnérabilité ou violation : qualifier
Une faille non exploitée ne constitue pas une violation de données au sens de l’article 4.12. La bascule se produit dès qu’un attaquant a pu exécuter du code sur un serveur qui accède à des données personnelles, même sans preuve d’extraction : la confidentialité et l’intégrité sont alors compromises.
| Constat de la DSI | Qualification | Suite à donner |
|---|---|---|
| Composant non exposé ou corrigé avant toute tentative | Pas de violation | Tracer l’analyse dans la fiche d’incident |
| Tentatives visibles dans les journaux, sans succès établi | Pas de violation à ce stade | Tracer, poursuivre la surveillance |
| Indices de compromission (fichier déposé, processus inconnu, connexions sortantes anormales) | Violation probable | Notification à la CNIL dans les 72 heures (article 33), sauf risque improbable dûment justifié |
| Compromission avérée touchant des données de santé | Violation à risque élevé très probable | Notification CNIL et information des personnes (article 34) |
| Service coupé par précaution, sans intrusion | Pas de violation en soi | Tracer la décision et sa durée |
Le délai de 72 heures court à partir du moment où l’organisme a une certitude raisonnable qu’une violation s’est produite. Une analyse de journaux qui traîne ne repousse pas ce point de départ indéfiniment : le DPO fixe avec la DSI une échéance pour conclure.
Quelle que soit la conclusion, l’article 33.5 impose de documenter toute violation, notifiée ou non. Pour un épisode écarté, la fiche d’incident apporte la preuve de diligence en cas de contrôle.
Les entités soumises à NIS2
Pour une entité essentielle ou importante au sens de la directive (UE) 2022/2555, un incident important impose un régime distinct de l’article 33 : alerte précoce au CSIRT national sous 24 heures, notification sous 72 heures, rapport final sous un mois (article 23). En France, l’ANSSI reçoit ces signalements. Le DPO vérifie que la procédure d’incident couvre les deux circuits et que personne ne suppose que l’un dispense de l’autre.
Après la crise
Une fois les correctifs appliqués, le DPO clôt la fiche d’incident avec la date de correction de chaque composant et la conclusion de l’analyse des journaux. Il porte ensuite au plan d’action les écarts révélés : composants absents de la cartographie, versions de PHP en fin de vie, contrats de sous-traitance muets sur les délais de correction, journaux conservés trop peu de temps.
Le guide de la sécurité des données personnelles de la CNIL fait de la mise à jour des logiciels une mesure de base. Un composant en fin de vie maintenu en production sans plan de migration expose l’organisme à un manquement à l’article 32 lors d’un futur contrôle. L’épisode trouve naturellement sa place dans le rapport annuel du DPO, avec les délais de réponse obtenus de chaque éditeur.
À retenir. Information de la direction le jour même, inventaire des composants PHP exposés, questions écrites à la DSI et aux éditeurs, conservation des journaux depuis le 17 octobre, qualification datée au regard des articles 33 et 34, fiche d’incident tenue de bout en bout.
PHP2Shell met à l’épreuve la capacité d’un organisme à savoir, en quelques heures, quels traitements tournent sur quels composants. Un registre relié aux applications, aux serveurs et aux sous-traitants produit cette liste sans dépendre de la mémoire des équipes. Vérifiez dès aujourd’hui que le vôtre en est capable.
