Gelekte Stripe-sleutels brachten gegevens van 688.363 klanten in gevaar

De blootstelling die op 18 augustus 2026 aan het licht kwam, lijkt vooral een grootschalig lek van merchant-gegevens te zijn geweest — niet een bevestigde hack van Stripe zelf. Een aanvaller die opereerde onder het alias ‘Satanic’ zou het materiaal hebben gepubliceerd op het illegale forum pwnforums. Daarin stonden naar verluidt actieve geheime API-sleutels en gegevens die uit afzonderlijke merchant-accounts waren opgehaald.

Hoe groot was de blootstelling?

De meest gedetailleerde analyse spreekt over een dataset die verband hield met 659 merchant-accounts, 650 actieve sk_live-sleutels en naar schatting 688.363 klantrecords uit 42 landen. Het archief zou ongeveer 35 GB groot zijn geweest en uit 17.654 bestanden hebben bestaan.

Volgens de berichtgeving bevatte het materiaal onder meer klantgegevens en informatie over:

• betalingen en charges;
• Payment Intents;
• facturen;
• uitbetalingen;
• terugbetalingen;
• balans- en transactieregistraties.

De gegevens zouden betrekking hebben op de periode van januari 2022 tot en met juni 2026.

Het risico was niet beperkt tot datalekken. Van 519 van de 659 accounts zou de sleutel zowel het ontvangen van betalingen als het uitvoeren van uitbetalingen mogelijk hebben gemaakt. Als zulke sleutels nog actief waren, konden ze mogelijk worden misbruikt voor frauduleuze betalingen of pogingen om geldstromen om te leiden.

De meeste getroffen merchants zouden zich in de Verenigde Staten bevinden, met 212 accounts. Daarna volgen het Verenigd Koninkrijk met 81 accounts en Frankrijk met 57.

Wie publiceerde de gegevens?

Het materiaal werd toegeschreven aan de dreigingsactor ‘Satanic’, die het op 18 augustus op pwnforums zou hebben geplaatst. Volgens verschillende meldingen was de dataset gratis te downloaden en werd die niet te koop aangeboden.

De cijfers van de eerste publicatie komen echter niet volledig overeen met latere analyses. Hudson Rock beschreef een gerelateerde dataset met 669 leveranciersmappen, 1.033 gecompromitteerde API-sleutels en een geclaimde omvang van 33 GB.

Dat verschil kan samenhangen met verschillende fasen van de publicatie, telmethodes of validatiecriteria. De aantallen mogen daarom niet zonder meer bij elkaar worden opgeteld of als één definitief totaal worden beschouwd. Ook de bewering dat de aanvaller nog ongeveer 20.000 extra Stripe-API-sleutels bezit, is niet onafhankelijk bevestigd.

Hudson Rock merkte bovendien op dat het forum 33 GB vermeldde, terwijl het downloadbare archief ongeveer 2,37 GB groot was. Dat verschil past bij — maar bewijst niet — de claim dat er meer materiaal buiten de eerste download beschikbaar was.

Waarom dit waarschijnlijk geen hack van Stripe was

De beschikbare informatie wijst erop dat aanvallers gestolen geheime merchant-sleutels hebben gebruikt om reguliere verzoeken aan de Stripe-API te doen. In dat scenario werd de data benaderd met inloggegevens die toegang hadden tot afzonderlijke merchant-accounts, en niet via een kwetsbaarheid in de centrale systemen van Stripe. Onderzoekers meldden geen bewijs dat de kerninfrastructuur van Stripe zelf was overgenomen.

Mogelijke bronnen van de gelekte sleutels zijn onder meer:

• logs van infostealers;
• commits in openbare codeopslagplaatsen;
• blootgestelde .env-bestanden;
• onveilige back-ups;
• logs van CI/CD-processen;
• verkeerd geconfigureerde webservers;
• geautomatiseerde scans naar omgevingsvariabelen en andere slecht beschermde geheimen.

Onderzoekers hadden op het moment van de berichtgeving geen infostealer-infectie kunnen koppelen aan de specifieke merchant-domeinen in de dataset. De oorspronkelijke bron van de inloggegevens bleef daardoor onduidelijk.

Dat onderscheid is belangrijk voor de aanpak van een incident. Een hack van Stripe’s infrastructuur zou wijzen op een platformbreed beveiligingsincident. Een lek van merchant-sleutels wijst daarentegen op een verzameling afzonderlijke geheimen die zijn buitgemaakt en vervolgens zijn gebruikt tegen de accounts waartoe ze toegang gaven.

Wat kon één actieve sleutel mogelijk maken?

Onderzoekers meldden dat één actieve sleutel voldoende was om binnen 17 uur toegang te krijgen tot de klantenlijst van een merchant, een frauduleuze Payment Link aan te maken en een testbetaling uit te voeren.

Die demonstratie laat zien waarom een actieve, ruim geprivilegieerde geheime sleutel direct als een ernstig beveiligingsincident moet worden behandeld. Een aanvaller hoeft Stripe niet noodzakelijk zelf binnen te dringen wanneer de sleutel al toegang geeft tot klantgegevens en betaalfuncties.

De mogelijke gevolgen gaan daarmee verder dan alleen het uitlekken van gegevens. Afhankelijk van de rechten van de sleutel en de accountconfiguratie kunnen aanvallers mogelijk betaalinformatie inzien of acties uitvoeren rond Payment Links, charges, terugbetalingen en uitbetalingen. De dataset bevatte verschillende van deze transactiecategorieën, maar de beschikbare berichtgeving bewijst niet dat elk genoemd account daadwerkelijk frauduleus is gebruikt.

Waarom alleen GitHub scannen niet genoeg is

De zaak onderstreept een bekend probleem bij het beschermen van betaalgegevens: alleen openbare repositories scannen is onvoldoende. Onderzoekers wezen op mogelijke lekpunten in GitHub Actions-logs, historische artefacten, openbare .env-bestanden, back-ups en verkeerd geconfigureerde servers — locaties die niet altijd onder een standaard repositoryscan vallen.

Afzonderlijke berichtgeving meldde dat onderzoekers meer dan 50.000 Stripe-secrets hadden gevonden in openbare code, GitHub Actions-logs en verkeerd geconfigureerde servers. Dat cijfer beschrijft de bredere omvang van het ontdekkingsprobleem en betekent niet automatisch dat al deze sleutels onderdeel waren van de dataset van 18 augustus.

Een geheim verwijderen uit de huidige versie van een repository maakt het dus niet vanzelf veilig. Kopieën kunnen achterblijven in de commitgeschiedenis, buildlogs, artefacten, back-ups of uitgerolde systemen. Een mogelijk blootgestelde sleutel moet worden ingetrokken of vervangen; ook de systemen eromheen moeten worden onderzocht.

Wat Stripe-merchants nu moeten doen

Bedrijven die mogelijk blootgestelde gegevens hebben, moeten eerst de toegang tot hun accounts beperken:

1. Trek mogelijk blootgestelde live-sleutels onmiddellijk in of vervang ze. Alleen een bestand of repository-item verwijderen maakt de sleutel niet ongeldig.
2. Controleer Stripe- en API-activiteit op onbekende IP-adressen, toegang tot klantenlijsten, data-exporten, aangemaakte Payment Links, betaalpogingen, terugbetalingen en uitbetalingen.
3. Controleer bankrekeninggegevens voor uitbetalingen en recente wijzigingen. Verhoog waar nodig tijdelijk de monitoring of voeg extra controles toe voor geldtransfers.
4. Vervang brede geheime sleutels door restricted keys die alleen de API-handelingen toestaan die een applicatie daadwerkelijk nodig heeft.
5. Sla geheimen op in een beheerde secretskluis en verwijder ze uit broncode, omgevingsbestanden, logs en onbeveiligde back-ups.
6. Doorzoek ook historische repositories, CI/CD-logs, artefacten, servers en back-ups, en niet alleen de meest recente openbare code.

De huidige aanwijzingen ondersteunen het beeld van een ernstig lek van merchant-inloggegevens, met aanzienlijk risico voor klant- en betaalinformatie. Ze rechtvaardigen niet de conclusie dat de centrale infrastructuur van Stripe is gehackt. Door de tegenstrijdige tellingen moeten de genoemde aantallen bovendien worden gelezen als schattingen die bij specifieke datasets horen, niet als één definitieve inventarisatie.