Contexte de la fuite

PingCAP commercialise TiDB Cloud, version managée de la base de données open‑source TiDB. Le service repose sur une architecture multi‑locataire où chaque client possède un cluster isolé, mais toutes les instances partagent le même plan de contrôle (control‑plane). Le groupe de recherche FulcrumSec a rendu public l’accès complet à ce plan de contrôle, aux facturations GCP et AWS, aux tickets Jira, aux CRM et aux logs de connexion de chaque client depuis le lancement du service. Au total, plus de 10,6 TB de données ont été exfiltrés, dont 200 GB publiés dans la première vague de divulgation.

Mécanismes de la faille d’isolation

Un ticket interne (SECURITY‑22, daté du 2022‑08) décrit la faiblesse principale : « Le mot de passe root du cluster peut être réinitialisé sans condition ». Tous les rôles d’une organisation – propriétaire, audit admin, billing admin, voire simple membre – pouvaient déclencher la réinitialisation du mot de passe root de chaque cluster de l’organisation. Le compte root possède des privilèges système, ce qui permet à un acteur malveillant de prendre le contrôle complet du cluster, de modifier son état et d’accéder aux données stockées. Cette capacité était documentée quatre ans avant l’incident, mais aucune mesure d’atténuation n’a été déployée.

En pratique, les attaquants ont exploité les clés de service GCP et le principal Azure présents dans les dépôts internes pour créer un flux de réplication du contrôle‑plane. Toutes les six heures, pendant vingt‑deux jours (du 8 au 30 septembre 2026), le pipeline a exporté chaque table du cœur opérationnel – locataires, utilisateurs, clés API, identifiants de clusters – vers un bucket contrôlé par les chercheurs. Au total, 88 exportations consécutives ont été réalisées sans déclencher d’alerte.

Chronologie de l’exfiltration

La campagne a débuté avec un premier vol d’environ 8 TB d’informations, suivi d’extractions régulières jusqu’à atteindre le volume final de 10,6 TB. Les logs montrent que les attaquants ont également récupéré des identifiants sensibles directement depuis les tickets Jira, dont des clés d’accès AWS (exemple ci‑dessous) et des chaînes de connexion MySQL contenant nom d’utilisateur et mot de passe.

AWS_ACCESS_KEY_ID=AKIAYM5Y2YXDRDJD2IOM
AWS_SECRET_ACCESS_KEY=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

Des centaines de comptes clients – Mercari, SoftBank, Square Enix, Airbnb, Pinterest, etc. – ont vu leurs VPC CIDR, versions de clusters et hôtes d’endpoint exposés, ainsi que leurs propres clés de production. Un ticket de support (APID‑12036) contenait plus de 8 000 valeurs d’identifiants, incluant des tokens GitHub, des clés d’API IA (OpenAI, Anthropic, Gemini) et même une paire de clés root AWS.

Conséquences et leçons

La fuite démontre que la simple présence d’outils EDR ne suffit pas à protéger un fournisseur de services cloud lorsqu’il ne surveille pas ses propres ressources de stockage (S3, GCS). L’absence de journalisation d’accès anormaux aux buckets a permis aux attaquants de maintenir le flux de données pendant plus de trois semaines. De plus, la pratique de coller des identifiants de production dans des tickets Jira constitue une violation flagrante des meilleures pratiques de gestion des secrets.

Sur le plan technique, la capacité à réinitialiser le mot de passe root depuis n’importe quel rôle brise le principe de moindre privilège et rend la séparation logique entre locataires inefficace. Une isolation robuste aurait nécessité un mécanisme de contrôle d’accès basé sur des politiques RBAC strictes, ainsi que la rotation automatisée des secrets root. Enfin, la divulgation de logs financiers et d’ARR montre que la compromission s’étend au-delà du plan de données, affectant la chaîne de valeur commerciale de PingCAP.