Le 21 octobre 2026, l’équipe d’intervention informatique de l’Union européenne (CERT-EU) a publié un avis de sécurité consacré à deux vulnérabilités critiques du langage PHP, avec une recommandation inhabituelle : les organisations qui ne peuvent pas appliquer immédiatement le correctif devraient envisager d’isoler d’internet leurs applications exposées jusqu’à l’arrivée de ce correctif. Le correctif lui-même était annoncé pour le 21 octobre 2026 à 14 h 00 UTC, avec une gravité de 9,2 sur l’échelle CVSS et un potentiel d’exécution de code à distance sans authentification. Si votre entreprise exploite un site vitrine, une boutique en ligne, un extranet ou une application métier, la question est concrète : une grande partie du web repose sur PHP, y compris des sites construits avec des outils très répandus. Les développements qui suivent sont de portée générale : ils décrivent les vérifications utiles pour tout exploitant de site placé dans une situation comparable et ne visent aucune entreprise en particulier. Cet article explique, pas à pas, ce que doit faire l’exploitant d’un site : vérifier l’exposition et appliquer le correctif ou isoler le site, gérer le cas des versions anciennes qui ne seront pas corrigées, puis, si des données personnelles ont pu être compromises, notifier la violation, informer les personnes et organiser la réparation.
I. Patch ou isolement : la première décision appartient à l’exploitant du site
A. Savoir si votre site est exposé et appliquer le correctif du 21 octobre 2026
Selon l’avis de sécurité CERT-EU 2026-018, publié le 21 octobre 2026, la fondation PHP a annoncé une mise à jour de sécurité hors cycle pour corriger deux vulnérabilités critiques pouvant conduire à une exécution de code à distance, avec une publication programmée le 21 octobre 2026 à 14 h 00 UTC et un score de gravité de 9,2 indiquant un risque d’exécution de code à distance sans authentification. La presse spécialisée rapporte les mêmes éléments et précise que seules les quatre branches PHP prises en charge, de la version 8.2 à la version 8.5, peuvent recevoir le correctif. Les identifiants CVE-2026-109618 et CVE-2026-109619 circulent pour désigner ces deux failles, mais la prudence s’impose : la presse spécialisée indique elle-même que ces numéros proviennent d’une fuite et ne figurent pas dans l’avis officiel de l’équipe PHP. Retenez le fait technique officiel (deux failles critiques, correctif le 21 octobre à 14 h 00 UTC, score de 9,2), pas les numéros.
La première vérification porte sur la technologie de votre site. PHP est omniprésent : il fait fonctionner des sites construits avec des outils très répandus, des plateformes d’hébergement mutualisé et de nombreux logiciels qui ne l’affichent pas. Concrètement, demandez à votre prestataire ou à votre hébergeur quelle version de PHP fait tourner votre site, ou vérifiez-la vous-même depuis votre panneau d’administration d’hébergement. La conduite recommandée par l’avis européen tient en deux temps : préparer l’application immédiate du correctif sur les actifs concernés et, lorsque cette application immédiate n’est pas possible, envisager d’isoler des réseaux publics les applications exposées sur internet jusqu’à la disponibilité du correctif. En pratique, cela donne un ordre de priorité clair. D’abord, recenser les actifs : site principal, boutique, sous-domaines, extranet, outils internes exposés sur internet. Ensuite, appliquer le correctif dès sa disponibilité, après une sauvegarde complète du site et de sa base de données, et en commençant si possible par un environnement de test. Si le correctif ne peut pas être appliqué tout de suite (site ancien, extensions incompatibles, absence de prestataire disponible), l’avis officiel invite à envisager l’isolement : page de maintenance, restriction d’accès, voire mise hors ligne temporaire des parties exposées. Cette mesure peut sembler radicale, mais elle répond à la nature du risque décrit : une exécution de code à distance potentiellement sans authentification permettrait à un attaquant de prendre le contrôle du site, d’y voler des données ou d’en altérer le fonctionnement.
Cette discipline n’est pas seulement technique : elle est juridique. Le droit européen de la protection des données impose au responsable du traitement et à son sous-traitant de mettre en œuvre les « mesures techniques et organisationnelles appropriées » afin de garantir un « niveau de sécurité adapté au risque », en tenant compte notamment des risques de destruction, de perte, d’altération, de divulgation non autorisée ou d’accès non autorisé aux données, qu’ils soient accidentels ou illicites. Appliquer un correctif de sécurité critique dès sa publication, ou isoler à défaut, fait partie de ces mesures : en cas de contrôle ou de litige ultérieur, le fait d’avoir agi vite, avec des traces écrites (date du correctif, sauvegardes, échanges avec le prestataire), sera déterminant pour démontrer le niveau de sécurité retenu.
B. Versions en fin de vie et rôle du prestataire : qui doit agir et sur quel fondement
Le second point de vigilance concerne les versions anciennes. Selon la presse spécialisée, seules les branches 8.2 à 8.5 peuvent recevoir le correctif, et les versions antérieures, notamment les branches 8.1, 8.0, 7.x et 5.x, sont en fin de vie et ne reçoivent aucun correctif de l’équipe PHP : si les failles atteignent ces branches, les installations correspondantes resteront sans correctif officiel. Si votre site tourne encore sur une de ces versions, le correctif du 21 octobre ne vous protégera pas. La réponse ne peut alors être que la migration vers une version prise en charge ou, à titre transitoire, des mesures de protection renforcées (pare-feu applicatif, restriction des accès, surveillance des journaux) assorties d’un calendrier de migration écrit. Conservez la preuve de la version utilisée, des alertes reçues et des décisions prises : en cas d’incident, c’est sur ces pièces que s’appréciera votre diligence.
Le plus souvent, l’exploitation technique du site est confiée à un tiers : agence web, infogéreur, hébergeur, freelance. C’est le contrat qui désigne qui fait quoi, et c’est lui qu’il faut relire en premier : périmètre de la maintenance, délais d’application des correctifs de sécurité, astreinte, sauvegardes, journalisation, réversibilité. Le principe civiliste est simple : « Les contrats légalement formés tiennent lieu de loi à ceux qui les ont faits » (code civil, article 1103). Si le contrat met la sécurité et les mises à jour à la charge du prestataire, écrivez-lui immédiatement pour lui demander l’application du correctif et la confirmation écrite de la version déployée. À défaut de réponse ou d’action, une mise en demeure écrite, avec un délai raisonnable et explicite, constitue la trace indispensable avant toute mesure plus ferme.
Lorsque le manquement du prestataire cause un dommage (site piraté, données volées, activité interrompue), le droit commun de la responsabilité contractuelle s’applique : « Le débiteur est condamné, s’il y a lieu, au paiement de dommages et intérêts soit à raison de l’inexécution de l’obligation, soit à raison du retard dans l’exécution, s’il ne justifie pas que l’exécution a été empêchée par la force majeure » (code civil, article 1231-1). La force majeure suppose un événement imprévisible et irrésistible : une faille mondialement médiatisée, avec un correctif disponible et un avis européen recommandant l’application immédiate, ne présente ni l’un ni l’autre caractère une fois le correctif publié. En revanche, avant la publication du correctif, l’impossibilité technique de corriger peut être discutée : d’où l’importance de dater précisément chaque étape (annonce, publication du correctif, demande au prestataire, intervention). Si l’hébergeur mutualisé applique lui-même les mises à jour, vérifiez ses conditions générales et ses communications : certains appliquent les correctifs automatiquement, d’autres laissent la version au choix du client, ce qui reporte la responsabilité sur l’exploitant du site.
II. Données des clients et visiteurs : notifier, informer, réparer
A. Violation de données personnelles : la notification à la CNIL dans les 72 heures et l’information des personnes
Une faille critique n’équivaut pas automatiquement à une violation de données personnelles : encore faut-il qu’un accès non autorisé, une extraction ou une altération de données ait eu lieu ou soit raisonnablement suspectée. Dès lors, la première tâche, une fois le correctif appliqué ou le site isolé, consiste à rechercher des traces d’exploitation : journaux d’accès au serveur, fichiers modifiés ou ajoutés, comptes administrateurs inconnus, exports suspects de la base de données, messages d’alerte de l’hébergeur. Faites réaliser cette analyse par un professionnel, conservez les journaux et demandez un compte rendu écrit et daté. Si l’analyse conclut à l’absence d’indice d’exploitation, conservez-la : elle justifiera, pièces à l’appui, l’absence de notification. Si elle révèle une exploitation avérée ou si un doute sérieux subsiste sur des données personnelles (noms, adresses, courriels, mots de passe, coordonnées bancaires, historiques d’achat), le régime des violations de données personnelles s’enclenche.
Le droit français désigne l’autorité destinataire et le régime applicable : « Le responsable de traitement notifie à la Commission nationale de l’informatique et des libertés et communique à la personne concernée toute violation de données à caractère personnel en application des articles 33 et 34 du règlement (UE) 2016/679 du 27 avril 2016 » (loi du 6 janvier 1978 relative à l’informatique, aux fichiers et aux libertés, article 58). Cette autorité, la CNIL, « est l’autorité de contrôle nationale au sens et pour l’application du règlement (UE) 2016/679 du 27 avril 2016 » (loi du 6 janvier 1978, article 8). Le régime européen ainsi visé impose au responsable du traitement de notifier la violation « dans les meilleurs délais » et, « si possible », « 72 heures au plus tard » « après en avoir pris connaissance », sauf si la violation n’est pas susceptible d’engendrer un risque pour les droits et libertés des personnes ; lorsque la notification n’a pas lieu dans ce délai, elle est accompagnée des « motifs du retard ». Le point de départ de ce délai, tel que le texte l’énonce, est le moment où le responsable en a pris connaissance : ce n’est donc ni la date de la faille ni celle du correctif, mais celle où l’exploitation ou la compromission a été constatée ou est devenue raisonnablement certaine au vu des éléments recueillis. Documentez cette date avec soin, car c’est elle qui sera contrôlée. Si votre site est géré par un prestataire qui détecte l’incident le premier, sachez que le sous-traitant doit notifier toute violation au responsable « dans les meilleurs délais » après en avoir pris connaissance : exigez contractuellement et par écrit une alerte immédiate, car chaque heure perdue par le sous-traitant réduit votre propre délai.
Le contenu de la notification est lui aussi encadré : elle doit au minimum décrire la nature de la violation, les catégories et le nombre approximatif de personnes et d’enregistrements concernés, les coordonnées du délégué à la protection des données ou d’un point de contact, les conséquences probables et les mesures prises ou envisagées pour y remédier. Rassemblez donc méthodiquement : périmètre des comptes affectés, types de données exposées, mesures de confinement déjà appliquées (correctif, réinitialisation des mots de passe, révocation des sessions). Une notification incomplète mais envoyée dans le délai, puis complétée ensuite, vaut mieux qu’une notification parfaite mais tardive sans motif.
Au-delà de l’autorité, les personnes concernées doivent parfois être informées directement : lorsque la violation est susceptible d’engendrer un risque élevé pour leurs droits et libertés, le responsable la leur communique « dans les meilleurs délais », dans des termes clairs et simples, en indiquant au minimum le point de contact, les conséquences probables et les mesures prises. Concrètement, pour une boutique en ligne dont la base clients aurait été aspirée, cela signifie un message individuel expliquant ce qui s’est passé, quelles données sont concernées et ce que chacun doit faire (changer son mot de passe, surveiller ses relevés, se méfier des messages frauduleux qui exploiteraient les données volées).
La loi prévoit toutefois des cas où cette information individuelle n’est pas nécessaire, notamment si le responsable avait mis en œuvre des mesures de protection qui rendent les données incompréhensibles pour toute personne non autorisée à y accéder, « telles que le chiffrement », ou s’il a pris des mesures ultérieures qui garantissent que le risque élevé ne peut plus se matérialiser. Le chiffrement effectif des données volées, avec des clés restées secrètes, constitue ainsi une protection décisive : c’est un argument supplémentaire pour chiffrer les bases clients et ne jamais stocker en clair les mots de passe. Mais attention : l’appréciation du risque élevé appartient au responsable du traitement sous le contrôle de la CNIL, et une erreur d’appréciation expose à une sanction. En cas de doute sur des données sensibles ou financières, informer reste l’option prudente.
B. Indemnisation des victimes et sanction des attaquants : les voies de recours
Les personnes dont les données ont été compromises disposent d’un droit propre à réparation : toute personne ayant subi un dommage matériel ou moral du fait d’une violation du règlement peut en obtenir « réparation du préjudice subi » auprès du responsable du traitement ou du sous-traitant. Le préjudice peut être matériel (achats frauduleux, usurpation d’identité, frais engagés) ou moral (angoisse, perte de contrôle sur ses données, temps passé aux démarches). Le responsable ne peut s’exonérer qu’en prouvant que le fait qui a provoqué le dommage ne lui est nullement imputable, ce qui suppose de démontrer une sécurité à la hauteur du risque et une réaction diligente. Lorsque plusieurs acteurs participent au traitement (éditeur du site, hébergeur, prestataire de paiement), chacun des responsables ou sous-traitants impliqués peut être tenu pour la totalité du dommage, afin de garantir à la victime une réparation effective : la victime peut donc se tourner vers l’un d’entre eux pour l’entier préjudice, à charge pour celui-ci de se retourner ensuite contre les autres selon leurs parts respectives.
Du côté de l’entreprise exploitante, l’enjeu financier dépasse les indemnisations individuelles. Le régime européen veut que les amendes administratives soient, dans chaque cas, effectives, proportionnées et dissuasives, et les manquements aux obligations de sécurité, de notification et d’information relèvent du niveau pouvant atteindre 10 millions d’euros ou, pour une entreprise, 2 % de son chiffre d’affaires annuel mondial. Autrement dit, c’est l’absence de correctif, le défaut de notification ou le silence gardé envers les clients qui font grimper le risque de sanction, bien plus que la faille elle-même, que personne ne pouvait empêcher avant la publication du correctif. La coopération avec l’autorité, les mesures d’atténuation et l’absence d’antécédents figurent parmi les critères d’appréciation du montant : chaque effort documenté compte.
Sur le plan pénal, l’exploitation d’une telle faille par un tiers entre dans le champ des atteintes aux systèmes de traitement automatisé de données. Le code pénal punit de trois ans d’emprisonnement et de 100 000 euros d’amende « Le fait d’accéder ou de se maintenir, frauduleusement, dans tout ou partie d’un système de traitement automatisé de données » (code pénal, article 323-1), de cinq ans et 150 000 euros « Le fait d’entraver ou de fausser le fonctionnement d’un système de traitement automatisé de données » (code pénal, article 323-2) ainsi que « Le fait d’introduire frauduleusement des données dans un système de traitement automatisé, d’extraire, de détenir, de reproduire, de transmettre, de supprimer ou de modifier frauduleusement les données qu’il contient » (code pénal, article 323-3). La détention ou la diffusion d’outils d’intrusion est elle-même visée : est puni « Le fait, sans motif légitime, notamment de recherche ou de sécurité informatique, d’importer, de détenir, d’offrir, de céder ou de mettre à disposition un équipement, un instrument, un programme informatique ou toute donnée conçus ou spécialement adaptés pour commettre une ou plusieurs des infractions prévues par les articles 323-1 à 323-3 » (code pénal, article 323-3-1). Lorsque ces faits sont commis par une personne morale ou pour son compte, sachez que « Les personnes morales déclarées responsables pénalement, dans les conditions prévues par l’article 121-2, des infractions définies au présent chapitre encourent », outre l’amende prévue pour les personnes morales, les peines prévues pour ces infractions (code pénal, article 323-6).
La jurisprudence récente illustre l’étendue de ces incriminations. Par un arrêt du 2 septembre 2025 (pourvoi n° 24-83.605, publié au bulletin), la chambre criminelle de la Cour de cassation a jugé que « se rend coupable de l’infraction prévue par l’article 323-1 du code pénal celui qui se maintient dans un système de traitement automatisé de données en prenant connaissance du contenu des messages échangés au sein du réseau, à des fins étrangères à sa mission et à l’insu des titulaires des messages, même si, administrateur du réseau, il bénéficie, de par ses fonctions, d’un droit général d’accès à la messagerie » (Cour de cassation, criminelle, 2 septembre 2025, n° 24-83.605). L’enseignement vaut pour notre sujet : un accès techniquement possible n’est pas un accès autorisé, et l’exploitation d’une faille par un intrus, même sans dégradation visible, caractérise l’infraction dès lors que l’accès est frauduleux.
Victime d’une intrusion, l’entreprise comme ses clients peuvent agir. Sur le plan civil, « Tout fait quelconque de l’homme, qui cause à autrui un dommage, oblige celui par la faute duquel il est arrivé à le réparer » (code civil, article 1240), et l’action en justice contre l’auteur de l’intrusion, s’il est identifié, se double de la voie pénale : « L’action civile en réparation du dommage causé par un crime, un délit ou une contravention appartient à tous ceux qui ont personnellement souffert du dommage directement causé par l’infraction » (code de procédure pénale, article 2), ce qui permet à la victime de se constituer partie civile devant le juge pénal. En pratique : déposez plainte en joignant le compte rendu technique d’intrusion, les journaux horodatés et l’inventaire des données concernées ; conservez toute la correspondance avec le prestataire et l’hébergeur ; et si vos clients vous interrogent, renvoyez-les vers les démarches utiles (changement des mots de passe, opposition bancaire le cas échéant, signalement des usages frauduleux) sans reconnaître une faute que seul le juge appréciera. Les lecteurs confrontés à une compromission massive de données personnelles trouveront un exposé complémentaire de la conduite à tenir dans notre dossier consacré aux suites d’un piratage de grande ampleur (données personnelles piratées : que faire après une cyberattaque massive, plainte et indemnisation).
Pour les entreprises de Paris et d’Île-de-France, les règles sont les mêmes que sur le reste du territoire, mais la proximité des acteurs facilite la réaction : la CNIL, autorité destinataire de la notification, siège à Paris, et les directions techniques comme les conseils spécialisés y sont concentrés, ce qui permet de réunir vite l’analyse d’intrusion, la notification et la communication aux clients. Vérifiez aussi où sont hébergées vos données et où se trouvent vos sous-traitants : un hébergeur parisien ou francilien n’exonère pas de la vérification du contrat, mais il simplifie les échanges et, en cas de litige, l’expertise. Dans tous les cas, intégrez à votre dossier une dimension locale : juridiction du siège ou du lieu du dommage selon l’assignation envisagée, pièces à réunir (contrat d’hébergement, contrat de maintenance, journaux), et canal procédural adapté à l’urgence et à l’objectif poursuivi.
Conclusion
La faille critique révélée le 21 octobre 2026 impose aux exploitants de sites une réaction en deux temps : d’abord technique, avec l’application du correctif annoncé à 14 h 00 UTC ou, à défaut, l’isolement des applications exposées comme le recommande l’avis CERT-EU 2026-018, en tenant compte du fait que les versions PHP en fin de vie ne recevront aucun correctif ; ensuite juridique, avec la recherche de traces d’exploitation, la notification à la CNIL dans les meilleurs délais et au plus tard 72 heures après la prise de connaissance, l’information des personnes en cas de risque élevé, et l’organisation des recours contre les auteurs de l’intrusion et, le cas échéant, contre le prestataire défaillant. Les textes applicables (articles 33 et 34 du règlement européen relayés par l’article 58 de la loi du 6 janvier 1978, articles 323-1 et suivants du code pénal, responsabilité civile de droit commun) sanctionnent moins la survenance de la faille, que personne ne pouvait empêcher, que l’inaction qui la suit. Documenter chaque étape, écrire à son prestataire, conserver les journaux : face à une vulnérabilité de cette ampleur, la diligence prouvée est la meilleure protection de l’entreprise comme de ses clients.