Logiciels de santé : un correctif planifié cinq ans après le signalement, le CERT-FR et le CERT Santé épinglent les éditeurs
Le 2 octobre 2026, le CERT-FR et le CERT Santé ont publié un retour d'expérience de six pages sur les vulnérabilités des produits du secteur santé. Le constat est sévère : pour quatre éditeurs importants, le traitement de vulnérabilités dure depuis plus d'un an, et dans un cas le dernier correctif a été planifié cinq ans après le signalement. Pour un DPO d'établissement de santé, c'est un sujet de sous-traitance autant que de sécurité.
Ce que le CERT-FR et le CERT Santé ont constaté
Le rapport, référencé CERTFR-2026-CTI-007, s'appuie sur des cas réels anonymisés issus du traitement des vulnérabilités signalées par des tiers et des accompagnements lors d'incidents. Il cite un sondage de l'Agence du Numérique en Santé auprès d'établissements de santé : 82 % des répondants ont eu connaissance de vulnérabilités sur leur système au cours des douze derniers mois, 74 % ont été confrontés à des éditeurs qui tardent ou refusent de corriger, et 90 % n'ont pas de canal formalisé pour remonter une faille à l'éditeur. Les incidents d'origine malveillante traités par le CERT Santé sont passés de 328 en 2024 à 400 en 2025, soit +22 %.
Quatre familles de défauts sont décrites :
- Des délais de correction trop longs, notamment parce que les correctifs de sécurité sont intégrés à des évolutions fonctionnelles, parfois payantes, que les clients retardent ou ne déploient pas.
- Une mauvaise gestion des secrets chez au moins trois éditeurs majeurs : secrets accessibles par simple saisie d'une URL, répertoire .git exposé, identifiants administrateur dans le code, comptes de télémaintenance laissés à leur valeur par défaut. Ces cas ont été corrigés depuis.
- Des injections de code (XSS, SQLi). Lors d'un contre-audit, une application restait vulnérable à plusieurs XSS plus d'un an après le correctif initial.
- Un contrôle d'accès déficient, qui permet à un utilisateur légitime, praticien ou parfois simple patient, d'accéder aux données d'autres utilisateurs. Selon le rapport, ce type de faille est particulièrement exploité actuellement, notamment sur des solutions en mode SaaS, les attaquants commençant généralement par compromettre un compte de professionnel de santé.
Les deux CERT signalent aussi de nombreuses instances d'un même logiciel de santé exposées sur Internet sans authentification. D'après l'éditeur, certains accès VNC ont été fermés, tandis que d'autres clients ont choisi de les maintenir en signant une décharge de responsabilité.
Pourquoi c'est important
Ces logiciels traitent des données de santé, catégorie particulière au sens du RGPD (voir notre guide RGPD et santé). L'établissement qui les déploie reste tenu, comme responsable de traitement, de mettre en place des mesures de sécurité adaptées au risque au titre de l'article 32 du RGPD, et de ne recourir qu'à des sous-traitants présentant des garanties suffisantes au titre de l'article 28. Une décharge de responsabilité signée au profit d'un éditeur ne fait pas disparaître ces obligations.
Le rapport replace ces constats dans le calendrier du Cyber Resilience Act, le règlement (UE) 2024/2847. Son article 14, qui impose de déclarer les vulnérabilités activement exploitées et les incidents graves, s'applique depuis le 11 septembre 2026 ; le règlement entrera pleinement en application le 11 décembre 2027. Il couvre les logiciels du secteur santé, à l'exception des dispositifs médicaux et des dispositifs médicaux de diagnostic in vitro, qui relèvent de leur propre réglementation. En France, il est prévu que l'Agence nationale des fréquences (ANFR) soit l'autorité de surveillance du marché, avec des amendes pouvant atteindre 15 millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial. Le CERT Santé et le CERT-FR pourront lui signaler les manquements d'un éditeur.
Ce que ça change pour les organisations
- Recenser les logiciels métier qui traitent des données de santé et, pour chacun, l'éditeur, la version déployée et le dernier correctif de sécurité appliqué.
- Demander à chaque éditeur s'il publie ses correctifs de sécurité séparément des évolutions fonctionnelles, et s'il dispose d'une politique de divulgation coordonnée des vulnérabilités, deux exigences de l'annexe I du CRA citées par le rapport.
- Formaliser un canal de remontée des vulnérabilités vers les éditeurs et l'inscrire dans le contrat de sous-traitance, puis le vérifier lors des audits de sous-traitants.
- Vérifier qu'aucun accès distant (télémaintenance, VNC) n'est ouvert sans authentification robuste, et refuser de signer une décharge à la place d'un correctif.
- Mettre en place, comme le recommandent les deux CERT, une détection des accès inhabituels ou massifs aux données sensibles.
Ce que Leto en pense
Ce rapport rappelle que la sécurité d'un logiciel de santé ne se joue pas seulement à l'achat : elle dépend de la vitesse à laquelle l'éditeur corrige, et de ce qu'il en dit à ses clients. Le CRA donnera un levier réglementaire en 2027, mais l'obligation de garanties suffisantes existe déjà dans le RGPD. Le geste utile est opérationnel : suivre, éditeur par éditeur, les délais de correction comme un indicateur de conformité du sous-traitant. Pour préparer les équipes à ces sujets, Leto propose des modules de sensibilisation.
Sources
