Le 20 octobre 2026, la PHP Foundation a annoncé une mise à jour de sécurité imminente pour corriger deux vulnérabilités critiques de PHP, le langage qui fait fonctionner une part immense des sites vitrines, des boutiques en ligne et des extranets des entreprises françaises. Le correctif est attendu ce mercredi 21 octobre 2026 à 16 heures, heure de Paris, et les agences de cybersécurité parlent déjà d’exploitation observée en conditions réelles. Pour une entreprise, la question n’est pas théorique : faut-il couper son site internet pendant quelques heures, comment protéger les données de ses clients et de ses salariés, qui prévenir, et qui paiera la facture si le pire se produit. Le centre britannique NCSC recommande aux organisations de préparer la mise à jour immédiate de leurs systèmes PHP et, quand la correction immédiate est impossible, d’envisager de mettre le système hors ligne jusqu’à sa sécurisation complète. Cet article explique, pas à pas, ce que le droit français et européen attend d’une entreprise confrontée à cette faille, depuis l’inventaire de l’urgence jusqu’à la notification à la CNIL et aux recours contre le prestataire ou l’hébergeur.
I. Faut-il mettre votre site hors ligne en attendant le correctif PHP du 21 octobre 2026 ?
La faille qui occupe toute la presse spécialisée ce 21 octobre 2026 porte un nom de code, php2shell, et deux identifiants : CVE-2026-109618 et CVE-2026-109619. L’éditeur de sécurité Aikido, qui a documenté l’alerte, fait état de deux vulnérabilités critiques d’exécution de code à distance logées dans PHP lui-même, avec un score de gravité CVSS v4.0 de 9,2 sur 10 pour les deux identifiants CVE-2026-109618 et CVE-2026-109619. L’exécution de code à distance signifie qu’un attaquant peut, sans disposer de vos identifiants, faire exécuter ses propres instructions par votre serveur : installer une porte dérobée, copier votre base clients, chiffrer vos fichiers pour exiger une rançon, ou utiliser votre serveur pour attaquer d’autres cibles. Le NCSC britannique précise le calendrier : la PHP Foundation a annoncé le 20 octobre 2026 une mise à jour de sécurité imminente corrigeant deux vulnérabilités critiques de PHP. La fondation a publié son avis sur sa page officielle, et le correctif est programmé à 14 heures UTC, soit 16 heures à Paris. La presse française spécialisée confirme l’urgence : selon un article de Clubic publié ce 21 octobre, la mise à jour d’urgence corrige deux failles de gravité maximale, et une part considérable du web français tourne encore sur des versions anciennes, avec 27 % des sites PHP sous PHP 7 et 7,7 % sous PHP 5 selon les mesures de W3Techs citées par le site. Or, selon Aikido, toutes les versions doivent être considérées comme affectées, y compris les très anciennes branches remontant à PHP 5. Pour l’entreprise, la première partie de cet article répond donc à deux questions pratiques : comment vérifier si vous êtes concerné, puis comment décider, proprement, de couper ou de maintenir votre site.
A. Comment savoir si votre site est concerné par la faille PHP (php vulnerability, cve-2026-109618)
La plupart des dirigeants ne savent pas dans quel langage tourne leur site : c’est normal, c’est le rôle de leur prestataire ou de leur hébergeur de le savoir. Mais le 21 octobre 2026, l’inaction n’est pas une option, car l’alerte concerne potentiellement tout site dynamique : boutique en ligne sous CMS, site vitrine avec formulaires, espace client, intranet accessible à distance, application métier hébergée. La recommandation officielle du NCSC tient en une liste d’actions immédiates : recensez tous vos systèmes qui utilisent une version quelconque de PHP, en commençant par ceux exposés sur internet ; surveillez ces systèmes exposés pour y détecter toute activité malveillante ; suivez les consignes officielles de PHP ; appliquez les mises à jour dès leur parution ; et surveillez aussi les mises à jour de vos fournisseurs tiers, y compris les équipements et services qui embarquent PHP sans que vous le sachiez. Ce dernier point vise les boîtiers, les logiciels de caisse, de gestion ou de supervision qui intègrent PHP en silence.
Concrètement, dès ce matin, écrivez à votre prestataire informatique et à votre hébergeur trois demandes datées : premièrement, confirmer par écrit la ou les versions de PHP utilisées par chacun de vos sites et services exposés ; deuxièmement, indiquer si le correctif du 21 octobre à 16 heures pourra être appliqué immédiatement et à quelle heure exacte ; troisièmement, dire si une activité suspecte a déjà été observée sur vos systèmes. Conservez ces échanges : en droit français, « Celui qui réclame l’exécution d’une obligation doit la prouver. Réciproquement, celui qui se prétend libéré doit justifier le paiement ou le fait qui a produit l’extinction de son obligation. » Cette règle de l’article 1353 du code civil s’applique à plein à vos contrats informatiques : si demain vous reprochez à votre prestataire de ne pas avoir patché à temps, il vous faudra prouver ce que vous lui aviez demandé et quand. Faites aussi vérifier vos sauvegardes : une sauvegarde récente, complète et testée, stockée hors ligne, est la seule protection fiable si votre serveur doit être reconstruit. Enfin, un outil gratuit de vérification en ligne mis à disposition par Aikido permet de tester si un site public est exposé, en scannant uniquement les sites dont vous êtes propriétaire ou pour lesquels vous avez l’autorisation : l’éditeur précise que le contrôle approfondi peut faire planter un processus PHP et interrompre des requêtes, et recommande donc de le lancer en dehors des heures de pointe. Ne lancez un tel test que sur vos propres actifs, jamais sur le site d’un tiers : tester sans autorisation le système d’autrui expose à des poursuites, car « Le fait d’accéder ou de se maintenir, frauduleusement, dans tout ou partie d’un système de traitement automatisé de données est puni de trois ans d’emprisonnement et de 100 000 € d’amende », selon l’article 323-1 du code pénal, et « 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 est puni de cinq ans d’emprisonnement et de 150 000 € d’amende », selon l’article 323-3 du même code, la tentative étant punie des mêmes peines d’après l’article 323-7. Ces textes visent les comportements frauduleux : un test de sécurité se fait avec l’accord écrit de l’hébergeur ou du prestataire, jamais à l’aveugle.
B. Mettre son site hors ligne : comment décider et comment le faire sans aggraver le préjudice
Couper son site de vente ou son extranet client en pleine journée coûte de l’argent : paniers abandonnés, devis non reçus, clients qui appellent, référencement qui peut souffrir d’une indisponibilité prolongée. Pourtant, les autorités recommandent d’envisager cette mesure quand le correctif ne peut pas être appliqué tout de suite. Aikido recommande, tant que le correctif n’est pas disponible, de mettre hors ligne les applications PHP exposées sur internet quand c’est possible. Et l’éditeur ajoute un avertissement important pour les fausses bonnes idées : « Do not rely on configuration changes. » Ne comptez pas sur des changements de configuration, car l’équipe PHP a confirmé que la faille ne peut pas être neutralisée par un simple réglage, et qu’aucune règle de filtrage applicatif complète n’existe encore. Surtout, l’exploitation a déjà commencé : une exploitation en conditions réelles a été signalée, et les atténuations par configuration un temps envisagées ne protègent pas contre ces vulnérabilités. Autrement dit, entre un site vulnérable qui continue d’encaisser des commandes et un site coupé quelques heures, le droit de la protection des données penche nettement pour la coupure : le règlement européen impose au responsable du traitement et à son sous-traitant de prendre des mesures techniques et organisationnelles appropriées pour garantir un niveau de sécurité adapté au risque, comme l’exige l’article 32 du règlement (UE) 2016/679, qui vise notamment des moyens garantissant durablement la confidentialité, l’intégrité, la disponibilité et la résilience des systèmes et des services de traitement. Maintenir sciemment en ligne, après une alerte critique documentée, un système dont on sait qu’il est exploitable, fragilise sérieusement votre position si des données clients sont ensuite volées.
La coupure doit cependant être exécutée avec méthode pour ne pas créer un second litige. Prévenez vos clients par un bandeau et, pour une boutique, par un message expliquant une maintenance de sécurité programmée, sans entrer dans les détails techniques. Si votre contrat client prévoit des délais de livraison ou de disponibilité, la suspension temporaire reste une inexécution : le code civil prévoit que « 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 », selon l’article 1231-1. La force majeure suppose, d’après l’article 1218 du même code, « un événement échappant au contrôle du débiteur, qui ne pouvait être raisonnablement prévu lors de la conclusion du contrat et dont les effets ne peuvent être évités par des mesures appropriées ». Une faille logicielle mondiale annoncée la veille sera difficilement qualifiée d’imprévisible pour un professionnel du numérique, mais elle peut constituer, pour le commerçant qui l’apprend par la presse, un événement extérieur qu’il gère au mieux : documentez l’heure de l’annonce, l’heure de votre décision et les mesures prises, car c’est cette diligence qui limitera les dommages et intérêts éventuels. Après l’application du correctif, le travail n’est pas terminé : Aikido recommande de rechercher toute trace de compromission en remontant au moins jusqu’à juin 2026, en inspectant les portes dérobées web, les fichiers inconnus, les nouveaux comptes administrateurs, les connexions sortantes inhabituelles et les fichiers PHP modifiés. Faites réaliser cette vérification par votre prestataire et exigez-en un compte rendu écrit : si un attaquant s’est introduit avant le patch, la simple mise à jour ne le fera pas partir.
II. Après la faille : notification CNIL, information des clients, assurance et recours contre le prestataire
Une fois le site stabilisé et le correctif appliqué, l’urgence technique laisse place à l’urgence juridique : faut-il prévenir la CNIL, faut-il écrire aux clients, faut-il déclarer le sinistre à l’assureur, et peut-on demander des comptes au prestataire qui n’avait pas mis à jour PHP depuis des années. Cette seconde partie suit l’ordre des réflexes : d’abord les obligations envers l’autorité et les personnes concernées, ensuite les recours financiers. Premier point de vigilance : les versions PHP 5 et PHP 7, encore très répandues selon les chiffres cités par la presse spécialisée, pourraient ne pas recevoir de correctif, la maintenance de ces branches étant arrêtée depuis longtemps. Si votre prestataire vous a laissé sur une version obsolète sans vous alerter, ce seul fait alimentera l’examen de sa responsabilité, comme le montrent les décisions récentes des cours d’appel en matière de sécurité informatique. Deuxième point : chaque étape doit être horodatée, car les délais en la matière se comptent en heures et en jours, et le point de départ de chacun d’eux court à compter de votre connaissance des faits, comme l’énoncent les textes cités ci-dessous.
A. Notification CNIL en 72 heures et information des clients : qui notifie, quoi et quand
Le règlement européen sur la protection des données organise la réaction à toute violation de données à caractère personnel, c’est-à-dire tout incident qui entraîne la destruction, la perte, l’altération ou la divulgation non autorisée de telles données. L’article 33 du règlement (UE) 2016/679 dispose qu’en cas de violation de données à caractère personnel, le responsable du traitement la notifie à l’autorité de contrôle dans les meilleurs délais et, si possible, au plus tard 72 heures 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 physiques ; toute notification tardive s’accompagne des motifs du retard. En France, l’autorité compétente est la CNIL et la notification s’effectue sur son téléservice dédié. Ce délai de 72 heures, posé par l’article 33 du règlement déjà cité, court à compter du moment où vous avez pris connaissance de la violation, c’est-à-dire, en pratique, du moment où votre prestataire ou votre propre surveillance vous révèle des indices sérieux de compromission, et non du jour de la faille elle-même : une simple vulnérabilité, sans indice d’intrusion ni d’exfiltration, n’est pas encore une violation à notifier, mais elle impose la vigilance renforcée décrite en première partie. La notification doit 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 autre point de contact, les conséquences probables et les mesures prises ou envisagées pour y remédier et en atténuer les effets. Si toutes les informations ne sont pas disponibles immédiatement, le même article 33 permet de communiquer les informations de manière échelonnée, sans retard indu : notifiez tôt avec ce que vous savez, puis complétez, plutôt que d’attendre le rapport d’expertise complet.
Lorsque c’est votre prestataire ou votre hébergeur qui traite les données pour votre compte, la chaîne d’alerte est encadrée par le même texte : Le même texte impose au sous-traitant d’alerter le responsable du traitement de toute violation de données personnelles dans les meilleurs délais après en avoir pris connaissance. Vérifiez donc votre contrat de sous-traitance : il doit prévoir un délai d’alerte du sous-traitant vers vous, plus court que vos propres 72 heures, faute de quoi vous risquez de découvrir l’incident trop tard pour notifier à temps. En parallèle, tenez le registre interne des violations prévu par le paragraphe 5 du même article 33, qui impose au responsable du traitement de documenter chaque violation, avec les faits constatés, ses effets et les mesures prises pour y remédier. Ce registre sera la première pièce réclamée en cas de contrôle : l’article 58 du règlement donne à chaque autorité de contrôle le pouvoir d’obtenir du responsable du traitement et du sous-traitant l’accès à toutes les données personnelles et informations nécessaires à ses missions, ainsi que celui de mener des audits sur la protection des données. Au-delà de l’autorité, les clients dont les données ont été exposées doivent parfois être prévenus directement : l’article 34 du règlement prévoit que Quand une violation est susceptible d’engendrer un risque élevé pour les droits et libertés d’une personne, l’article 34 du règlement impose au responsable du traitement d’en informer la personne concernée dans les meilleurs délais, dans des termes clairs et simples, avec la nature de l’incident et les mesures de protection à prendre, comme changer un mot de passe ou surveiller ses relevés. Cette information individuelle n’est pas exigée si les données volées étaient chiffrées de manière à rester incompréhensibles, si des mesures ultérieures ont écarté le risque élevé, ou si l’information exigerait des efforts disproportionnés, auquel cas une communication publique peut suffire. L’appréciation du risque élevé dépend de la nature des données : des identifiants et mots de passe en clair, des coordonnées bancaires ou des pièces d’identité n’appellent pas la même réaction que des adresses électroniques seules. En cas de contrôle, la CNIL tient compte des circonstances propres à chaque cas, et le règlement prévoit des amendes effectives, proportionnées et dissuasives, fixées en tenant compte notamment de la nature, de la gravité et de la durée de la violation, de son caractère délibéré ou négligent et des mesures prises pour atténuer le dommage subi, selon l’article 83 du règlement. Autrement dit, une entreprise qui a coupé son site vite, notifié tôt et aidé ses clients sera jugée différemment d’une entreprise qui a laissé un serveur vulnérable en ligne pendant des semaines.
B. Se retourner contre son prestataire ou son hébergeur et activer son assurance : prouver la faute, chiffrer le préjudice, agir dans les délais
Quand le site a été piraté ou a dû être coupé, la question financière suit immédiatement : perte de chiffre d’affaires, heures de remise en état, rançon éventuellement payée, notification et gestion de crise, préjudice d’image. La première cible naturelle est le prestataire chargé de la maintenance, et la jurisprudence récente lui est sévère quand la sécurité a été négligée. Dans un arrêt du 28 avril 2026, la cour d’appel de Reims a jugé qu’un prestataire informatique chargé de la création et de l’élaboration de logiciels, sites web ou applications mobiles, prestations intellectuelles complexes soumises aux aléas de la collaboration du client et de l’évolution rapide du secteur, « est tenu d’une obligation de moyens renforcée quant à la délivrance de l’ouvrage commandé », en ajoutant : « Il lui appartient ainsi de rapporter la preuve qu’il a accompli toute diligence en vue de l’obtention du résultat escompté, mais également qu’il n’a pas commis de faute dans l’exécution de ses obligations. » Dans cette affaire, l’expert avait relevé que « la configuration du système Windows server a été déployée avec des paramètres par défaut », et la cour a retenu que le manquement du prestataire à son devoir de conseil et le non-respect des prescriptions de sécurité avaient fragilisé le système et permis l’attaque. La cour a conclu : « Dit que la société 3 services informatiques est responsable à hauteur de 50 % des dommages subis par la société MISA », et l’a condamnée à verser 12 097,59 euros détaillés en perte d’exploitation, remise en état, paramétrage, réinstallation et coût de la rançon (cour d’appel de Reims, chambre civile et commerciale, 28 avril 2026, RG 24/01502, décision consultable sur le site de la Cour de cassation). Transposé à la faille PHP du 21 octobre 2026, ce raisonnement donne une grille d’analyse : un prestataire qui maintenait votre site sur une version PHP obsolète sans vous alerter, qui n’a pas appliqué le correctif du 21 octobre dans la journée, ou dont l’audit révèle des réglages par défaut et l’absence de supervision, engage sa responsabilité contractuelle, et c’est à lui de prouver sa diligence. La part de responsabilité partagée retenue à Reims rappelle aussi que le client n’est pas exonéré de tout effort : ne pas sauvegarder, refuser les mises à jour proposées ou tarder à couper un site signalé comme vulnérable peut réduire l’indemnisation.
Face à l’hébergeur, le raisonnement est voisin mais les contrats sont souvent plus verrouillés : plafonds d’indemnisation, exclusions, clauses de force majeure. Un arrêt de la cour d’appel de Douai du 4 juin 2026, rendu après l’incendie d’un centre de données, illustre la méthode des juges : la cour y a refusé de reconnaître la force majeure invoquée par l’hébergeur, a rejeté aussi la demande du client tendant à faire réputer non écrites la clause de force majeure et les clauses limitatives de responsabilité, a jugé que l’hébergeur avait déjà intégralement indemnisé le seul préjudice imputable à son manquement, puis a condamné le client aux dépens d’appel et à 5 000 euros au titre de l’article 700 du code de procédure civile (cour d’appel de Douai, chambre 2, section 2, 4 juin 2026, RG 24/00967). Trois enseignements pour votre dossier PHP : premièrement, la force majeure ne se présume pas, elle se prouve selon ses trois conditions légales, et une panne même spectaculaire n’en remplit pas automatiquement les critères ; deuxièmement, les clauses qui plafonnent la responsabilité de l’hébergeur résistent souvent, sauf si elles vident l’obligation essentielle de sa substance, car « Toute clause qui prive de sa substance l’obligation essentielle du débiteur est réputée non écrite » d’après l’article 1170 du code civil, et sauf déséquilibre significatif dans un contrat d’adhésion, puisque « Dans un contrat d’adhésion, toute clause non négociable, déterminée à l’avance par l’une des parties, qui crée un déséquilibre significatif entre les droits et obligations des parties au contrat est réputée non écrite » selon l’article 1171 ; troisièmement, seul le préjudice qui est « une suite immédiate et directe de l’inexécution » est réparé, y compris en cas de faute lourde ou dolosive, comme le rappelle l’article 1231-4 du code civil, et le débiteur ordinaire ne doit que les dommages « prévus ou qui pouvaient être prévus lors de la conclusion du contrat » selon l’article 1231-3. Chiffrez donc votre préjudice au plus près : journaux de ventes des périodes comparables, factures de remise en état, coût de la gestion de crise, et conservez chaque justificatif. Si l’inexécution est établie, le créancier dispose d’un arsenal prévu par l’article 1217 du code civil : refuser d’exécuter ou suspendre l’exécution de sa propre obligation, poursuivre l’exécution forcée en nature, obtenir une réduction du prix, provoquer la résolution du contrat ou demander réparation des conséquences de l’inexécution, ces sanctions pouvant être cumulées quand elles ne sont pas incompatibles. En pratique, la suspension du paiement des redevances de maintenance le temps que le prestataire sécurise vos systèmes, puis la résolution si rien n’est fait, sont des leviers efficaces, à manier par écrit et après mise en demeure. Enfin, pensez à votre assurance : les garanties cyber ou pertes d’exploitation exigent une déclaration rapide, et le code des assurances impose à l’assuré « De donner avis à l’assureur, dès qu’il en a eu connaissance et au plus tard dans le délai fixé par le contrat, de tout sinistre de nature à entraîner la garantie de l’assureur », en précisant que « Ce délai ne peut être inférieur à cinq jours ouvrés », d’après l’article L113-2 du code des assurances. Déclarez donc par écrit, dans le délai de votre contrat et au plus tard dans ce plancher de cinq jours ouvrés, en joignant le rapport d’incident et les premières factures. Et ne laissez pas le temps effacer vos droits : « Les actions personnelles ou mobilières se prescrivent par cinq ans à compter du jour où le titulaire d’un droit a connu ou aurait dû connaître les faits lui permettant de l’exercer », selon l’article 2224 du code civil, et entre commerçants « Les obligations nées à l’occasion de leur commerce entre commerçants ou entre commerçants et non-commerçants se prescrivent par cinq ans », selon l’article L110-4 du code de commerce. Cinq ans peuvent sembler longs, mais les preuves numériques s’effacent vite : journaux écrasés, sauvegardes recyclées, prestataire qui change de mains. Constituez votre dossier cette semaine, avec l’horodatage de l’alerte du 21 octobre 2026, vos échanges avec le prestataire et l’hébergeur, le rapport de compromission et le chiffrage du préjudice.
Conclusion
La faille PHP critique du 21 octobre 2026, avec ses deux CVE à 9,2 sur 10 et une exploitation déjà observée, impose aux entreprises exposées une séquence resserrée : recenser aujourd’hui même les systèmes sous PHP en commençant par ceux ouverts sur internet, appliquer le correctif de 16 heures ou, à défaut, mettre le site hors ligne comme le recommandent le NCSC et les éditeurs de sécurité, puis vérifier toute compromission depuis juin 2026. Sur le plan juridique, une intrusion avérée avec des données personnelles déclenche la notification à la CNIL dans les 72 heures de sa découverte et, en cas de risque élevé, l’information des personnes concernées, avec un registre d’incident tenu à disposition des contrôles. Sur le plan financier, le prestataire négligent répond de ses manquements sur le fondement d’une obligation de moyens renforcée dont c’est à lui de prouver l’exécution, comme l’a rappelé la cour d’appel de Reims le 28 avril 2026, tandis que l’hébergeur se retranchera derrière ses clauses limitatives, qui ne tombent que si elles vident le contrat de sa substance, comme l’a montré la cour d’appel de Douai le 4 juin 2026. Déclarez le sinistre à votre assureur dans le délai du contrat, sans descendre sous cinq jours ouvrés, et agissez dans les cinq ans de la découverte des faits. Dans ce type de crise, l’entreprise qui documente chaque heure, notifie tôt et sécurise vite ne protège pas seulement ses clients : elle se donne les pièces qui feront, demain, la différence devant l’autorité de contrôle comme devant le juge.