J’ai découvert une vulnérabilité. Ils ont trouvé un avocat

• L’auteur, instructeur de plongée et ingénieur plateforme, a découvert une grave vulnérabilité de sécurité dans le portail membres d’un assureur de plongée
• Le portail utilisait des ID utilisateur séquentiels et le même mot de passe par défaut, permettant à n’importe qui d’accéder aux données personnelles d’autres membres avec une simple combinaison
• Il a signalé le problème simultanément au CSIRT Malta et à l’organisation concernée, mais au lieu de le remercier, l’organisation a averti d’un risque de responsabilité pénale par l’intermédiaire de son représentant juridique
• L’auteur a refusé de signer un engagement de confidentialité (NDA) et a proposé à la place une déclaration corrigée confirmant uniquement la suppression des données, mais l’organisation a de nouveau proféré des menaces en invoquant un risque de diffamation
• L’affaire met en lumière l’importance d’une procédure de divulgation responsable des vulnérabilités et la réalité des menaces juridiques qui dissuadent de protéger les chercheurs

---

Découverte de la vulnérabilité

• Lors d’un voyage de plongée sur l’île Cocos, au Costa Rica, l’auteur a découvert un défaut structurel dans le portail membres d’un assureur de plongée
  • Lorsqu’un instructeur enregistrait un élève, le système générait un ID numérique séquentiel et un mot de passe par défaut inchangé
  • Comme de nombreux utilisateurs ne modifiaient pas leur mot de passe, il était possible d’accéder à l’intégralité des données personnelles d’autres membres (nom, adresse, date de naissance, coordonnées, etc.)
• Aucune mesure de sécurité de base comme l’obligation de changer le mot de passe, la limitation des connexions ou la MFA n’était en place
• Certains comptes contenaient aussi les informations de mineurs (14 ans)
• L’auteur a vérifié le problème avec un accès minimal, puis a immédiatement cessé toute action, et toutes les données collectées ont été supprimées définitivement

Vérification et preuve

• Il a essayé avec Python requests, mais en raison d’une structure de session complexe, la vérification a été faite via une automatisation du navigateur avec Selenium
  • Il suffisait de saisir l’ID utilisateur et le mot de passe par défaut pour se connecter
  • Le script d’automatisation est publié comme exemple de code non fonctionnel, et tous les identifiants réels ont été supprimés
• Les exemples de sortie incluaient l’ensemble des données de profil, comme le nom, l’e-mail, l’adresse et la date de naissance
• Ce processus a également confirmé que plusieurs comptes de mineurs étaient exposés de la même manière

Procédure de divulgation de la vulnérabilité

• La vulnérabilité a été officiellement signalée le 28 avril 2025, avec un délai de grâce de 30 jours pour corriger le problème
• Un e-mail a été envoyé simultanément au CSIRT Malta et à l’organisation concernée
  • Le rapport incluait un résumé du problème, un risque potentiel de violation du GDPR, des captures d’écran et un lien PoC chiffré
  • Il demandait un accusé de réception sous 7 jours et une correction sous 30 jours
• Il s’agissait d’une procédure standard conforme à la politique nationale de divulgation des vulnérabilités (NCVDP)

Réponse de l’organisation

• Deux jours plus tard, la réponse est venue non pas de l’équipe IT, mais d’un avocat chargé de la protection des données (cabinet juridique du DPO)
  • Le message mentionnait la réinitialisation des mots de passe et l’introduction de la 2FA, mais reprochait d’avoir d’abord informé un organisme public
  • Il avertissait que les actes de l’auteur pourraient constituer une infraction au regard du code pénal maltais, avec une possible responsabilité juridique
• L’organisation a exigé la signature d’une déclaration de confidentialité, ainsi que la remise d’une copie du passeport, avec une échéance de signature le jour même
  • La déclaration incluait une clause stipulant que « le contenu de cette déclaration restera confidentiel », ce qui revenait de fait à une NDA (accord de confidentialité)
• Ensuite, les demandes répétées de signature se sont poursuivies sous des intitulés comme « rappel amical » ou « notification urgente »

Refus et réponse du chercheur

• L’auteur a refusé de signer une clause de confidentialité et a proposé à la place une déclaration révisée confirmant uniquement la suppression des données
  • Il a précisé que l’information transmise au CSIRT Malta faisait partie de la procédure officielle et que l’analyse après divulgation relevait des pratiques standard du secteur de la sécurité
• L’organisation a cité l’article 337E du code pénal (computer misuse), avertissant que même des actes commis à l’étranger pourraient être considérés comme des infractions à Malte
• Elle a également indiqué que toute mention du nom de l’organisation sur un blog ou lors d’une conférence pourrait entraîner une action en diffamation et en réparation du préjudice
• La vulnérabilité a désormais été corrigée, et la réinitialisation des mots de passe par défaut ainsi que l’introduction de la 2FA sont en cours
• Cependant, il n’est pas confirmé si les victimes ont été notifiées, conformément aux articles 33 et 34 du GDPR

Transfert de responsabilité et violation du GDPR

• L’organisation a soutenu que « changer le mot de passe relève de la responsabilité de l’utilisateur »
• Or, selon l’article 5(1)(f) et l’article 24(1) du GDPR, le responsable du traitement doit mettre en place des mesures techniques et organisationnelles appropriées
• Des mots de passe par défaut identiques et des ID séquentiels constituent clairement des mesures de sécurité inadaptées

Un schéma récurrent

• Il existe toujours un effet dissuasif (Chilling Effect) où les chercheurs en sécurité qui divulguent une vulnérabilité de manière responsable se heurtent à des menaces juridiques
• La réponse juridique détériore au contraire la réputation, et le problème n’est pas la vulnérabilité elle-même, mais la manière dont l’organisation réagit

La bonne procédure de réponse

• Accuser réception du signalement et corriger le problème
• Remercier le chercheur
• Mettre en place une politique de CVD (Coordinated Vulnerability Disclosure)
• Notifier les utilisateurs concernés, en particulier pour protéger les mineurs
• Ne pas imposer le silence via une NDA

Conseils pour les organisations et les chercheurs

• Les organisations devraient mettre en place une procédure de divulgation claire, par exemple avec security.txt, et remercier les chercheurs
• Les chercheurs devraient impliquer le CSIRT national, conserver tous les échanges, supprimer les données puis refuser toute clause de confidentialité
• La directive NIS2 encourage la divulgation responsable des vulnérabilités au sein de l’UE
• Même en 2026, la réalité demeure qu’un simple signalement de vulnérabilité peut encore déboucher sur des menaces juridiques

[GN⁺]

Avis sur Hacker News

• D'autres personnes ont aussi repéré des ID utilisateur incrémentaux et les ont testés, puis ont fini en prison
  À partir du moment où l'on teste de cette façon, on s'expose à un risque de violation du CFAA
  Si l'on savait déjà que les ID étaient incrémentaux et qu'un mot de passe par défaut était configuré, il aurait fallu signaler la vulnérabilité immédiatement à ce moment-là
  Dès l'instant où le test a été exécuté, cela a pu constituer une infraction à la loi
  Écrire ce texte maintenant revient pratiquement à faire des aveux, donc il faut engager un avocat et étudier le droit applicable

• Je n'ai pas d'expertise juridique, mais j'ai trois réflexions

  1. Si une procédure de divulgation légale est trop difficile, alors au final seules des personnes malveillantes signaleront les vulnérabilités
  2. Dans d'autres secteurs, il serait absurde qu'un architecte soit poursuivi pour avoir découvert un défaut dans un bâtiment. Cela dit, la cybersécurité est différente dans la mesure où le simple fait de connaître un défaut augmente le risque
  3. Le fait qu'un inconnu de passage fasse un audit est trop instable. Si un site web exige mes PII (informations personnelles identifiables), je devrais avoir le droit d'exiger que ces données soient sécurisées
     Des entreprises comme les assureurs devraient être légalement tenues de subir des audits cyber, les hackers white hat devraient être protégés, et les utilisateurs devraient pouvoir engager des recours collectifs
     Dans ce cas, les vulnérabilités basiques disparaîtraient et les ingénieurs logiciel deviendraient économiquement plus utiles que les avocats
  • Dans d'autres secteurs, il existe un statut d'ingénieur agréé avec responsabilité juridique
    Je me demande si l'informatique ira dans cette direction à l'ère de l'IA
    Les ingénieurs agréés approuvent les conceptions et réalisent les inspections, jouant un rôle clé dans la garantie de la sécurité
    Leur autorité et leur responsabilité sont donc importantes, tout comme leur rémunération
  • Dans d'autres secteurs, les concepteurs ont une assurance et une licence
    Je ne veux pas empêcher les développeurs débutants de contribuer à l'open source, mais je pense que les sites qui gèrent de grandes quantités de données personnelles ou d'argent devraient nécessiter la signature d'un ingénieur logiciel certifié
    Cela donnerait un moyen de résister aux exigences déraisonnables de la direction
    Bien sûr, quand on voit les cas de Boeing ou Volkswagen, ce n'est pas une solution parfaite
  • Dans certains pays, même la vérité peut relever de la diffamation
    Autrement dit, signaler un problème aux autorités et le rendre public dans la presse sont deux choses totalement différentes
    Surtout dans des endroits comme Malte, où le crime organisé et la corruption sont graves, une personne qui rendrait cela public pourrait subir un « accident »

• J'utilise une adresse e-mail différente pour chaque service
  Il y a environ 15 ans, j'ai commencé à recevoir du spam sur l'adresse diversalertnetwork
  Quand j'ai signalé à DAN qu'il y avait eu une compromission, je n'ai reçu qu'un e-mail me demandant de changer mon mot de passe
  Je m'estime heureux de ne pas avoir fait l'objet de poursuites pénales

  • C'était peut-être un piratage, ou l'entreprise a pu vendre les données à un tiers
  • J'ai vécu quelque chose de similaire. J'ai commencé à recevoir du spam sur une adresse réservée à la compagnie aérienne portugaise, et l'entreprise n'a jamais répondu

• Le fait que l'auteur ait peur de révéler le nom de l'organisation montre que les menaces juridiques ont été efficaces

  • Ou bien, dans la communauté de la plongée, l'expression « assureur pour plongeurs basé à Malte » suffit déjà à désigner DAN Europe
  • Vu les indices dans le texte, parmi les assureurs internationaux de plongée, le seul enregistré à Malte est DAN Europe, donc cela paraît quasiment certain
  • Bien sûr, on ne peut pas exclure non plus la possibilité qu'il ait vendu les informations à des black hats

• À propos de la demande de « signer une attestation de suppression des données », on peut se demander pourquoi il a signé
  L'entreprise semble avoir voulu contrôler la situation plutôt que coopérer

  • Mais si l'on amène l'autre partie à accepter ses conditions, on neutralise sa stratégie de contrôle tout en obtenant une force juridiquement contraignante

• Le schéma dans lequel des chercheurs en sécurité signalent des vulnérabilités puis reçoivent des menaces juridiques se répète depuis des décennies
  Les gouvernements et les entreprises parlent de l'importance de la cybersécurité, mais en pratique ils sont hostiles aux chercheurs
  Il faut une législation pour empêcher ce type de réaction abusive
  On peut voir des cas similaires dans ce lien

• Je me demande si l'entité concernée dans cette affaire est DAN Europe et sa filiale IDA Insurance Limited

  • Cela a déjà été déduit dans un autre commentaire

• En Allemagne, lancer un script de cette manière pour accéder aux données d'autrui est illégal
  C'est comme entrer dans la voiture de quelqu'un et la démarrer sous prétexte que la porte était ouverte
  Pour une explication juridique connexe, voir cet article

  • Dans ce cas, la loi doit changer. À ce niveau de négligence en matière de sécurité, rien ne s'améliorera jamais sans lanceur d'alerte de bonne foi ou fuite massive
  • Je suis d'accord aussi. Il faut savoir où s'arrêter
    Prendre des captures d'écran et signaler le problème dans le cadre d'un usage normal du site, c'est acceptable, mais collecter des données avec un script Python franchit la ligne rouge
    C'est comme voir la porte d'une banque ouverte et entrer au lieu d'appeler la police
  • Espérons que des criminels n'exploitent pas cette faille

• L'an dernier, j'ai découvert une vulnérabilité dans le système de billetterie d'un grand événement
  Le lien du billet reçu par e-mail était simplement un encodage base64 d'un numéro de commande séquentiel
  Cela signifiait qu'il était facile de télécharger aussi les billets d'autres personnes
  J'ai envoyé un e-mail aux organisateurs et à l'entreprise de développement, mais je n'ai eu aucune réponse, et c'est toujours exposé aujourd'hui
  Je compte vérifier lors de l'événement de cette année si cela a été corrigé

• Si les ID utilisateur étaient séquentiels et que le mot de passe par défaut était identique, la vraie vulnérabilité était l'« hypothèse qu'il existe un responsable sécurité »
  De nos jours, la « divulgation responsable » consiste surtout à donner à l'entreprise le temps d'engager des avocats