Une fuite de clés API Stripe met en danger les données de 688 363 clients

La publication du 18 août 2026 doit être interprétée comme une exposition d’identifiants marchands, plutôt que comme une violation confirmée de la plateforme Stripe. Selon les informations disponibles, une archive gratuite d’environ 35 Go regroupait 17 654 fichiers provenant de 659 comptes marchands et des données associées à environ 688 363 clients répartis dans 42 pays. Ces chiffres sont des estimations rapportées, et certaines affirmations plus larges de l’acteur n’ont pas été vérifiées indépendamment.

Ce que l’archive aurait contenu

Les données concerneraient des périodes comprises entre janvier 2022 et juin 2026. Les types d’informations cités dans les analyses comprennent notamment :

• les objets clients Stripe et leurs coordonnées ;
• les paiements, intentions de paiement, sessions Checkout, factures, remboursements et litiges ;
• les versements et les transactions de solde ;
• les abonnements, produits et tarifs ;
• des métadonnées de paiement, comme la marque de la carte, ses quatre derniers chiffres, sa date d’expiration, son type de financement, son pays d’émission et son empreinte de paiement.

Les informations publiées ne semblent pas contenir de numéros de carte complets. Cela limite certaines formes de fraude directe à la carte, mais ne supprime pas le risque lié à l’exposition de clés API et de données détaillées sur les clients et les transactions.

Les chercheurs ont indiqué avoir trouvé 650 clés secrètes actives au format sk_live et neuf clés restreintes. Parmi les comptes concernés, 573 pouvaient accepter des paiements, 531 effectuer des versements et 519 disposer des deux capacités, selon l’analyse citée dans les différents rapports.

Pourquoi une seule clé active pouvait suffire

Une clé secrète Stripe est un identifiant d’authentification pour l’API, et non un simple numéro de référence. Sa portée dépend de ses permissions et de la configuration du compte marchand. Lorsqu’elle est compromise, elle peut néanmoins donner accès à des ressources marchandes et permettre des opérations de paiement non autorisées.

Les tests décrits dans les rapports montrent qu’une clé active pouvait être utilisée pour consulter des listes de clients, créer de faux liens de paiement et effectuer des paiements de test. Parmi les conséquences possibles figuraient l’énumération de données clients, l’abus des fonctions de paiement, les remboursements frauduleux, l’hameçonnage ciblé et l’ingénierie sociale liée aux paiements. Les comptes autorisés à effectuer des versements devaient en outre vérifier leurs paramètres et leurs coordonnées de destination.

Le risque principal tient à la rapidité d’exploitation : un secret serveur exposé peut transformer une erreur de gestion des identifiants en enquête pour fraude avant même que le marchand ne remarque une activité inhabituelle.

Pourquoi il ne s’agirait pas d’une fuite de l’infrastructure Stripe

Les éléments disponibles indiquent que les attaquants auraient utilisé des identifiants marchands valides pour récupérer des données via l’API légitime de Stripe. En examinant les fichiers publiés hors ligne, les chercheurs ont relevé des objets et une organisation de répertoires compatibles avec des exports provenant de points d’accès API. Ils précisent toutefois ne pas avoir utilisé les clés exposées ni accédé aux environnements actifs des marchands dans le cadre de cette analyse.

Cette distinction est importante : la défaillance se situerait plus probablement dans les environnements où les marchands stockent ou exposent leurs secrets que dans les systèmes centraux de Stripe. Les voies d’exposition plausibles comprennent :

• une infection par un voleur d’informations sur l’ordinateur d’un développeur ou d’un administrateur ;
• des dépôts publics et l’historique Git ;
• des fichiers .env ou des configurations serveur accessibles publiquement ;
• des espaces de stockage cloud, sauvegardes et couches de conteneurs ;
• des systèmes d’intégration et de déploiement continus (CI/CD), notamment les journaux GitHub Actions ;
• des serveurs mal configurés ou des scans automatisés recherchant des variables exposées.

Le chemin initial ayant permis de dérober les identifiants de 659 marchands n’a pas été établi. Ces pistes sont donc des scénarios plausibles, et non l’origine confirmée de l’ensemble des données.

Une publication liée, mais des chiffres à ne pas additionner

Hudson Rock a attribué à ce même acteur une publication associée sur un forum. Celle-ci aurait concerné 669 dossiers de fournisseurs et 1 033 clés API compromises, pour une taille annoncée de 33 Go ; le téléchargement lié aurait été plus petit. L’acteur a également affirmé détenir environ 20 000 clés API Stripe supplémentaires et laissé entendre que d’autres lots pourraient être publiés.

Ces chiffres ne doivent pas être fusionnés pour former un total vérifié. Les écarts entre 659 comptes marchands, 669 dossiers de fournisseurs et 1 033 clés peuvent s’expliquer par des jeux de données différents, plusieurs clés pour un même compte, des doublons ou des méthodes de comptage distinctes. Le chiffre de 20 000 clés reste une affirmation non vérifiée de l’acteur.

Les pays les plus représentés

Selon les informations disponibles, les principaux pays concernés étaient :

• États-Unis : 212 marchands ;
• Royaume-Uni : 81 ;
• France : 57 ;
• Canada : 38 ;
• Brésil : 30 ;
• Australie : 27.

Cette répartition décrit les marchands recensés dans les données publiées. Elle doit être lue avec prudence, car l’étendue exacte de l’exposition était encore en cours d’évaluation.

Les mesures à prendre immédiatement

1. Révoquer et remplacer les clés secrètes actives

Révoquez puis remplacez toute clé secrète active susceptible d’être apparue dans du code, des journaux, des sauvegardes, la télémétrie des terminaux, des images de conteneurs ou une infrastructure publique. Il ne faut pas attendre de constater une fraude pour remplacer un identifiant potentiellement exposé.

2. Examiner l’activité API et les opérations de paiement

Analysez les journaux API et de sécurité à la recherche d’appels inhabituels, de nouveaux liens de paiement, de paiements de test ou non autorisés, de remboursements inattendus, de modifications de permissions et d’adresses IP suspectes. Conservez les journaux pertinents afin de reconstituer la chronologie des événements.

3. Vérifier les paramètres de versement

Contrôlez les paramètres de versement, les coordonnées des comptes bancaires associés et les destinations de paiement. Toute modification suspecte doit être signalée rapidement à Stripe et aux établissements financiers concernés, conformément aux procédures applicables de réponse à incident et de signalement.

4. Remplacer les identifiants trop permissifs

Utilisez des clés restreintes, limitées au plus petit ensemble d’opérations API nécessaires à chaque service. Séparez les environnements de production et de développement ainsi que les rôles opérationnels, au lieu de distribuer un même secret largement autorisé à plusieurs applications.

5. Rechercher les secrets dans tous les environnements

Inspectez les dépôts actuels et historiques, l’historique Git, les sorties CI/CD, les journaux GitHub Actions, les fichiers .env, les couches de conteneurs, le stockage cloud, la documentation et les sauvegardes à la recherche de valeurs sk_live. Toute clé découverte doit être révoquée et remplacée, même si elle n’apparaît plus dans la version actuelle du code.

6. Ne pas considérer l’analyse GitHub comme une protection suffisante

GitHub indique que l’analyse des secrets s’exécute automatiquement sur les dépôts publics, tandis que les dépôts privés et internes appartenant à une organisation nécessitent GitHub Secret Protection, sur les offres éligibles. Cette analyse ne peut pas non plus récupérer des secrets déjà copiés dans des journaux, des sauvegardes, la télémétrie des terminaux ou des archives téléchargées.

Elle doit donc compléter, et non remplacer, une gestion centralisée des secrets, des durées de vie courtes pour les identifiants, des contrôles d’accès stricts et une surveillance continue.

La leçon pour les marchands

L’enseignement le plus clair de cette affaire est que la sécurité d’une plateforme de paiement dépend aussi de la gestion des identifiants par ses marchands. Les informations disponibles n’établissent pas une compromission de l’infrastructure Stripe, mais elles montrent qu’une clé API active exposée peut ouvrir rapidement la voie à l’accès aux données clients et à la fraude au paiement.

Les secrets de production doivent être traités comme des identifiants à fort impact : ils ne doivent figurer ni dans le code ni dans les journaux, leurs permissions doivent être limitées, ils doivent être renouvelés rapidement et chaque événement inhabituel lié à l’API ou aux versements doit faire l’objet d’une investigation.