SNOSM : 12 Go de code source et 139 000 fiches d'accidents revendiqués

Une publication déposée le jeudi 9 juillet 2026 sur un forum cybercriminel revendique la compromission complète du serveur du Système national d'observation de la sécurité en montagne (SNOSM), dispositif rattaché à l'École nationale de ski et d'alpinisme (ENSA) et hébergé à l'adresse snosm.fr. Elle est signée par le pseudonyme BLACKHATSECT0R, en collaboration avec DXQRTXX et APT-90 — le même triplet apparu quelques jours plus tôt sur la fuite revendiquée à la Fédération Française d'Équitation. À l'heure de rédaction, aucune confirmation officielle n'a été publiée par le SNOSM, l'ENSA ou le ministère des Sports.

Ce qui est revendiqué

Selon les observatoires indépendants Cyberattaque.org, FrenchBreaches et Fuites Infos, qui ont documenté la revendication le jour même de la publication, l'accès annoncé porte sur :

• 11 682 fichiers, soit environ 12 Go de données brutes ;
• le dépôt Git complet de l'application, développé en Laravel 8 côté serveur et Vue.js côté interface ;
• le fichier .env de l'application, qui contient typiquement identifiants de base de données, clés API, secrets applicatifs et identifiants de messagerie ;
• environ 139 000 fiches statistiques d'accidents (Fuites Infos avance le chiffre de 139 128) couvrant âge — avec une proportion notable de mineurs — sexe, commune, nationalité et état médical ;
• 11 années de correspondance messagerie de service (2015–2026), incluant contacts institutionnels et plusieurs adresses gouvernementales ;
• des exports récents liés aux CRS (compagnies républicaines de sécurité) et des statistiques d'accidents datant de mai 2026.

Le SNOSM opère sous l'autorité de l'ENSA à Chamonix et produit, depuis 2004, les bilans d'accidentologie des sports de montagne en France ; la page d'accidentologie de l'ENSA et le bilan 2023 donnent l'ordre de grandeur : quelques dizaines de milliers d'événements consolidés chaque année. Un corpus de 139 000 événements couvrant onze ans est plausible à ce référentiel.

Statut de la revendication

À ce stade, rien n'est confirmé publiquement :

• Aucun communiqué du SNOSM, de l'ENSA ni du ministère des Sports au moment de la rédaction.
• Aucune analyse indépendante d'un échantillon exfiltré n'a été publiée pour recouper les schémas de tables réels de l'application.
• La signature triple BLACKHATSECT0R + DXQRTXX + APT-90 est identique à celle apposée sur la revendication de la FFE huit jours plus tôt — un même auteur revendique deux compromissions à sept jours d'écart, ce qui ne suffit pas à qualifier un collectif structuré et ne dit rien de l'authenticité du corpus. C'est un habillage de mise en scène ; la valeur probante reste dans l'échantillon.

Le pseudonyme APT-90 est présenté par le publieur comme un allié occasionnel ; il ne s'agit pas de la nomenclature de threat intelligence des groupes attribués (chiffre APT-XX) tenue par les éditeurs comme Mandiant ou CrowdStrike. La ressemblance de nommage est volontaire côté auteur, elle n'est pas une attribution.

Que faire

1. SNOSM, ENSA, prestataires d'hébergement : si l'incident est confirmé, considérer comme compromis en clair tout secret du fichier .env revendiqué — DSN de base de données, clés API, mots de passe SMTP, secrets applicatifs Laravel — et procéder à la rotation immédiate. Les identifiants git et les jetons de dépôts privés cités dans la configuration entrent dans le même périmètre. La reconstruction depuis une sauvegarde hors ligne antérieure à mai 2026 est le seul chemin propre pour l'application elle-même si le dépôt Git a effectivement fuité.
2. Personnes potentiellement présentes dans la base d'accidentologie : les données revendiquées incluent nom de commune, nationalité et état médical. Un exercice d'exploitation crédible consisterait à envoyer, à des victimes d'accidents anciens, des courriels d'« indemnisation » ou de « suivi médical » en citant des détails vérifiables — commune, mois, contexte. Aucune administration ne demande ces informations par mail non sollicité ; le rappeler autour de vous cette semaine est plus utile qu'un antivirus supplémentaire.
3. Institutionnels partenaires du SNOSM : la revendication cite des messageries gouvernementales dans les 11 ans d'archives. Les contacts référencés doivent traiter tout mail « en réponse à un fil ancien » avec la même prudence que du hameçonnage ciblé — le vol de fil de correspondance est un vecteur documenté depuis les fuites Emotet, et onze ans d'échanges de service en produisent des centaines.
4. Filière secours en montagne (PGHM, CRS montagne, sapeurs-pompiers de montagne, praticiens du secours médical) : les exports « récents liés aux CRS » revendiqués ne peuvent être qualifiés avant analyse indépendante. En attendant, considérer que l'articulation opérationnelle entre secours civils et SNOSM est potentiellement exposée dans ses métadonnées et adapter la classification interne des messages échangés jusqu'à démenti explicite.
5. Grand public : pas d'action individuelle immédiate à engager en dehors de l'écosystème montagne. Les données revendiquées ne constituent pas un fichier grand public.

Contexte

C'est la seconde revendication de la même signature en huit jours visant une institution française : la FFE le 8 juillet, le SNOSM le 9 juillet. Le mode opératoire annoncé se recoupe — exfiltration d'un dépôt Git applicatif, dump base de données, revendication publique sur forum sans chiffrement préalable — et s'inscrit dans la même dynamique que les fuites récentes chez la Fédération Française Handisport ou la Fédération Française d'Athlétisme. La cible-type se dessine : une structure de mission publique ou associative, budget IT réduit, application métier Laravel/Drupal/Odoo maintenue par un prestataire, base contenant un annuaire à forte valeur métier.

L'élément qui distingue le corpus SNOSM des précédents est la sensibilité individuelle des enregistrements — accidents, état médical, mineurs. Le préjudice potentiel côté personnes n'est pas la fraude au RIB comme sur la fuite FFE, c'est le ciblage d'une population vulnérable identifiable par événement, commune et date. La CNIL — qui n'a pas encore été saisie officiellement au vu des sources publiques — devra, si la revendication se confirme, arbitrer sur la qualification en incident de sécurité de niveau « à risque élevé pour les personnes » au sens de l'article 34 du RGPD, avec le délai de notification individuelle qui va avec.