JeVeuxAider.gouv.fr : 558 952 bénévoles exposés via une faille IDOR

La plateforme JeVeuxAider.gouv.fr — service de la Réserve civique opéré par l'État — a confirmé un incident de sécurité entraînant la fermeture temporaire du site. Le communiqué officiel relayé par Presse Agence indique que la plateforme a été suspendue « par mesure de précaution » après détection d'un accès non autorisé. Selon l'analyse des échantillons publics par Cyberattaque.org et FrenchBreaches, la base revendiquée recense 558 952 personnes uniques, 1 248 305 enregistrements et environ 421 131 adresses email uniques. La revendication est portée par le pseudonyme misere sur un forum cybercriminel.

Vecteur revendiqué

L'attaquant attribue l'accès à une vulnérabilité IDOR (Insecure Direct Object Reference) sur une API de la plateforme, accessible aux utilisateurs disposant d'un compte. La collecte aurait été réalisée « sur plusieurs heures, en automatisant les requêtes depuis plusieurs adresses IP et plusieurs comptes utilisateurs », selon la description reprise par Tom's Guide et L'Info Durable.

Le motif est identique à celui observé sur les revendications SSTRN et Optic 2000 ces dernières semaines : une autorisation insuffisante sur des identifiants énumérables, sans détection ni rate-limiting suffisant pour bloquer l'aspiration. Aucune compromission de mot de passe, aucune intrusion d'infrastructure — un script qui itère.

Périmètre des données

Selon le communiqué et les inventaires publiés, l'exposition couvre :

• Identité civile : nom, prénom.
• Coordonnées : adresse email, numéro de téléphone.
• Date de naissance.
• Historique d'engagement des bénévoles sur la plateforme (missions, candidatures, échanges associatifs).

Sont explicitement hors périmètre d'après la plateforme : mots de passe (non compromis), données bancaires (non stockées) et pièces d'identité (non stockées). Le verrou côté authentification a tenu — c'est la couche d'autorisation côté API qui a cédé.

Statut de l'attribution

Le pseudonyme misere est le même que celui revendiquant la fuite SSTRN une semaine plus tôt. Aucune attribution étatique, aucun groupe rançongiciel cité, aucune communication officielle de l'État ne va au-delà du constat technique. La revendication doit être traitée comme un point de départ d'enquête. L'authenticité des 558 952 enregistrements n'est pas confirmée par la plateforme — c'est l'analyse des échantillons publiés par les observatoires francophones qui aboutit à ce chiffre.

Réponse de la plateforme et de l'État

Le communiqué officiel détaille la séquence :

• Cellule de crise activée à la détection.
• Équipes techniques mobilisées avec l'appui de la DINUM (Direction interministérielle du numérique) pour sécuriser la plateforme et évaluer le périmètre.
• Identification et correction de la vulnérabilité exploitée.
• Audit complet de sécurité en cours avec accompagnement DINUM.
• Notification aux autorités compétentes — de facto la CNIL au titre du RGPD.
• Fermeture temporaire maintenue tant que l'audit n'est pas achevé.

Que faire

1. Bénévoles JeVeuxAider : considérer email, téléphone et date de naissance comme désormais publics. Activer 2FA partout où le téléphone sert de second facteur. Le combo {nom + email + téléphone + date de naissance} est le carburant standard du phishing ciblé et de la fraude à l'usurpation auprès des opérateurs télécom (SIM-swap).
2. Associations partenaires de la Réserve civique : auditer les flux d'API liés à la plateforme. Si une intégration côté association consomme les mêmes endpoints, vérifier que vos contrôles d'autorisation ne reposent pas sur la confiance dans l'identifiant transmis.
3. DSI publiques exploitant des plateformes citoyennes : c'est le moment d'inventorier les API exposées dont les routes de lecture renvoient des ressources personnelles indexées par entier auto-incrémenté. Le test est trivial : itérer ?id=1, ?id=2, vérifier que l'utilisateur authentifié n'obtient que ses ressources. Si vous ne pouvez pas le démontrer en cinq minutes, c'est probablement exploitable.
4. RSSI : le rate-limiting n'est pas un contrôle d'autorisation, mais c'est le filet qui transforme une fuite à grande échelle en signal d'alerte avant les 500 000 enregistrements. Sur les endpoints qui renvoient des ressources nominatives, un quota par compte et par IP, plus une alerte sur dérive de volume, sont des contre-mesures bon marché.
5. Notification CNIL et information des personnes : la plateforme a indiqué avoir notifié les autorités compétentes. Les bénévoles concernés devraient recevoir une information individuelle au titre de l'article 34 du RGPD — vérifier sa réception et son contenu (catégories de données, mesures recommandées).

Contexte

C'est la troisième fuite IDOR d'ampleur revendiquée sur une plateforme française en moins d'un mois, après SSTRN (355 000 dossiers de médecine du travail, même pseudonyme misere) et Optic 2000 (7 898 PDF, AplaGroup). Côté plateformes étatiques, c'est la deuxième compromission visible en huit jours après Tchap — vecteur différent (usurpation de compte plutôt qu'IDOR), même conséquence opérationnelle : la DINUM en cellule de crise.

L'IDOR n'est pas un bug binaire, n'a pas de CVE, n'apparaît dans aucun scanner SAST classique sans configuration métier. C'est une erreur d'architecture d'autorisation qui se détecte par revue de code et tests d'intrusion sur les endpoints exposant des ressources personnelles. Si la rédaction devait parier sur la prochaine fuite revendiquée sur une plateforme française, ce serait à nouveau ce même motif. La couche d'authentification publique de l'État (FranceConnect, AgentConnect) gère l'identité ; elle ne décide pas, pour les applications qui s'y connectent, quelle ressource appartient à quel utilisateur. Cette responsabilité reste, plateforme par plateforme, au code applicatif — et c'est là que le score est mauvais en 2026.