Omfanget av lekkasjen

Den mest detaljerte analysen beskriver et datasett knyttet til 659 virksomhetskontoer, 650 aktive sk_live-nøkler og anslagsvis 688 363 kunderegistre fra 42 land. Arkivet skal ha vært på rundt 35 GB, fordelt på 17 654 filer.

Materialet skal blant annet ha inneholdt kundeopplysninger og informasjon om:

• belastninger
• betalingsintensjoner
• fakturaer
• utbetalinger
• refusjoner
• saldo- og kontotransaksjoner

Dataene skal ha vært datert fra januar 2022 til juni 2026.

Risikoen var ikke begrenset til innsyn i data. 519 av de 659 kontoene skal ha kunnet både ta imot betalinger og gjennomføre utbetalinger. Dersom nøklene fortsatt var aktive, kunne det i verste fall åpne for falske betalinger eller forsøk på å styre penger til andre kontoer.

Flest berørte virksomheter skal ha vært registrert i USA, med 212 kontoer, fulgt av Storbritannia med 81 og Frankrike med 57.

Hvem publiserte materialet?

Datasettet ble knyttet til trusselaktøren «Satanic», som skal ha publisert det på pwnforums 18. august. Materialet ble omtalt som tilgjengelig for nedlasting, ikke som noe som ble solgt.

Tallene fra den første publiseringen stemmer imidlertid ikke helt med det senere validerte datasettet. Hudson Rock beskrev i en relatert analyse 669 leverandørmapper, 1 033 kompromitterte API-nøkler og et arkiv på oppgitte 33 GB.

Forskjellene kan skyldes ulike publiseringsstadier, opptellingsmetoder eller kriterier for validering. Tallene bør derfor ikke behandles som én samlet, bekreftet total. Påstanden om at aktøren satt på rundt 20 000 ekstra Stripe API-nøkler for senere publiseringer, er ikke uavhengig bekreftet.

Hudson Rock rapporterte også at foruminnlegget annonserte 33 GB, mens selve arkivet som kunne lastes ned, var på omtrent 2,37 GB. Avviket er forenlig med – men beviser ikke – påstanden om at mer materiale fantes utenfor den første nedlastingen.

Hvorfor dette ikke ser ut som et innbrudd i Stripe

Tilgjengelig rapportering tyder på at angripere kan ha brukt stjålne hemmelige nøkler til å sende vanlige API-forespørsler til Stripe. I så fall ble dataene hentet gjennom legitimasjon som allerede hadde tilgang til bestemte virksomhetskontoer, snarere enn gjennom en sårbarhet i Stripes sentrale systemer. Forskere har ikke rapportert bevis for at Stripes kjerneinfrastruktur ble kompromittert.

Mulige kilder til de lekkede nøklene er blant annet:

• logger fra skadevare som stjeler informasjon
• nøkler i offentlige kodeinnsjekkinger
• eksponerte .env-filer
• usikre sikkerhetskopier
• logger fra CI/CD-systemer
• feilkonfigurerte webservere
• automatisert skanning etter miljøvariabler og andre dårlig beskyttede hemmeligheter

På rapporteringstidspunktet hadde forskerne ikke knyttet en konkret infostealer-infeksjon til domenene som var oppført i datasettet. Den opprinnelige kilden til legitimasjonen er derfor fortsatt uklar.

Skillet er viktig i håndteringen av hendelsen. Et innbrudd i Stripes infrastruktur ville ha vært en plattformomfattende sikkerhetshendelse. En lekkasje av virksomhetenes egne nøkler peker i stedet mot mange separate hemmeligheter som er kommet på avveie og senere er blitt brukt mot kontoene de ga tilgang til.

Dette kunne én aktiv nøkkel gjøre

Forskere rapporterte at én aktiv nøkkel var nok til å få tilgang til en virksomhets kundeliste, opprette en falsk betalingslenke og gjennomføre en testbetaling innen 17 timer.

Demonstrasjonen viser hvorfor en aktiv nøkkel med brede rettigheter må behandles som en akutt sikkerhetshendelse. En angriper trenger ikke nødvendigvis å bryte seg inn i Stripe når nøkkelen allerede gir tilgang til kundedata og betalingsfunksjoner.

Konsekvensene kan dermed bli mer alvorlige enn ren datalekkasje. Avhengig av nøkkelens rettigheter og kontoinnstillinger kan uvedkommende få innsyn i betalingsopplysninger eller utføre handlinger knyttet til betalingslenker, belastninger, refusjoner og utbetalinger. Datasettet skal ha inneholdt flere av disse transaksjonstypene, men rapporteringen slår ikke fast at alle kontoene faktisk ble brukt til svindel.

Hvorfor GitHub-skanning ikke er nok

Hendelsen illustrerer også hvorfor det ikke er tilstrekkelig å skanne offentlige kodearkiver etter betalingslegitimasjon. Forskere fant mulige eksponeringspunkter i GitHub Actions-logger, historiske artefakter, offentlige .env-filer, sikkerhetskopier og feilkonfigurerte servere – steder som ikke nødvendigvis fanges opp av en vanlig skanning av selve kodearkivet.

Separat rapportering sier at forskere har identifisert mer enn 50 000 Stripe-hemmeligheter i offentlig kode, GitHub Actions-logger og feilkonfigurerte servere. Dette tallet beskriver et bredere funnproblem og betyr ikke nødvendigvis at nøklene var en del av datasettet som ble publisert 18. august.

For virksomheter er lærdommen konkret: En nøkkel blir ikke trygg bare fordi den slettes fra den nyeste versjonen av et kodearkiv. Kopier kan fortsatt ligge i historikken, bygglogger, artefakter, sikkerhetskopier eller utrullede systemer. En mulig eksponert nøkkel må tilbakekalles eller roteres, og de omkringliggende systemene bør undersøkes.

Dette bør Stripe-kunder gjøre nå

Virksomheter som kan ha fått nøkler på avveie, bør prioritere å stanse misbruket:

1. Tilbakekall eller roter alle aktive hemmelige nøkler som kan være eksponert umiddelbart. Det er ikke nok å slette en fil eller et kodearkiv.
2. Gå gjennom Stripe- og API-aktivitet for ukjente IP-adresser, tilgang til kundelister, dataeksport, opprettelse av betalingslenker, betalingsforsøk, refusjoner og utbetalinger.
3. Kontroller bankopplysninger for utbetalinger og nylige endringer. Øk overvåkingen eller innfør midlertidige kontroller for overføringer ved behov.
4. Bytt ut brede hemmelige nøkler med begrensede nøkler som bare tillater operasjonene applikasjonen faktisk trenger.
5. Oppbevar hemmeligheter i en administrert secrets-løsning, og fjern dem fra kildekode, miljøfiler, logger og usikrede sikkerhetskopier.
6. Søk gjennom historiske kodearkiver, CI/CD-logger, artefakter, servere og sikkerhetskopier – ikke bare den nyeste offentlige koden.

Dokumentasjonen peker samlet mot en alvorlig eksponering av virksomhetenes Stripe-legitimasjon, med betydelig risiko for kunde- og betalingsdata. Den gir ikke grunnlag for å slå fast at Stripes sentrale infrastruktur ble hacket. De motstridende opptellingene betyr også at totalsummene bør forstås som anslag knyttet til bestemte datasett, ikke som én endelig oversikt.

Omfanget av lekkasjen

Den mest detaljerte analysen beskriver et datasett knyttet til 659 virksomhetskontoer, 650 aktive sk_live-nøkler og anslagsvis 688 363 kunderegistre fra 42 land. Arkivet skal ha vært på rundt 35 GB, fordelt på 17 654 filer.

Materialet skal blant annet ha inneholdt kundeopplysninger og informasjon om:

• belastninger
• betalingsintensjoner
• fakturaer
• utbetalinger
• refusjoner
• saldo- og kontotransaksjoner

Dataene skal ha vært datert fra januar 2022 til juni 2026.

Risikoen var ikke begrenset til innsyn i data. 519 av de 659 kontoene skal ha kunnet både ta imot betalinger og gjennomføre utbetalinger. Dersom nøklene fortsatt var aktive, kunne det i verste fall åpne for falske betalinger eller forsøk på å styre penger til andre kontoer.

Flest berørte virksomheter skal ha vært registrert i USA, med 212 kontoer, fulgt av Storbritannia med 81 og Frankrike med 57.

Hvem publiserte materialet?

Datasettet ble knyttet til trusselaktøren «Satanic», som skal ha publisert det på pwnforums 18. august. Materialet ble omtalt som tilgjengelig for nedlasting, ikke som noe som ble solgt.

Tallene fra den første publiseringen stemmer imidlertid ikke helt med det senere validerte datasettet. Hudson Rock beskrev i en relatert analyse 669 leverandørmapper, 1 033 kompromitterte API-nøkler og et arkiv på oppgitte 33 GB.

Forskjellene kan skyldes ulike publiseringsstadier, opptellingsmetoder eller kriterier for validering. Tallene bør derfor ikke behandles som én samlet, bekreftet total. Påstanden om at aktøren satt på rundt 20 000 ekstra Stripe API-nøkler for senere publiseringer, er ikke uavhengig bekreftet.

Hudson Rock rapporterte også at foruminnlegget annonserte 33 GB, mens selve arkivet som kunne lastes ned, var på omtrent 2,37 GB. Avviket er forenlig med – men beviser ikke – påstanden om at mer materiale fantes utenfor den første nedlastingen.

Hvorfor dette ikke ser ut som et innbrudd i Stripe

Tilgjengelig rapportering tyder på at angripere kan ha brukt stjålne hemmelige nøkler til å sende vanlige API-forespørsler til Stripe. I så fall ble dataene hentet gjennom legitimasjon som allerede hadde tilgang til bestemte virksomhetskontoer, snarere enn gjennom en sårbarhet i Stripes sentrale systemer. Forskere har ikke rapportert bevis for at Stripes kjerneinfrastruktur ble kompromittert.

Mulige kilder til de lekkede nøklene er blant annet:

• logger fra skadevare som stjeler informasjon
• nøkler i offentlige kodeinnsjekkinger
• eksponerte .env-filer
• usikre sikkerhetskopier
• logger fra CI/CD-systemer
• feilkonfigurerte webservere
• automatisert skanning etter miljøvariabler og andre dårlig beskyttede hemmeligheter

På rapporteringstidspunktet hadde forskerne ikke knyttet en konkret infostealer-infeksjon til domenene som var oppført i datasettet. Den opprinnelige kilden til legitimasjonen er derfor fortsatt uklar.

Skillet er viktig i håndteringen av hendelsen. Et innbrudd i Stripes infrastruktur ville ha vært en plattformomfattende sikkerhetshendelse. En lekkasje av virksomhetenes egne nøkler peker i stedet mot mange separate hemmeligheter som er kommet på avveie og senere er blitt brukt mot kontoene de ga tilgang til.

Dette kunne én aktiv nøkkel gjøre

Forskere rapporterte at én aktiv nøkkel var nok til å få tilgang til en virksomhets kundeliste, opprette en falsk betalingslenke og gjennomføre en testbetaling innen 17 timer.

Demonstrasjonen viser hvorfor en aktiv nøkkel med brede rettigheter må behandles som en akutt sikkerhetshendelse. En angriper trenger ikke nødvendigvis å bryte seg inn i Stripe når nøkkelen allerede gir tilgang til kundedata og betalingsfunksjoner.

Konsekvensene kan dermed bli mer alvorlige enn ren datalekkasje. Avhengig av nøkkelens rettigheter og kontoinnstillinger kan uvedkommende få innsyn i betalingsopplysninger eller utføre handlinger knyttet til betalingslenker, belastninger, refusjoner og utbetalinger. Datasettet skal ha inneholdt flere av disse transaksjonstypene, men rapporteringen slår ikke fast at alle kontoene faktisk ble brukt til svindel.

Hvorfor GitHub-skanning ikke er nok

Hendelsen illustrerer også hvorfor det ikke er tilstrekkelig å skanne offentlige kodearkiver etter betalingslegitimasjon. Forskere fant mulige eksponeringspunkter i GitHub Actions-logger, historiske artefakter, offentlige .env-filer, sikkerhetskopier og feilkonfigurerte servere – steder som ikke nødvendigvis fanges opp av en vanlig skanning av selve kodearkivet.

Separat rapportering sier at forskere har identifisert mer enn 50 000 Stripe-hemmeligheter i offentlig kode, GitHub Actions-logger og feilkonfigurerte servere. Dette tallet beskriver et bredere funnproblem og betyr ikke nødvendigvis at nøklene var en del av datasettet som ble publisert 18. august.

For virksomheter er lærdommen konkret: En nøkkel blir ikke trygg bare fordi den slettes fra den nyeste versjonen av et kodearkiv. Kopier kan fortsatt ligge i historikken, bygglogger, artefakter, sikkerhetskopier eller utrullede systemer. En mulig eksponert nøkkel må tilbakekalles eller roteres, og de omkringliggende systemene bør undersøkes.

Dette bør Stripe-kunder gjøre nå

Virksomheter som kan ha fått nøkler på avveie, bør prioritere å stanse misbruket:

1. Tilbakekall eller roter alle aktive hemmelige nøkler som kan være eksponert umiddelbart. Det er ikke nok å slette en fil eller et kodearkiv.
2. Gå gjennom Stripe- og API-aktivitet for ukjente IP-adresser, tilgang til kundelister, dataeksport, opprettelse av betalingslenker, betalingsforsøk, refusjoner og utbetalinger.
3. Kontroller bankopplysninger for utbetalinger og nylige endringer. Øk overvåkingen eller innfør midlertidige kontroller for overføringer ved behov.
4. Bytt ut brede hemmelige nøkler med begrensede nøkler som bare tillater operasjonene applikasjonen faktisk trenger.
5. Oppbevar hemmeligheter i en administrert secrets-løsning, og fjern dem fra kildekode, miljøfiler, logger og usikrede sikkerhetskopier.
6. Søk gjennom historiske kodearkiver, CI/CD-logger, artefakter, servere og sikkerhetskopier – ikke bare den nyeste offentlige koden.

Dokumentasjonen peker samlet mot en alvorlig eksponering av virksomhetenes Stripe-legitimasjon, med betydelig risiko for kunde- og betalingsdata. Den gir ikke grunnlag for å slå fast at Stripes sentrale infrastruktur ble hacket. De motstridende opptellingene betyr også at totalsummene bør forstås som anslag knyttet til bestemte datasett, ikke som én endelig oversikt.