Le secteur de la santé britannique fait face à une multiplication par dix des cyberattaques — Log4Shell continue de sévir

Une vulnérabilité révélée et corrigée il y a plus de quatre ans est aujourd’hui la principale cause des cyberattaques visant le secteur de la santé au Royaume-Uni — et l’ampleur de cette offensive n’a pas de précédent récent. Selon une étude de SonicWall, relayée par Infosecurity Magazine le 30 juin 2026, le secteur de la santé britannique a enregistré 264 000 cyberattaques rien que sur les cinq premiers mois de 2026. Sur l’ensemble de l’année 2025, ce même secteur avait recensé environ 27 000 incidents — soit un facteur dix qui invite à s’interroger sérieusement sur l’état de la sécurité informatique dans la santé.

Sur ces 264 000 incidents, 41 % étaient des tentatives d’exploitation de Log4Shell : la faille critique d’exécution de code à distance dans Apache Log4j, une bibliothèque de journalisation Java intégrée à de nombreux logiciels d’entreprise. Log4Shell a été rendue publique en décembre 2021. Un correctif était disponible en quelques jours. Pourtant, la faille persiste, non corrigée, dans les middlewares cliniques Java, les applications web destinées aux patients et les systèmes hospitaliers anciens à travers le Royaume-Uni en 2026 — une persistance qui ne traduit pas un manque de sensibilisation, mais bien une défaillance structurelle dans la gestion des correctifs au sein des environnements IT de santé.

Pour les responsables IT et les responsables conformité du secteur santé, la situation soulève deux préoccupations distinctes. La première est opérationnelle : l’exploitation active d’une vulnérabilité connue à cette échelle exige une réaction immédiate. La seconde est réglementaire : les organismes de santé qui gèrent des informations personnelles identifiables (PII) ou des informations médicales protégées (PHI) sous HIPAA ont des obligations techniques précises, que l’exploitation de CVE non corrigées et critiques vient directement contrecarrer. La conformité HIPAA ne se résume pas à de la paperasse — elle impose que les mesures techniques suivent l’évolution des menaces connues.

Le service d’échange sécurisé de données de Kiteworks accompagne les organismes de santé qui gèrent des communications de contenu sensible dans ce type d’environnement à risque. Lorsque Log4Shell — aussi appelée Log4jam — a été révélée fin 2021, Kiteworks a réagi rapidement : évaluation de l’exposition, communication avec les clients, déploiement des correctifs en quelques jours seulement. Cette réactivité contraste avec la situation aujourd’hui documentée dans l’infrastructure de santé britannique, et illustre ce que signifie, concrètement, une gouvernance de plateforme axée sur la sécurité.

Résumé de l’article

Explosion des cyberattaques contre la santé britannique en cinq mois.

L’étude SonicWall a recensé 264 000 attaques sur les cinq premiers mois de 2026, contre environ 27 000 sur toute l’année 2025 — une envolée qui s’explique par un ciblage accru, une exposition de nouvelles infrastructures, ou les deux.

Log4Shell représente 41 % des attaques détectées, plus de quatre ans après la publication du correctif.

La faille critique Apache Log4j, révélée en décembre 2021, reste non corrigée dans les middlewares cliniques Java, les applications web à destination des patients et les systèmes hospitaliers anciens au Royaume-Uni — un échec systémique dans la gestion des correctifs, et non un simple oubli ponctuel.

L’Iran suspecté d’être à l’origine de la vague d’attaques.

Les analystes qui étudient l’ampleur et la nature des attaques pointent l’Iran comme acteur potentiel, ce qui correspond à l’intérêt des États-nations pour la perturbation des infrastructures de santé et la collecte de renseignements sur les patients.

Des systèmes non corrigés exposent directement les organismes couverts à HIPAA.

Les organismes de santé qui exploitent des systèmes vulnérables à une CVE critique et documentée ne respectent pas les exigences techniques de la HIPAA Security Rule — quelle que soit leur conformité sur le papier.

Le durcissement des plateformes et l’application rapide des correctifs sont le strict minimum.

Les responsables IT du secteur santé doivent considérer la correction des vulnérabilités anciennes comme une obligation de conformité — et non comme un simple retard de maintenance — et évaluer leur écosystème fournisseurs selon la rapidité et la rigueur de leur gestion des correctifs dans le passé.

Cyberattaques contre la santé britannique en 2026 : Log4Shell et l’ampleur de la menace

L’ampleur même de cette hausse — de 27 000 incidents sur toute l’année 2025 à 264 000 en seulement cinq mois en 2026 — impose une analyse approfondie avant de tirer des conclusions. Deux explications principales émergent des données, et elles ne s’excluent pas mutuellement.

La première concerne l’élargissement de la surface d’attaque. Les organismes de santé ont accéléré leur transformation numérique pendant la pandémie et au-delà. Portails web pour les patients, télémédecine, dispositifs médicaux connectés, systèmes administratifs migrés dans le cloud — tous ces éléments élargissent la surface que les acteurs malveillants peuvent explorer. Des systèmes autrefois hors ligne ou peu connectés il y a cinq ans sont aujourd’hui accessibles sur Internet et, surtout, fonctionnent avec des logiciels non corrigés. Ce qui ressemble à une explosion des attaques reflète en partie l’augmentation du nombre de cibles visibles et accessibles.

La seconde explication est un ciblage accru. L’étude SonicWall pointe l’Iran comme acteur potentiel de cette montée en puissance. Les attaques d’États-nations contre les infrastructures de santé sont documentées dans les pays occidentaux. Le secteur attire par la sensibilité de ses données, son caractère critique et sa posture de sécurité historiquement faible. Un hôpital ne peut pas simplement mettre hors ligne ses systèmes de gestion des patients pour les corriger. Les acteurs sophistiqués l’ont bien compris et exploitent de plus en plus cette contrainte opérationnelle.

Log4Shell (CVE-2021-44228) permet à un attaquant distant non authentifié d’exécuter du code arbitraire sur des systèmes vulnérables en injectant une chaîne spécialement conçue dans un champ journalisé par Log4j. Lors de sa divulgation en décembre 2021, elle affichait un score CVSS de 10,0 — le maximum de gravité. Un correctif était disponible presque immédiatement. Le fait que 41 % des attaques contre la santé britannique sur les cinq premiers mois de 2026 ciblent encore cette faille n’incrimine pas une organisation en particulier. C’est la gestion sectorielle de la correction des vulnérabilités anciennes qui est en cause. Une analyse de risques formelle, cartographiant les dépendances Log4j dans chaque application fournie par un éditeur — et pas seulement dans les développements internes — est la première étape pour hiérarchiser les corrections.

Pourquoi Log4Shell persiste dans les environnements cliniques

Log4j n’est pas un produit que les hôpitaux achètent et installent directement. Il s’agit d’une bibliothèque — un composant intégré à d’autres logiciels. Un système d’information de radiologie, une plateforme de dossier patient informatisé, un portail de prise de rendez-vous, des outils d’aide à la décision clinique — tous peuvent embarquer Log4j, parfois à plusieurs niveaux de dépendance, souvent sans que l’équipe IT de l’hôpital n’en ait connaissance. Lors de la divulgation de Log4Shell, de nombreux organismes ont découvert que leur exposition ne venait pas de logiciels déployés en interne, mais d’applications cliniques fournies par des éditeurs dont les dépendances Log4j n’avaient jamais été inventoriées de façon systématique.

Corriger Log4Shell ne se résume donc pas à valider une mise à jour. Il faut identifier chaque application contenant Log4j, collaborer avec chaque éditeur pour obtenir et valider une version corrigée, puis gérer le processus de contrôle du changement sur des systèmes critiques pour les flux cliniques. Dans un grand groupe hospitalier exploitant des dizaines d’applications cliniques — certaines maintenues par des éditeurs eux-mêmes lents à corriger — cela représente un vrai défi opérationnel. Appliquer une classification rigoureuse des données à l’inventaire des dépendances logicielles — en identifiant les applications traitant des informations médicales protégées et les composants Log4j présents dans ces flux — permet aux équipes IT de prioriser la correction sur les points d’exposition les plus à risque.

Les systèmes cliniques ont aussi des exigences de disponibilité qui compliquent les fenêtres de correction. Un hôpital ne peut pas mettre hors ligne ses systèmes de gestion des patients à 2h du matin sans impacter les soins. Les processus de gestion du changement, la validation par les parties prenantes cliniques et les exigences documentaires réglementaires ajoutent des semaines, voire des mois, à ce qui devrait être un cycle de correction simple. Certaines applications cliniques anciennes sont en pratique orphelines — toujours utilisées mais plus maintenues par leur éditeur d’origine. Ces systèmes ne recevront peut-être jamais de correctif Log4Shell, obligeant les organismes à choisir entre accepter un risque permanent ou engager des migrations applicatives coûteuses.

Aucune de ces difficultés structurelles ne justifie plus de quatre ans d’exposition non résolue. Elles expliquent pourquoi la correction prend plus de temps dans la santé que dans d’autres secteurs. Mais elles n’expliquent pas pourquoi 264 000 attaques ciblant cette vulnérabilité en cinq mois ne déclenchent pas une réaction sectorielle massive. Ce décalage — entre menace documentée et inaction persistante — c’est précisément ce que révèlent les données SonicWall.

La dimension étatique et l’attribution à l’Iran

Un volume de 264 000 attaques en cinq mois contre un secteur national de la santé ne correspond pas à du cybercrime opportuniste à grande échelle. Les groupes criminels motivés par l’argent ciblent bien la santé, mais la densité et la concentration de ces attaques pointent vers une opération coordonnée. Les chercheurs de SonicWall désignent l’Iran comme source potentielle — une attribution à prendre au sérieux, même si l’attribution dans le cyberespace reste incertaine par nature.

Les menaces persistantes avancées (APT) associées à des acteurs étatiques iraniens ont déjà ciblé hôpitaux, instituts de recherche et laboratoires pharmaceutiques dans les pays occidentaux. Les motivations sont diverses : les dossiers médicaux figurent parmi les données les plus recherchées sur le marché du renseignement, car ils contiennent des informations d’identité, des comportements, des données financières, et parfois des éléments sur des personnels gouvernementaux ou militaires. Les organismes de santé sont aussi des cibles de choix pour la perturbation — mettre hors ligne des systèmes hospitaliers crée une pression publique immédiate et démontre une capacité sans escalade militaire.

La méthode APT pour ce type de ciblage est méthodique : scanner massivement les systèmes exposés, prioriser ceux qui ne sont pas corrigés, établir un accès persistant et opérer discrètement sur la durée. Log4Shell s’y prête parfaitement. Elle est largement répandue dans les logiciels d’entreprise, reste sous-corrigée dans la santé, et permet une exécution de code à distance sans authentification. Une exploitation de Log4Shell aujourd’hui peut rester invisible pendant des mois. Une plateforme SIEM qui collecte les journaux en temps réel de tous les systèmes cliniques permet de détecter ce type d’intrusion persistante — sans corrélation centralisée des logs, ces attaques restent indétectables.

Les attaques par ransomware contre la santé ont un impact humain qui les distingue de celles visant la finance ou le commerce. Quand les systèmes hospitaliers tombent, les soins aux patients sont directement affectés : opérations reportées, dossiers médicaux inaccessibles, urgences redirigées, créant des risques en cascade sur tout le réseau. Les conséquences d’un accès étatique persistant — collecte de renseignements, préparation à la perturbation, manipulation potentielle de données cliniques — sont suffisamment graves pour traiter ce scénario comme une menace de premier ordre, et non comme un simple problème de gestion des vulnérabilités.

Obligations HIPAA et déficit de gestion des correctifs

La situation Log4Shell dans la santé britannique a un équivalent direct aux États-Unis. Les organismes soumis à la HIPAA Security Rule doivent respecter des exigences techniques explicites, qui s’appliquent directement aux scénarios de vulnérabilités non corrigées. La Security Rule impose aux entités couvertes et à leurs partenaires de mettre en œuvre des procédures pour examiner régulièrement les journaux d’activité des systèmes d’information et de maintenir des mesures de sécurité techniques protégeant contre les accès non autorisés aux informations médicales protégées transmises sur les réseaux électroniques.

La Security Rule ne fixe pas de délai précis pour l’application des correctifs, mais elle impose une analyse de risques pour identifier les menaces pesant sur les informations médicales protégées et un programme de gestion des risques mettant en œuvre des mesures de sécurité suffisantes pour ramener ces risques à un niveau raisonnable et approprié. Un organisme de santé ayant mené une analyse de risques, identifié une exposition Log4Shell dans des systèmes proches des informations médicales protégées et n’ayant pris aucune mesure corrective aurait du mal à se justifier lors d’une enquête pour violation menée par l’OCR. La règle du minimum nécessaire de la HIPAA renforce cette exigence : limiter l’accès au strict nécessaire suppose que les contrôles fonctionnent correctement — ce qu’une faille exploitée remet directement en cause.

La conformité HIPAA est une obligation opérationnelle continue, et non une certification ponctuelle. Les organismes de santé qui laissent Log4Shell persister dans leurs environnements doivent voir la vague d’attaques actuelle comme un signal d’alarme : priorité aux correctifs d’urgence, mise en place de mesures compensatoires si la correction immédiate est impossible, et surveillance accrue des systèmes connus pour être vulnérables. Le HITECH Act ajoute une dimension supplémentaire — les obligations de notification en cas de violation imposent qu’une exploitation réussie de Log4Shell ayant exposé des informations médicales protégées déclenche des notifications obligatoires, avec des conséquences réputationnelles et opérationnelles lourdes, au-delà des sanctions réglementaires. Une procédure documentée de gestion des violations — distincte du plan général de gestion des incidents — couvrant spécifiquement les scénarios Log4Shell, l’évaluation du périmètre PHI et le délai de notification HIPAA de 60 jours, donne aux responsables conformité la structure nécessaire pour agir vite en cas d’incident.

Des journaux d’audit détaillés sont une exigence technique centrale de la HIPAA et un outil clé de réponse aux incidents. Lors d’une exploitation Log4Shell sur un système clinique, les questions immédiates sont : quels systèmes ont été touchés, quelles données ont été consultées, des informations médicales protégées ont-elles été exfiltrées, et combien de temps l’attaquant est-il resté présent ? Sans traçabilité complète, ces questions restent sans réponse — ce qui aggrave à la fois le risque pour les patients et l’exposition réglementaire.

Comment Kiteworks a réagi à Log4Shell — et ce que cela démontre

Lorsque Log4Shell a été révélée publiquement en décembre 2021, la question immédiate pour chaque éditeur de logiciel d’entreprise était : vos produits utilisent-ils Log4j ? Pour beaucoup, répondre à cette question a pris des jours, voire des semaines, car Log4j était intégré dans des dépendances tierces elles-mêmes imbriquées. Le délai de correction s’est allongé pour les éditeurs nécessitant de longs tests avant de déployer les correctifs en production.

Kiteworks a rapidement identifié et corrigé Log4Shell — aussi appelée Log4jam. En quelques jours après la divulgation, Kiteworks avait évalué son exposition, informé les clients concernés et déployé les correctifs. Cette réactivité reflète un modèle d’exploitation centré sur la réduction maximale du délai entre la révélation d’une vulnérabilité et la protection des clients. Pour une plateforme qui gère des communications de contenu sensible — y compris des informations médicales protégées échangées entre prestataires, assureurs, patients et partenaires de recherche — ce délai de réaction est crucial.

L’architecture appliance virtuelle durcie de Kiteworks vise à réduire la surface d’attaque dès la conception. Contrairement aux plateformes logicielles installées sur des serveurs généralistes, l’appliance Kiteworks présente une empreinte minimale : les services inutiles sont désactivés, le système d’exploitation est durci, la configuration optimisée pour la sécurité. Cette architecture n’élimine pas tout risque de vulnérabilité — aucune architecture ne le peut — mais elle réduit considérablement les surfaces exploitables par un attaquant.

Le chiffrement validé FIPS 140-3 niveau 1 protège les données au repos et en transit sur la plateforme. Les clés de chiffrement contrôlées par le client garantissent aux organismes de santé la souveraineté sur leurs données — Kiteworks ne détient jamais les clés, ce qui signifie qu’un compromis de la plateforme ne peut pas exposer le contenu du client. Pour les organismes gérant des informations médicales protégées sous HIPAA, il ne s’agit pas de fonctions optionnelles. C’est le niveau opérationnel exigé par le contexte de menace documenté par SonicWall.

Protéger les informations médicales protégées quand le périmètre a cédé

L’explosion des exploitations Log4Shell n’est pas qu’un problème de gestion des vulnérabilités. C’est un problème de sécurité du contenu. Les organismes de santé transmettent en permanence des informations médicales protégées — entre prestataires, vers les assureurs, vers les patients, vers les chercheurs, vers les agences de santé publique. Chaque transmission est un point d’exposition potentiel. Quand l’infrastructure qui porte ces transmissions présente des vulnérabilités non corrigées, le contenu lui-même est en danger, même si la faille n’a rien à voir avec le protocole de transmission.

La messagerie sécurisée Kiteworks propose un canal protégé pour la transmission des informations médicales protégées, en dehors des middlewares cliniques où les vulnérabilités Log4Shell sont fréquentes. Le partage sécurisé de fichiers Kiteworks offre un environnement gouverné pour l’échange de documents cliniques, résultats d’imagerie et dossiers de coordination des soins. Le MFT sécurisé prend en charge les flux automatisés — transmission de résultats de laboratoire, dossiers de remboursement, échanges de coordination — via un canal durci et gouverné, qui contourne totalement les middlewares anciens. En faisant transiter les communications de contenu sensible par une plateforme dédiée et durcie plutôt que par une infrastructure généraliste, les organismes de santé réduisent leur dépendance aux systèmes anciens les plus susceptibles de présenter des vulnérabilités non corrigées.

La DSPM pour la santé — la gestion de la posture de sécurité des données appliquée aux systèmes traitant des informations médicales protégées — fournit la visibilité qui manque à beaucoup d’environnements IT de santé. Savoir où résident les informations médicales protégées, quels systèmes y accèdent et quelle est la posture de vulnérabilité de ces systèmes est indispensable pour réduire réellement les risques. Sans cette visibilité, la gestion des correctifs reste réactive : on corrige ce que l’on connaît. Avec la DSPM, les équipes IT peuvent cartographier la surface d’exposition et prioriser la correction sur les systèmes les plus à risque.

Le CISO Dashboard de Kiteworks offre aux responsables sécurité une vue en temps réel de l’activité sur la plateforme — qui accède à quoi, depuis où, et par quel canal. Pour un RSSI de la santé confronté à des attaques Log4Shell à grande échelle, cette visibilité n’est pas un simple confort. C’est une exigence opérationnelle. Savoir que les communications d’informations médicales protégées se font sur une plateforme gouvernée, traçable et chiffrée — et non via une infrastructure ancienne vulnérable — apporte l’assurance nécessaire à la prise de décision sécurité et à la conformité réglementaire.

Le rapport annuel 2026 de Kiteworks sur les risques de sécurité et de conformité identifiait la gestion des vulnérabilités anciennes comme un risque persistant et sous-estimé pour les secteurs réglementés. Les données SonicWall sur Log4Shell valident ce constat : quatre ans après la publication du correctif, les organismes de santé paient encore le prix du report des corrections — et les attaquants savent précisément où chercher.

Construire une posture de sécurité défendable dans la santé

Les conclusions de SonicWall pointent un ensemble d’échecs qu’il est possible de corriger. Les responsables IT qui souhaitent réduire leur exposition à Log4Shell — et à la prochaine vulnérabilité critique qui ne manquera pas d’être révélée — doivent s’attaquer à trois défis liés : la gouvernance de la gestion des correctifs, l’architecture de sécurité du contenu et la préparation à la réponse aux incidents.

La gouvernance de la gestion des correctifs dans la santé est compliquée par les exigences de validation clinique évoquées plus haut. Mais compliqué ne veut pas dire impossible. Les organismes qui ont réduit leur exposition aux vulnérabilités non corrigées l’ont fait en combinant mesures compensatoires et responsabilisation des fournisseurs. Les mesures compensatoires — segmentation réseau, pare-feu applicatif, surveillance renforcée sur les systèmes vulnérables — réduisent la probabilité d’exploitation et limitent les mouvements latéraux, même si la correction est différée. La responsabilisation des fournisseurs consiste à exiger des éditeurs de logiciels cliniques qu’ils documentent leur posture de correction comme condition de renouvellement de contrat. Un éditeur incapable de démontrer sa gestion de Log4Shell représente un risque supply chain — la même discipline de gestion des risques tiers appliquée à la gestion des données doit s’appliquer à la gestion des vulnérabilités lors du renouvellement des contrats.

L’architecture de sécurité du contenu impose de veiller à ce que la transmission et le stockage des informations médicales protégées se fassent sur des plateformes conçues pour la sécurité, et non adaptées a posteriori. Les protocoles de transfert sécurisé de fichiers, le chiffrement de bout en bout et des journaux d’audit détaillés sont le minimum requis — et non des options premium — pour les organismes gérant des informations médicales protégées sous HIPAA. Les principes de protection des données Zéro trust — accès au strict nécessaire, présomption de compromission, limitation des mouvements latéraux — réduisent ce qu’un attaquant peut atteindre, même s’il parvient à pénétrer le réseau.

La préparation à la réponse aux incidents suppose de disposer d’un plan de réponse aux incidents documenté, couvrant spécifiquement le scénario d’exploitation Log4Shell : comment détecter les tentatives d’exploitation, contenir un incident, évaluer l’exposition des informations médicales protégées et respecter les délais de notification HIPAA ? Les organismes qui n’ont pas simulé ce scénario doivent le faire avant que la prochaine vague d’attaques ne transforme l’exercice théorique en incident réel.

Pour en savoir plus sur la façon dont Kiteworks protège les informations médicales protégées et accompagne la conformité HIPAA dans un contexte où les vulnérabilités anciennes comme Log4Shell sont activement exploitées à grande échelle, réservez votre démo personnalisée dès maintenant.

Ressources complémentaires

• Article de blog Comment protéger les données d’essais cliniques dans la recherche internationale
• Article de blog Le CLOUD Act et la protection des données au Royaume-Uni : pourquoi la juridiction compte
• Article de blog Protection des données Zéro trust : stratégies de mise en œuvre pour plus de sécurité
• Article de blog Protection des données dès la conception : comment intégrer les contrôles RGPD à votre programme MFT
• Article de blog Comment prévenir les violations de données grâce au partage sécurisé de fichiers à l’international