EVA.gg : 70 424 comptes revendiqués après abus d'une API GraphQL

Une revendication publiée le 16 juillet 2026 sur le compte FrenchBreaches attribue à la plateforme française d'esport en réalité virtuelle EVA.gg l'exfiltration de 70 424 comptes utilisateurs et d'environ 119 361 réservations. Selon l'auteur de la publication, l'accès a été obtenu via l'API GraphQL de la plateforme, en reconstruisant le schéma depuis les fichiers JavaScript de l'interface d'administration. Source primaire : la fiche publiée par Cyberattaque.org, avec recoupement chez info.fr et FrenchBreaches.

Ce qui est revendiqué

L'auteur affirme avoir récupéré la base complète de la plateforme :

• 70 424 comptes utilisateurs — identité, adresse email, contact, historique de compte.
• 119 361 réservations — horaires, arènes fréquentées, joueurs associés à chaque session.

Le périmètre couvre l'ensemble du réseau EVA.gg, qui opère plusieurs arènes de VR compétitive en France. Les réservations sont particulièrement sensibles hors du cadre esport : elles reconstituent un historique de présence physique daté, localisé, avec noms des joueurs partenaires. C'est le profil exact d'un jeu de données exploitable pour du phishing très ciblé ou du social engineering visant un individu identifié.

Le vecteur : abus d'API GraphQL, pas d'introspection

Le détail technique publié par la source primaire est le point saillant du dossier. Selon l'auteur de la revendication :

1. L'introspection GraphQL était désactivée côté serveur — configuration attendue pour une API en production, qui coupe la voie d'énumération standard qu'utilise n'importe quel outil type GraphQL Voyager ou InQL.
2. L'attaquant a analysé les fichiers JavaScript du tableau de bord d'administration téléchargés par le navigateur. Ces bundles contiennent les requêtes GraphQL nommées émises par l'interface — noms de queries, champs demandés, arguments.
3. À partir des requêtes observées, l'attaquant a reconstruit une portion suffisante du schéma pour identifier les queries qui, exposées en production, permettaient d'extraire les données recherchées.
4. Les requêtes en question ont ensuite été rejouées depuis un contexte non-privilégié pour vider la base.

Autrement dit : désactiver __schema ne suffit pas si le front-end admin est servi au navigateur non authentifié, ou si les requêtes sont accessibles depuis un compte utilisateur standard sans contrôle de scope. La leçon architecturale est banale mais persistante — l'introspection désactivée est un ralentisseur, pas une frontière d'autorisation.

Ce qui n'est pas confirmé

• Aucune communication publique d'EVA.gg à la date de publication de ce billet. Ni notification article 33 RGPD à la CNIL relayée publiquement, ni communiqué aux clients.
• L'authenticité complète du jeu de données n'a pas été validée par un tiers indépendant. La cohérence structurelle (nombre de comptes vs. nombre de réservations dans un rapport plausible pour une plateforme VR à sessions courtes) plaide pour une revendication crédible, sans être une preuve.
• La question de la présence ou non de mots de passe dans l'échantillon n'est pas explicitement documentée par la source. Traiter par défaut comme si des identifiants réutilisables ailleurs pouvaient figurer dans le dump.
• Le vecteur exact d'authentification utilisé pour rejouer les requêtes GraphQL — compte utilisateur légitime créé par l'attaquant, token exposé, ou faille d'autorisation par-dessus l'API — reste non détaillé.

Que faire

1. Utilisateurs EVA.gg — rotation de mot de passe sur le compte EVA et sur tout autre service où le même mot de passe aurait été réutilisé. Le vecteur exploité n'implique pas de facto un dump de credentials, mais l'exposition d'une base utilisateur complète justifie la prudence tant qu'EVA n'a pas publié le périmètre exact des champs extraits.
2. Considérer que l'historique de réservations peut être public. Horaires, arènes, joueurs associés — c'est le matériel d'un email de phishing « votre session du [date exacte] à [arène exacte] avec [nom exact] » particulièrement crédible. Ne pas cliquer sur des liens venant d'un email évoquant votre historique EVA sans vérifier via l'application.
3. Équipes API GraphQL — auditer aujourd'hui : introspection désactivée en production, mais surtout requêtes nommées non-atteignables sans le scope d'autorisation attendu, quel que soit le contenu du bundle JS admin. Le test minimal : ouvrir les DevTools sur le back-office authentifié, extraire une requête GraphQL sensible, la rejouer depuis un client anonyme ou depuis un compte utilisateur standard, vérifier qu'elle est refusée au niveau du resolver et non seulement au niveau du front.
4. Séparation front admin / front public : servir le bundle JS de l'interface d'administration uniquement derrière une authentification amont (ou via un domaine séparé avec ACL réseau), plutôt que de compter sur l'invisibilité de code JavaScript minifié. La minification n'est pas une protection.
5. Logging côté GraphQL : compter les requêtes par type et par utilisateur, alerter sur les exécutions massives des queries « admin-shaped » depuis des sessions non-admin. C'est le signal qui aurait probablement rendu l'exfiltration détectable pendant qu'elle se produisait.

Contexte

La revendication EVA.gg s'inscrit dans la vague de sept incidents revendiqués en 48 heures entre le 14 et le 16 juillet 2026 sur le compte FrenchBreaches, exposant selon info.fr plus de 200 000 personnes en France. Sur la même fenêtre ont également été revendiqués :

• Accor — 162 437 lignes clients (voir Accor : 162 437 lignes clients revendiquées, accès VPN interne signalé).
• Croq'Vacances — 72 916 dossiers de séjours enfants (voir Croq'Vacances — 72 916 dossiers de séjours enfants).
• SFR NOVA — 2,1 millions de lignes clients fibre (voir SFR : 2,1 millions de clients fibre revendiqués via l'outil NOVA).
• Fédération des Centres Sociaux et Socioculturels de France, groupe Actiale, Kosc Telecom, DoinSport, France Pare-Brise.

Sur cette série, EVA.gg est le cas le plus intéressant sur le plan technique — pas parce que le volume est le plus élevé (il ne l'est pas), mais parce que le vecteur revendiqué met en lumière un anti-pattern GraphQL courant : compter sur introspection: false pour équivaloir à « API scellée ». Le bundle admin livré au navigateur reste l'endroit où le schéma est trivial à reconstruire, requête par requête. Le contrôle d'autorisation doit vivre côté resolver, pas côté rendu.

L'incident reste à ce stade une revendication non confirmée par l'exploitant. Nous mettrons à jour ce billet si EVA.gg ou la CNIL publient une position officielle.