275 083 comptes exposés sans le moindre exploit — les 4 leçons de la fuite SNU du 7 septembre

Il n'y a pas eu d'intrusion. Pas de rançongiciel, pas de poste compromis, pas de mot de passe cassé. Le 7 septembre 2026, une base de 275 083 comptes du Service national universel a été revendiquée publiquement, et le mécanisme décrit est d'une banalité qui devrait inquiéter tous les responsables d'applications métier : l'application a répondu, correctement, à des questions qu'elle n'aurait jamais dû accepter.

C'est ce détail qui rend cette affaire intéressante bien au-delà du SNU. Les fuites qui font les gros titres impliquent généralement un attaquant sophistiqué et une chaîne d'exploitation complexe. Celle-ci n'a demandé qu'une chose : remarquer qu'un identifiant dans une URL pouvait être changé.

Les faits, tels qu'ils sont documentés

Un acteur se présentant sous le pseudonyme LunarisSec affirme avoir compromis l'un des portails du Service national universel en exploitant une faille IDOR. Le volume revendiqué se décompose en 270 021 identifiants d'utilisateurs et 5 062 comptes associés à des rôles de gestion de structures partenaires, soit 275 083 comptes au total.

L'observatoire indépendant Cyberattaque.org, qui a publié l'information le 7 septembre 2026, indique avoir obtenu des échantillons diffusés par l'auteur de la revendication. Deux éléments rendent celle-ci crédible : le contenu des échantillons se recoupe avec des sources publiques permettant de les rattacher à l'écosystème SNU, et surtout les traces d'activité présentes dans les données remontent jusqu'aux 5 et 6 septembre 2026. L'extraction est donc récente, et non le recyclage d'une base ancienne.

Une précision de méthode s'impose ici, parce qu'elle change la façon dont il faut lire ce type d'information : à ce stade, il s'agit d'une revendication étayée par des échantillons, pas d'un périmètre confirmé par l'entité concernée. Le volume définitif peut évoluer. Le mécanisme décrit, lui, est parfaitement documenté et c'est celui qui nous intéresse.

Leçon 1 — Authentifier n'est pas autoriser

Une faille IDOR — Insecure Direct Object Reference — est un défaut de contrôle d'accès. L'application expose une référence à une ressource, le plus souvent un identifiant numérique dans une URL ou un appel d'API, et ne vérifie pas que l'utilisateur connecté a le droit d'accéder à cette ressource précise.

La cause profonde est presque toujours la même, et elle est conceptuelle : l'authentification et l'autorisation sont deux contrôles distincts, et beaucoup d'applications n'en implémentent rigoureusement qu'un seul. Le développeur vérifie très correctement qui vous êtes. Puis, une fois la session établie, il considère implicitement que toute requête émanant d'un utilisateur connecté est légitime — et oublie de vérifier ce à quoi vous avez droit.

Ce n'est pas une négligence exotique. Le contrôle d'accès défaillant occupe la première place du Top 10 de l'OWASP, précisément parce qu'il résiste aux outils : il ne se corrige pas par un correctif fournisseur et ne se détecte pas par une signature.

Leçon 2 — Une fuite peut être totalement silencieuse

C'est le point que les directions techniques sous-estiment le plus. Dans une exploitation IDOR, aucune règle n'est franchie au sens technique. L'attaquant est authentifié. Ses requêtes sont bien formées. Il utilise l'application exactement comme elle a été conçue pour être utilisée.

Un pare-feu applicatif ne voit rien : il n'y a ni charge utile malveillante, ni caractère d'échappement, ni tentative d'injection. Les journaux applicatifs enregistrent des consultations valides, avec des codes de réponse 200. Une solution de détection sur les postes est hors sujet, puisque rien n'est exécuté côté client.

Le seul signal exploitable est comportemental, et il est volumétrique : un compte qui consulte plusieurs centaines de milliers de fiches distinctes, séquentiellement, en un temps court, ne se comporte pas comme un utilisateur. Encore faut-il avoir instrumenté cette métrique. Dans la grande majorité des applications métier que nous auditons, personne ne compte le nombre de ressources distinctes consultées par compte et par heure. C'est pourtant la seule alarme qui aurait sonné ici.

Leçon 3 — Le SNU n'est pas un cas isolé

Replacer cette fuite dans sa semaine est instructif. Sur la période du 5 au 8 septembre 2026, l'observatoire Cyberattaque.org a recensé une série d'incidents français touchant des organisations de toutes tailles et de tous secteurs :

• Footsider, application de recrutement dans le football : environ 153 000 enregistrements de comptes exposés.
• LesCuristes.fr, plateforme dédiée au thermalisme : messages et coordonnées d'environ 86 000 personnes.
• Une plateforme d'emploi du département de l'Aveyron : plus de 20 000 profils et 1 500 CV concernés.
• Jinko, plateforme d'accompagnement en oncologie : données de santé de plus de 3 500 personnes.
• SAD'S Interim, agence d'intérim visée par le groupe Rhysida, avec des documents d'identité et des données de santé compromis.

Le motif est net et il devrait faire réfléchir toute PME qui se croit hors cible : ce ne sont pas des banques ni des opérateurs d'importance vitale. Ce sont des associations, des plateformes sectorielles, une agence d'intérim, une collectivité. Des organisations qui gèrent des données sensibles avec des équipes techniques réduites et, le plus souvent, sans revue de sécurité applicative.

Leçon 4 — Le test tient en une demi-heure

La bonne nouvelle, c'est que la vérification est triviale à décrire et ne demande aucun outil coûteux. Créez deux comptes utilisateurs, A et B, avec des droits équivalents et des données distinctes. Connectez-vous en tant que A et relevez, dans votre navigateur, tous les identifiants de ressources qui apparaissent dans les URL et les appels d'API. Puis rejouez exactement ces requêtes avec la session de B.

Toute réponse autre qu'un refus explicite est une faille. Un code 200 qui renvoie les données de A à l'utilisateur B est directement exploitable, et l'automatiser tient en quelques lignes de script.

Deux pièges reviennent systématiquement dans nos audits. D'abord, ne tester que la lecture : les défauts de contrôle d'accès en modification et en suppression sont plus rares mais nettement plus destructeurs. Ensuite, compter sur un scanner automatique : un outil ne connaît pas votre modèle d'autorisation métier et ne peut pas savoir que la fiche 4312 appartient à l'utilisateur A. C'est exactement le type de faille qu'un test d'intrusion manuel va chercher en priorité, et que la conformité documentaire seule ne détectera jamais.

Enfin, remplacer les identifiants séquentiels par des identifiants non devinables limite la découverte, mais ne corrige rien : c'est une mesure de ralentissement, pas un contrôle d'accès. La seule correction réelle est une vérification d'autorisation côté serveur, sur chaque requête, pour chaque ressource.

Ce que vous devez faire si cela vous arrive

Le cadre réglementaire ne laisse pas de marge d'appréciation, et le délai est plus court que ce que la plupart des équipes anticipent. Si des données à caractère personnel sont concernées, le RGPD impose une notification à la CNIL dans les 72 heures suivant la prise de connaissance de la violation, ainsi qu'une information des personnes concernées lorsque le risque pour leurs droits et libertés est élevé.

Les entités relevant de la directive NIS2 ont en parallèle leurs propres obligations de signalement, avec une alerte précoce sous 24 heures. Le point de vigilance opérationnel est le même dans les deux cas : le délai court à partir du moment où vous avez connaissance de l'incident, pas à partir du moment où votre analyse technique est terminée. Il faut donc notifier avec les éléments dont vous disposez, puis compléter — et non attendre d'avoir tout compris. Si votre périmètre d'obligations n'est pas clair, notre page sur l'audit de périmètre NIS2 détaille les seuils applicables.

Le même principe vaut bien au-delà des applications classiques : dès qu'un service expose des identifiants de ressources, la question de l'autorisation par requête se pose à l'identique. C'est vrai des interfaces d'administration internes, des API partenaires, et jusqu'aux applications décentralisées dont les enjeux de contrôle d'accès sont recensés par l'annuaire des agences Web3 françaises. La technologie change, le défaut reste le même.

Ce qu'il faut retenir

La fuite SNU du 7 septembre ne raconte pas une histoire d'attaquants brillants. Elle raconte une application qui faisait correctement la moitié de son travail de sécurité — vérifier l'identité — et qui a omis l'autre moitié.

C'est une bonne et une mauvaise nouvelle à la fois. Mauvaise, parce que vos outils de sécurité périmétrique ne vous protègent pas de ce défaut et ne vous préviendront pas s'il est exploité. Bonne, parce que le contrôle correctif est à votre portée immédiate : deux comptes de test, une session rejouée, et une vérification d'autorisation côté serveur sur chaque requête.

La question à poser à votre équipe cette semaine n'est pas « sommes-nous protégés ». C'est : « combien de fiches un seul de nos comptes peut-il consulter en une heure, et qui s'en apercevrait ? »