Des clés marchands Stripe exposées, avec un risque pour 688 363 fiches clients

Les enregistrements dateraient de janvier 2022 à juin 2026.

Le risque ne se limitait pas à la divulgation de données. Selon les chercheurs, 519 des 659 comptes pouvaient à la fois accepter des paiements et effectuer des versements. Des identifiants toujours valides auraient donc pu servir à lancer des opérations frauduleuses ou à tenter de détourner des fonds.

Les États-Unis concentraient le plus grand nombre de marchands concernés, avec 212 comptes, devant le Royaume-Uni avec 81 comptes et la France avec 57.

Qui a publié les données ?

La publication est attribuée à l’acteur « Satanic », qui aurait mis les données en ligne sur pwnforums le 18 août. Le contenu aurait été proposé en téléchargement, plutôt que vendu.

Les chiffres diffèrent toutefois selon les analyses. Hudson Rock a décrit une publication initiale comprenant 669 dossiers de fournisseurs, 1 033 clés d’API compromises et une archive annoncée à 33 Go.

Ces écarts peuvent s’expliquer par plusieurs étapes de diffusion, des méthodes de comptage différentes ou des critères de validation distincts. Ils ne doivent pas être additionnés pour former un total unique et définitif. De même, l’affirmation selon laquelle l’acteur disposerait d’environ 20 000 clés d’API Stripe supplémentaires n’a pas été vérifiée indépendamment.

Hudson Rock a également relevé une différence entre les chiffres affichés sur le forum et le fichier disponible : l’annonce mentionnait 33 Go, tandis que l’archive téléchargeable ne pesait qu’environ 2,37 Go. Cette discordance est compatible avec l’hypothèse d’un volume de données plus important, sans toutefois la démontrer.

Pourquoi il ne s’agirait pas d’une intrusion dans Stripe

Les informations disponibles indiquent que les attaquants auraient utilisé des clés secrètes de marchands volées pour envoyer des requêtes ordinaires à l’API Stripe. Les données auraient ainsi été récupérées à l’aide d’identifiants autorisés à accéder à des comptes individuels, et non grâce à une faille de l’infrastructure centrale de Stripe. Les chercheurs n’ont signalé aucun élément prouvant que les systèmes centraux de Stripe avaient été compromis.

Plusieurs voies d’exposition sont possibles :

• journaux de logiciels voleurs d’informations (« infostealers ») ;
• commits dans des dépôts de code publics ;
• fichiers .env accessibles publiquement ;
• sauvegardes mal protégées ;
• journaux de chaînes CI/CD, c’est-à-dire les systèmes d’intégration et de déploiement continus ;
• serveurs web mal configurés ;
• balayage automatisé à la recherche de variables d’environnement et d’autres secrets mal protégés.

Au moment des signalements, les chercheurs n’avaient pas établi de lien entre une infection par infostealer et les domaines des marchands figurant précisément dans les données. L’origine initiale des identifiants reste donc incertaine.

La distinction est importante pour la réponse à incident. Une compromission de l’infrastructure de Stripe aurait constitué un événement de sécurité touchant la plateforme elle-même. Ici, les éléments disponibles pointent plutôt vers la fuite de nombreux secrets distincts, ensuite utilisés pour accéder aux comptes qu’ils protégeaient.

Ce qu’une seule clé active pouvait permettre

Les chercheurs ont indiqué qu’une seule clé active avait suffi pour consulter la liste de clients d’un marchand, créer un Payment Link frauduleux — un lien de paiement hébergé par Stripe — et effectuer une transaction test en moins de 17 heures.

Cette démonstration montre pourquoi une clé secrète active et dotée de privilèges étendus doit être considérée comme un incident de sécurité immédiat. Un attaquant n’a pas nécessairement besoin de pénétrer dans Stripe si la clé lui permet déjà d’accéder aux données clients et aux fonctions de paiement.

Les conséquences potentielles dépassent donc la simple fuite d’informations. Selon les autorisations de la clé et la configuration du compte, un accès non autorisé pouvait exposer des historiques de paiement ou permettre de créer des liens de paiement, de lancer des transactions, d’effectuer des remboursements ou d’intervenir sur des versements. Les données publiées comprenaient plusieurs de ces catégories, mais les informations disponibles ne permettent pas d’affirmer que chaque compte listé a subi une fraude effective.

Les limites de la détection des secrets

L’incident rappelle qu’une analyse des seuls dépôts publics ne suffit pas à protéger des identifiants de paiement. Les chercheurs ont identifié d’autres points d’exposition possibles : journaux GitHub Actions, anciens artefacts de compilation, fichiers .env publics, sauvegardes et serveurs mal configurés. Ces emplacements peuvent échapper à une analyse classique des dépôts.

GitHub Actions désigne les fonctions d’automatisation de GitHub, souvent utilisées pour construire, tester et déployer du code. Une clé peut rester visible dans les journaux générés par ces tâches, même après sa suppression du dépôt actuel.

Une autre analyse a fait état de plus de 50 000 secrets Stripe repérés dans du code public, des journaux GitHub Actions et des serveurs mal configurés. Ce chiffre illustre le problème général de détection ; il ne signifie pas que toutes ces clés faisaient partie de l’archive publiée le 18 août.

Pour les entreprises, la leçon est concrète : supprimer un secret du dépôt courant ne le rend pas automatiquement sûr. Des copies peuvent subsister dans l’historique Git, les journaux de compilation, les artefacts, les sauvegardes ou les systèmes déployés. Toute clé potentiellement exposée doit être révoquée ou remplacée, tandis que les systèmes environnants doivent faire l’objet d’une vérification.

Les mesures à prendre immédiatement

Les marchands qui pourraient avoir exposé des identifiants doivent commencer par contenir l’incident :

1. Révoquer ou renouveler immédiatement les clés secrètes actives potentiellement exposées. Supprimer un fichier ou une entrée de dépôt ne désactive pas la clé.
2. Examiner l’activité de l’API et du compte Stripe afin de repérer des adresses IP inhabituelles, des consultations de listes clients, des exportations de données, la création de Payment Links, des tentatives de paiement, des remboursements ou des versements suspects.
3. Vérifier les coordonnées bancaires utilisées pour les versements ainsi que les changements récents. Renforcer temporairement la surveillance ou les contrôles des transferts si nécessaire.
4. Remplacer les clés générales par des clés restreintes, limitées aux opérations réellement nécessaires à chaque application.
5. Centraliser les secrets dans un gestionnaire dédié et les retirer du code source, des fichiers d’environnement, des journaux et des sauvegardes non sécurisées.
6. Rechercher les secrets dans les anciens dépôts, les journaux CI/CD, les artefacts, les serveurs et les sauvegardes, et pas uniquement dans le code public actuel.

À ce stade, les éléments disponibles étayent l’hypothèse d’une exposition grave d’identifiants marchands, avec un risque important pour des données clients et des opérations de paiement. Ils ne permettent pas d’affirmer que l’infrastructure centrale de Stripe a été piratée. Les écarts entre les chiffres — notamment 659 ou 669 marchands, et 650 ou 1 033 clés — doivent également être lus comme des estimations propres à différents jeux de données, et non comme un inventaire définitif.