KeepCool : 287 842 fiches adhérents revendiquées via identifiants en dur et BOLA

Le 11 juillet 2026, un acteur publie sur un forum cybercriminel un extrait attribué à KeepCool, la chaîne française de salles de sport, contenant 287 842 fiches d'adhérents. L'export revendiqué date de février 2026. La revendication, recensée par Cyberattaque.org et reprise par SoCRadar, n'a fait l'objet d'aucun communiqué public de KeepCool à la date de ce billet.

Périmètre revendiqué

Les échantillons publiés en libre accès par l'auteur, au format JSON, contiennent par fiche :

• Identité : nom, prénom.
• Coordonnées : adresse, courriel, téléphone.
• Compte : détails d'abonnement, club KeepCool fréquenté, date du dernier passage en salle.

D'après Cyberattaque.org, aucun mot de passe ni donnée bancaire ne figure dans les éléments diffusés. L'échantillon regroupe adhérents actifs et anciens adhérents — le second groupe indique la présence de données historiques dans l'export.

Vecteur revendiqué

L'auteur détaille publiquement la chaîne d'exploitation, dans l'ordre :

1. Découverte d'identifiants administrateur codés en dur dans une application KeepCool distribuée aux clients ou aux clubs.
2. Obtention d'un jeton JWT valide via ces identifiants, permettant l'accès à l'API back-office.
3. Exploitation d'une vulnérabilité BOLA (Broken Object Level Authorization) sur l'API : l'endpoint retourne la fiche d'un adhérent sans vérifier que le porteur du jeton est autorisé à consulter cet identifiant précis. L'attaquant énumère les identifiants pour extraire l'ensemble des fiches.

BOLA est le premier item de la OWASP API Security Top 10 et reste la classe de faille la plus fréquente sur les API RESTful d'entreprises. La combinaison secret en dur → jeton → itération d'IDs est le schéma canonique.

À ce stade, il s'agit d'une revendication non confirmée officiellement. L'auteur affirme avoir alerté KeepCool avant publication et accuse l'enseigne de n'avoir ni répondu ni déclaré l'incident.

Statut de l'exploitation

L'export est diffusé — pas seulement mis en vente. L'échantillon public suffit à une vérification externe de cohérence interne (correspondance nom / adresse / club) mais aucune contre-vérification indépendante de l'ensemble du jeu de données n'a été produite par KeepCool ni par une autorité française à ce jour. Pas de mention de la CNIL ni de dépôt de plainte connu à cette heure.

Que faire

Pour les adhérents (actuels ou passés) :

1. Surveiller les tentatives de phishing ciblant votre courriel et votre téléphone, en particulier des messages usurpant l'identité de KeepCool (renouvellement d'abonnement, remboursement, demande de moyen de paiement). Le jeu de données contient assez d'information contextuelle — club fréquenté, date du dernier passage — pour produire des leurres crédibles.
2. Si le mot de passe KeepCool a été réutilisé ailleurs, le changer immédiatement sur les autres services. Aucun mot de passe n'apparaît dans la fuite revendiquée, mais un adhérent qui utilisait le même sur d'autres sites reste exposé aux attaques par credential stuffing indépendantes de cet incident.
3. Exercer les droits RGPD auprès de KeepCool si l'enseigne se prononce : accès (article 15) pour connaître les données détenues, effacement (article 17) pour les anciens adhérents. Un signalement à la CNIL reste ouvert si la réponse de l'enseigne est insuffisante.

Pour les responsables d'API dans les DSI françaises :

1. Auditer les applications mobiles et clients lourds distribués aux utilisateurs finaux à la recherche de secrets embarqués. Les identifiants « admin » codés en dur dans une build Android ou iOS téléchargée par tout adhérent ne sont pas un secret — ils sont un poids mort qui sera extrait tôt ou tard.
2. Tester chaque endpoint API pour l'autorisation objet-par-objet. Un jeton valide ne doit pas autoriser à lire un objet dont l'ID n'est pas rattaché au principal du jeton. La règle est indépendante de la présence ou non d'un « rôle admin » dans le jeton — un admin d'espace X ne doit pas lire l'espace Y.
3. Journaliser les motifs d'énumération — un client unique qui parcourt une plage d'IDs séquentielle sur un endpoint /members/{id} est l'exact signal qu'aurait produit cette attaque. Sans plafond de débit ni détection d'énumération, le passage est silencieux.

Contexte

La séquence enseigne fitness → base d'adhérents → fuite via faille applicative répète, à un mois d'écart, celle observée en juin sur Iron Bodyfit, où 382 544 fiches clients ont été revendiquées par l'acteur « Shabat ». Elle s'inscrit aussi dans le motif plus large des fuites françaises exploitant des défauts d'autorisation d'API — la même classe de faille qui a été mise en cause dans la fuite SSTRN de 355 000 dossiers de médecine du travail via IDOR. Le patron commun : côté client mobile ou API RESTful, un contrôle d'accès manquant sur l'objet, pas sur le rôle.