Läckta Stripe-nycklar kan ha utsatt 688 363 kundposter för risk

Publiceringen den 18 augusti 2026 bör främst förstås som en exponering av handlares inloggningsuppgifter – inte som ett bekräftat dataintrång i Stripe. Rapporter beskrev ett gratisarkiv på omkring 35 GB med 17 654 filer från 659 handlarkonton och information kopplad till uppskattningsvis 688 363 kunder i 42 länder. Siffrorna är rapporterade uppskattningar, och flera bredare påståenden från hotaktören har inte verifierats oberoende.

Vad arkivet uppges ha innehållit

Materialet ska ha omfattat uppgifter från januari 2022 till juni 2026. Bland de rapporterade datatyperna fanns:

• Stripe-kundobjekt och kontaktuppgifter
• Debiteringar, betalningsintentioner och Checkout-sessioner
• Fakturor, återbetalningar och tvister
• Utbetalningar och saldotransaktioner
• Prenumerationer, produkter och priser
• Betalningsrelaterade metadata, som kortvarumärke, de fyra sista siffrorna, utgångsdatum, finansieringstyp, utfärdandeland och betalningsfingeravtryck

Rapporteringen tyder inte på att arkivet innehöll fullständiga kortnummer. Det begränsar vissa former av direkt kortbedrägeri, men undanröjer inte riskerna med exponerade API-uppgifter och detaljerad kund- och transaktionsdata.

Forskare uppgav att de hittade 650 aktiva hemliga sk_live-nycklar och nio begränsade nycklar. Av de berörda kontona kunde 573 ta emot betalningar, 531 göra utbetalningar och 519 göra både och, enligt den analys som citerats i rapporteringen.

Därför kan en enda aktiv nyckel vara allvarlig

En hemlig Stripe-nyckel är en API-behörighet, inte bara en identifierare. Hur mycket åtkomst den ger beror på nyckelns rättigheter och handlarens kontokonfiguration. En röjd nyckel kan ändå ge åtkomst till handlarens resurser och möjliggöra obehöriga betalningsåtgärder.

I den rapporterade testningen visades att en aktiv nyckel kunde användas för att läsa kundlistor, skapa falska betalningslänkar och genomföra testdebiteringar. Möjliga följder är kartläggning av kunddata, betalningsmissbruk, obehöriga återbetalningar, riktade nätfiskeförsök och social manipulation med koppling till betalningar. Konton med utbetalningsbehörighet behöver dessutom kontrollera inställningar och mottagardetaljer för utbetalningar.

Den praktiska risken ligger i snabbheten: en exponerad servernyckel kan förvandla ett bristande hemlighetsskydd till en pågående bedrägeriutredning innan företaget hinner upptäcka avvikande aktivitet.

Varför detta inte klassades som ett intrång i Stripes infrastruktur

Den tillgängliga bevisningen pekar på att angripare använde giltiga handlaruppgifter för att hämta Stripe-data genom legitim API-åtkomst. Forskare som granskade de publicerade filerna offline uppgav att Stripe-liknande objekt och katalogstrukturen stämde med exporter från API-anrop. De loggade inte in med de exponerade nycklarna och fick inte åtkomst till handlarnas aktiva miljöer som en del av granskningen.

Skillnaden är viktig. Den flyttar det sannolika kontrollfelet från Stripes centrala system till de platser där handlares hemligheter kan ha lagrats eller läckt, exempelvis:

• Infostealer-infektioner på utvecklares eller administratörers enheter
• Publika kodarkiv och äldre Git-historik
• Exponerade .env-filer och serverkonfiguration
• Molnlagring, säkerhetskopior och containerlager
• CI/CD-system och loggar från GitHub Actions
• Felkonfigurerade servrar eller automatiserade sökningar efter exponerade variabler

Den första stöldvägen för de 659 handlarnas uppgifter är fortfarande inte fastställd. Detta är möjliga exponeringsvägar, inte en bekräftad gemensam källa till hela datamängden.

Den relaterade publiceringen och varför siffrorna inte ska slås ihop

Hudson Rock kopplade en närliggande forumpublicering till samma aktör. Den beskrevs som omfattande 669 leverantörsmappar och 1 033 komprometterade API-nycklar, med en annonserad storlek på 33 GB. Den länkade nedladdningen uppgavs vara mindre. Aktören hävdade också att den hade omkring 20 000 ytterligare komprometterade Stripe-nycklar och antydde att fler delar kunde publiceras.

Siffrorna ska inte räknas ihop till en enda verifierad totalsumma. Skillnaden mellan 659 handlarkonton, 669 leverantörsmappar och 1 033 nycklar kan bero på olika datamängder, flera nycklar per konto, dubbletter eller olika sätt att räkna. Uppgiften om 20 000 nycklar är fortfarande ett obekräftat påstående från aktören.

Var fanns de rapporterade handlarna?

De länder som hade flest berörda handlare i den tillgängliga rapporteringen var:

• USA: 212 handlare
• Storbritannien: 81
• Frankrike: 57
• Kanada: 38
• Brasilien: 30
• Australien: 27

Fördelningen beskriver de rapporterade handlarna och bör läsas med förbehållet att datamängdens fulla omfattning fortfarande bedömdes.

Vad Stripe-företag bör göra nu

1. Rotera aktiva hemliga nycklar

Återkalla och ersätt alla aktiva hemliga nycklar som kan ha förekommit i källkod, loggar, säkerhetskopior, endpoint-telemetri, containeravbildningar eller publik infrastruktur. Vänta inte på bevis på bedräglig aktivitet innan en potentiellt exponerad nyckel roteras.

2. Granska API- och betalningsaktivitet

Sök i API- och säkerhetsloggar efter okända anrop, nya betalningslänkar, test- eller obehöriga debiteringar, oväntade återbetalningar, ändrade behörigheter och ovanliga IP-adresser. Bevara relevanta loggar så att en tidslinje kan byggas.

3. Kontrollera utbetalningsinställningar

Verifiera utbetalningsinställningar, anslutna bankkonton och mottagardetaljer. Misstänkta ändringar bör snabbt eskaleras till Stripe och berörda finansinstitut enligt företagets incidentrutiner och tillämpliga rapporteringskrav.

4. Ersätt breda nycklar med begränsade nycklar

Använd begränsade nycklar som bara har de API-rättigheter som respektive tjänst behöver. Separera produktionssystem, utvecklingsmiljöer och operativa roller i stället för att sprida en bred hemlighet mellan flera applikationer.

5. Sök igenom alla platser där hemligheter kan finnas kvar

Sök i aktuella och historiska kodarkiv, Git-historik, CI/CD-utdata, GitHub Actions-loggar, .env-filer, containerlager, molnlagring, dokumentation och säkerhetskopior efter värden som börjar med sk_live. Alla upptäckta uppgifter ska återkallas och ersättas, även om de inte längre finns i den aktuella kodversionen.

6. Se GitHub-skanning som ett lager – inte som heltäckande skydd

GitHub uppger att secret scanning körs automatiskt för publika arkiv. För organisationsägda privata och interna arkiv krävs GitHub Secret Protection på berättigade abonnemang. Skanning kan inte heller återkalla hemligheter som redan kopierats till loggar, säkerhetskopior, endpoint-telemetri eller nedladdade arkiv. Den bör därför komplettera, inte ersätta, central hantering av hemligheter, korta livslängder för autentiseringsuppgifter, åtkomstkontroller och kontinuerlig övervakning.

Den viktigaste lärdomen för handlare

Den tydligaste slutsatsen är att säkerheten i en betalplattform också beror på handlarens hantering av autentiseringsuppgifter. Den tillgängliga rapporteringen fastslår inte att Stripes infrastruktur har utsatts för intrång, men visar hur exponerade aktiva API-nycklar kan ge tillgång till kunddata och skapa möjligheter till betalningsmissbruk. Produktionshemligheter bör därför behandlas som högriskuppgifter: håll dem borta från kod och loggar, begränsa deras behörigheter, rotera dem snabbt och utred varje oväntad API- eller utbetalningshändelse.