Le CERT Santé et le CERT-FR ont publié le 2 octobre 2026 un rapport consacré aux vulnérabilités des logiciels utilisés dans les structures de santé. Il contient une phrase qui mérite d’être lue lentement : pour l’un des éditeurs examinés, le déploiement du dernier correctif d’une vulnérabilité de criticité moyenne a été planifié 5 ans après son signalement.
Pour 4 éditeurs importants du secteur, le traitement de vulnérabilités toujours en cours dure depuis plus d’un an. Les éditeurs concernés sont volontairement anonymisés par les 2 CERT, et nous ne tentons aucun rapprochement avec un incident récent : une similitude technique ne constitue pas une identification.
Un sondage de l’Agence du Numérique en Santé repris dans le rapport donne par ailleurs 3 mesures. 82 % des répondants ont eu connaissance de vulnérabilités sur leur système au cours des 12 derniers mois. 74 % ont été confrontés à des éditeurs qui tardent ou refusent de corriger. Et 90 % ne disposent d’aucun canal formalisé pour remonter une vulnérabilité à leur éditeur. Les incidents d’origine malveillante traités par le CERT Santé sont passés de 328 en 2024 à 400 en 2025, soit une hausse de 22 %.
Pourquoi une faille connue reste ouverte
Le rapport énumère les causes, et elles ne sont pas techniques. Les correctifs de sécurité sont systématiquement intégrés à des évolutions fonctionnelles, ce qui impose d’attendre une nouvelle version, souvent très espacée, et ces évolutions étant parfois payantes ou imposant des changements de pratique, les clients peuvent en retarder le déploiement, voire y renoncer. Les éditeurs supportent un grand nombre de versions et d’environnements, héritage d’adaptations successives à des spécificités clients, ce qui multiplie l’effort de test. L’absence de canal prédéfini limite la connaissance qu’ont les clients du risque qu’ils courent. La reprise d’une base de code ancienne coûte cher. Enfin la réglementation propre aux dispositifs médicaux et leur marquage complexifient le déploiement de correctifs.
Aucune de ces causes ne relève de l’attaquant. Elles décrivent un cycle produit, un modèle économique, une dette technique et un cadre réglementaire. La durée pendant laquelle une organisation reste exposée n’est donc pas subie : elle résulte d’arbitrages, pris par l’éditeur et par le client, et répartis sur plusieurs années.
Le second délai, celui dont personne ne parle
Le rapport contient un constat plus inquiétant que le premier, et il est passé inaperçu dans les reprises. Les échanges avec les éditeurs ont plusieurs fois montré qu’une même vulnérabilité était présente à plusieurs endroits d’une application. Pour l’un d’eux, un contre-audit a relevé que le code restait vulnérable à plusieurs injections de script plus d’un an après le correctif initial.
Autrement dit, la date du correctif ne clôt pas nécessairement l’exposition. Une organisation qui tient un registre de ses vulnérabilités y inscrit une date de correction et considère la ligne fermée. Ce contre-audit montre qu’entre la correction annoncée et la correction effective, il peut s’écouler une seconde durée, que personne ne mesure parce que personne ne la cherche. Un correctif non vérifié produit exactement le même effet qu’un correctif absent, avec en plus la conviction d’être protégé.
La mesure palliative est parfois vendue par celui qui a produit le défaut
Le rapport note que dans plusieurs cas, l’usage d’un pare-feu applicatif Web a été conseillé par l’éditeur pour réduire le risque d’exploitation de ses propres vulnérabilités. Puis il ajoute, en incise, que cette solution est parfois vendue par l’éditeur lui-même.
Les 2 CERT précisent qu’un tel dispositif peut contribuer à la sécurité mais ne saurait remplacer l’implémentation des mesures adaptées dans les applications. La phrase est mesurée ; sa portée ne l’est pas. Un client se voit proposer, par le fournisseur à l’origine du défaut, un produit supplémentaire pour en atténuer les conséquences, et ce produit laisse le défaut en place. Cette configuration n’est pas illégale et n’est pas nécessairement de mauvaise foi. Elle mérite simplement d’être nommée quand elle apparaît dans un devis.
Quand le risque est connu, puis accepté par écrit
Les 2 CERT ont identifié de nombreuses instances d’un même logiciel de santé exposées sur Internet et accessibles sans authentification. L’éditeur a sollicité ses clients pour fermer les accès distants concernés. Certains les ont fermés. D’autres ont choisi de les maintenir, et pour ceux-là, écrit le rapport, une décharge de responsabilité a été signée.
Précisons ce que le rapport dit vraiment, parce que la formule est facile à durcir. Les CERT ne condamnent pas l’accès distant : ils écrivent que ce besoin peut être légitime et que, plutôt que d’y renoncer ou d’imposer une solution complexe ou coûteuse, une authentification robuste, native et simple doit être systématiquement configurée. Ce qui est en cause est l’absence d’authentification, pas la télémaintenance.
Reste que la séquence est remarquable. Une faiblesse est identifiée, communiquée, comprise, et l’organisation décide de la conserver en échange d’un document. Nous avons analysé, à propos du premier bilan chiffré du dispositif REACTIV, que l’essentiel des violations recensées par l’ANSSI procédait d’accès légitimes compromis plutôt que de ruptures techniques sophistiquées. Le rapport du CERT Santé ajoute l’étage précédent : certains de ces accès sont restés ouverts après que leur titulaire eut été averti.
Une décharge déplace une responsabilité contractuelle entre 2 parties. Elle ne retire pas une machine d’Internet. Et elle ne lie en rien le patient dont les données sont traitées par cette machine, lequel n’a signé aucun document et ne sait pas qu’il en existe un.
Le cloisonnement sacrifié à la demande du client
Un dernier point mérite l’attention des directions générales, parce qu’il est le seul du rapport qui soit explicitement volontaire. Plusieurs logiciels permettent à un utilisateur disposant d’un accès légitime d’atteindre indûment les données d’autres utilisateurs. Le rapport précise que cet utilisateur peut être un praticien, mais parfois aussi un simple patient.
Ce défaut est actuellement exploité, en particulier sur les solutions en ligne. Les attaquants compromettent d’abord le compte d’un professionnel de santé, par hameçonnage ou par un mot de passe déjà divulgué, puis élargissent progressivement leur périmètre depuis ce compte authentifié, ce qui rend l’activité difficilement détectable.
Or le rapport ajoute que dans certains cas, ce comportement a été développé en connaissance de cause, pour répondre à la demande de clients souhaitant faciliter la coopération sur des dossiers. La réponse des CERT est sans ambiguïté : les demandes des clients ne doivent pas être satisfaites aux dépens de la sécurité, par exemple par une ouverture massive de droits, mais par des solutions adaptées au juste besoin.
Ce qui change au 11 septembre 2026
Le règlement européen sur la cyber résilience impose depuis cette date la déclaration de certaines vulnérabilités activement exploitées et des incidents graves. Son application pleine interviendra le 11 décembre 2027 pour les produits concernés. Les sanctions administratives prévues peuvent atteindre 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial, et des rappels ou retraits de produit sont possibles. Les dispositifs médicaux relevant de leurs propres réglementations font l’objet d’exceptions.
La conséquence pratique est simple à formuler. Une organisation qui achète un logiciel critique n’achète pas seulement une fonction : elle achète la vitesse à laquelle son fournisseur corrigera, la fiabilité de cette correction, et la façon dont il l’en informera. Ces 3 éléments ne figurent presque jamais dans un contrat, alors qu’ils déterminent une exposition qui se compte, ici, en années.
La donnée qui manque aux directions
Le rapport fournit implicitement la mesure à construire, et elle n’existe dans presque aucun tableau de bord. Pour chaque logiciel critique, il faudrait connaître la date du signalement, celle de l’accusé de réception de l’éditeur, celle de la mise à disposition du correctif, celle de son déploiement effectif, le nombre d’instances concernées, la mesure compensatoire retenue, la personne qui a accepté le risque résiduel et la date à laquelle cette acceptation sera réexaminée.
De cette série se déduit une seule valeur, et c’est elle qui devrait être suivie au même titre qu’un taux de disponibilité : l’âge de la plus ancienne vulnérabilité connue encore ouverte. Dans les cas documentés par ce rapport, cette valeur se compte en années, et elle est connue de quelqu’un depuis le premier jour.
Les limites de ce rapport
Les éditeurs et les établissements sont anonymisés, les cas ne sont pas tous datés individuellement, et le rapport ne permet donc ni d’identifier un produit ni de quantifier combien d’établissements sont concernés par chaque situation. Les 3 pourcentages cités proviennent d’un sondage déclaratif auprès de répondants, non d’un audit exhaustif du parc. Enfin, les faiblesses signalées sur la gestion des secrets ont, selon le rapport, été corrigées depuis dans les cas signalés.
