Stripe-nøgler lækket: 688.363 kundeposter kan være i fare

Det, der blev offentliggjort 18. august 2026, ligner en omfattende kompromittering af Stripe-forhandleres legitimationsoplysninger – ikke et bekræftet brud på Stripes egen infrastruktur. En aktør under navnet “Satanic” lagde ifølge rapporterne materialet på det illegale forum pwnforums. Det indeholdt aktive hemmelige API-nøgler og data hentet fra individuelle forhandlerkonti.

Omfanget af den rapporterede eksponering

Den mest detaljerede analyse beskriver en datasamling knyttet til 659 forhandlerkonti, 650 aktive sk_live-hemmelige nøgler og anslået 688.363 kundeposter fra 42 lande. Arkivet skulle fylde cirka 35 GB fordelt på 17.654 filer.

Materialet indeholdt angiveligt kundeoplysninger samt data om:

• Betalinger
• Payment Intents
• Fakturaer
• Udbetalinger
• Refunderinger
• Saldo- og kontotransaktioner

Posterene dækkede perioden fra januar 2022 til juni 2026.

Risikoen handlede ikke kun om datalæk. 519 af de 659 konti kunne ifølge rapporterne både modtage betalinger og foretage udbetalinger. Hvis nøglerne stadig var aktive, kunne kombinationen potentielt bruges til svigagtige betalinger eller forsøg på at omdirigere penge.

USA havde det største rapporterede antal berørte forhandlere med 212 konti, efterfulgt af Storbritannien med 81 og Frankrig med 57.

Hvem offentliggjorde materialet?

Datasamlingen blev tilskrevet trusselsaktøren “Satanic”, som ifølge rapporterne offentliggjorde den på pwnforums den 18. august. Materialet skulle kunne downloades gratis frem for at blive solgt.

Tallene fra den første offentliggørelse stemmer dog ikke helt overens med den senere validerede datasamling. Hudson Rock beskrev i en relateret analyse 669 leverandørmapper, 1.033 kompromitterede API-nøgler og et arkiv på angiveligt 33 GB.

Forskellene kan skyldes forskellige faser af offentliggørelsen, optællingsmetoder eller valideringskriterier. De bør derfor ikke lægges sammen til ét bekræftet totalbeløb. Påstanden om, at aktøren havde omkring 20.000 ekstra Stripe API-nøgler klar til fremtidige offentliggørelser, er ikke uafhængigt bekræftet.

Hudson Rock rapporterede også, at et forumopslag annoncerede 33 GB, mens det downloadbare arkiv kun fyldte cirka 2,37 GB. Forskellen er forenelig med – men beviser ikke – påstanden om, at mere materiale fandtes uden for den første download.

Hvorfor det ikke ligner et brud på Stripes infrastruktur

De tilgængelige oplysninger tyder på, at angribere kan have brugt stjålne hemmelige forhandlernøgler til at sende almindelige API-forespørgsler til Stripe. I så fald blev dataene hentet gennem legitimationsoplysninger med adgang til bestemte forhandlerkonti – ikke via et indbrud i Stripes centrale systemer. Forskere har ikke rapporteret beviser for, at Stripes kerneinfrastruktur blev kompromitteret.

Mulige kilder til de lækkede nøgler omfatter:

• Infostealer-logfiler
• Offentlige kodeændringer
• Eksponerede .env-filer
• Usikre sikkerhedskopier
• Logfiler fra CI/CD-systemer
• Fejlkonfigurerede webservere
• Automatiseret scanning efter miljøvariabler og andre dårligt beskyttede hemmeligheder

På rapporteringstidspunktet havde forskerne ikke knyttet en konkret infostealer-infektion til de forhandlerdomæner, der fremgik af datasamlingen. Den oprindelige kilde til legitimationsoplysningerne er derfor fortsat uklar.

Forskellen er vigtig i en sikkerhedshændelse. Et brud på Stripes infrastruktur ville være en platform-dækkende hændelse. En eksponering af forhandlernøgler peger i stedet på, at mange separate hemmeligheder er blevet lækket og derefter brugt mod de konti, som nøglerne gav adgang til.

Hvad én aktiv nøgle kunne bruges til

Forskere rapporterede, at én aktiv nøgle var nok til at få adgang til en forhandlers kundeliste, oprette et falsk Payment Link og gennemføre en testbetaling inden for 17 timer.

Demonstrationen viser, hvorfor en aktiv hemmelig nøgle med brede rettigheder skal behandles som en akut kontosikkerhedshændelse. En angriber behøver ikke nødvendigvis bryde ind i Stripe, hvis nøglen allerede giver adgang til kundeoplysninger og betalingsfunktioner.

Konsekvenserne kan derfor række ud over selve datalækket. Afhængigt af nøglens tilladelser og kontoens opsætning kan uautoriseret adgang eksponere betalingsdata eller gøre det muligt at oprette betalingslinks, gennemføre betalinger, udstede refunderinger og håndtere udbetalinger. Den rapporterede datasamling indeholdt flere af disse transaktionstyper, men de tilgængelige oplysninger dokumenterer ikke, at alle konti blev udsat for svigagtig aktivitet.

GitHub-scanning er ikke nok

Hændelsen understreger, hvorfor scanning af offentlige kodearkiver ikke alene beskytter betalingslegitimationsoplysninger. Forskerne pegede på mulige eksponeringspunkter i GitHub Actions-logfiler, historiske artefakter, offentlige .env-filer, sikkerhedskopier og fejlkonfigurerede servere – steder, som en almindelig scanning af kodearkiver måske ikke dækker.

I en separat rapportering blev der identificeret over 50.000 Stripe-hemmeligheder i offentlig kode, GitHub Actions-logfiler og fejlkonfigurerede servere. Tallet beskriver et bredere fund af potentielt eksponerede nøgler og betyder ikke nødvendigvis, at alle var en del af datasamlingen fra 18. august.

For virksomheder er læren klar: En hemmelighed bliver ikke sikker, bare fordi den fjernes fra den aktuelle version af et kodearkiv. Kopier kan stadig ligge i commit-historik, build-logfiler, artefakter, sikkerhedskopier eller installerede systemer. En mulig eksponeret nøgle skal tilbagekaldes eller udskiftes, og de omkringliggende systemer bør undersøges.

Det bør Stripe-forhandlere gøre nu

Virksomheder, der kan have fået eksponeret legitimationsoplysninger, bør prioritere at begrænse skaden:

1. Tilbagekald eller udskift straks potentielt eksponerede live-hemmelige nøgler. Det er ikke nok blot at slette en fil eller en post i et kodearkiv.
2. Gennemgå Stripe API- og kontoaktivitet for ukendte IP-adresser, adgang til kundelister, dataeksport, oprettelse af Payment Links, betalingsforsøg, refunderinger og udbetalinger.
3. Kontrollér bankkontooplysninger til udbetalinger og nylige ændringer. Skærp om nødvendigt overvågningen eller indfør midlertidige kontroller for overførsler.
4. Erstat brede hemmelige nøgler med begrænsede nøgler, der kun kan udføre de API-handlinger, applikationen faktisk har brug for.
5. Opbevar hemmeligheder i et administreret secrets-lager, og fjern dem fra kildekode, miljøfiler, logfiler og ubeskyttede sikkerhedskopier.
6. Søg i historiske kodearkiver, CI/CD-logfiler, artefakter, servere og sikkerhedskopier – ikke kun i den seneste offentlige kode.

Den nuværende dokumentation understøtter en alvorlig eksponering af forhandlerlegitimationsoplysninger med betydelig risiko for kunde- og betalingsdata. Den dokumenterer ikke, at Stripes centrale infrastruktur blev hacket. De modstridende optællinger betyder desuden, at tallene bør læses som estimater for bestemte datasamlinger – ikke som én endelig opgørelse.