Najtrafniej opisywać to zdarzenie jako ujawnienie danych i poświadczeń należących do merchantów, a nie jako potwierdzone naruszenie infrastruktury Stripe. Dostępne dowody wskazują, że przestępcy wykorzystywali prawidłowe klucze API poszczególnych firm, aby pobierać dane za pośrednictwem legalnych endpointów Stripe.

Jakie dane znalazły się w archiwum

Raportowane materiały obejmowały okres od stycznia 2022 do czerwca 2026 r. Wśród wymienianych kategorii znalazły się:

• obiekty klientów Stripe i dane kontaktowe klientów;
• obciążenia, intencje płatności, sesje Checkout, faktury, zwroty i spory;
• wypłaty oraz transakcje na saldzie;
• subskrypcje, produkty i ceny;
• metadane związane z kartami, w tym marka, cztery ostatnie cyfry, data ważności, typ finansowania, kraj wydawcy i fingerprint płatności.

Raporty nie wskazywały na obecność pełnych numerów kart. Ogranicza to część ryzyka bezpośredniej kradzieży danych kartowych, ale nie eliminuje zagrożeń wynikających z ujawnienia aktywnych kluczy API oraz szczegółowych danych klientów i transakcji.

Badacze mieli znaleźć 650 aktywnych kluczy tajnych sk_live oraz dziewięć kluczy z ograniczonymi uprawnieniami. Spośród analizowanych kont 573 mogły przyjmować płatności, 531 realizować wypłaty, a 519 wykonywać oba rodzaje operacji.

Jeden aktywny klucz mógł wystarczyć do nadużycia

Tajny klucz Stripe nie jest zwykłym identyfikatorem — to poświadczenie umożliwiające dostęp programistyczny. Zakres działania zależy od uprawnień klucza i konfiguracji konta, ale jego przejęcie może otworzyć drogę do danych merchantów oraz nieautoryzowanych operacji płatniczych.

W testach opisanych w raportach pojedynczy aktywny klucz pozwalał uzyskać dostęp do list klientów, tworzyć fałszywe linki płatnicze i wykonywać testowe obciążenia. Potencjalne skutki obejmowały:

• wyliczanie i porządkowanie danych klientów oraz transakcji;
• nadużycia płatnicze i oszustwa z wykorzystaniem linków;
• nieautoryzowane zwroty;
• ukierunkowany phishing i socjotechnikę;
• próby manipulowania ustawieniami wypłat.

Konta z możliwością realizowania wypłat wymagały dodatkowo sprawdzenia ustawień wypłat, podpiętych rachunków bankowych i danych odbiorców.

Skąd mogły pochodzić klucze

Analiza opublikowanych plików, przeprowadzona offline, wykazała strukturę obiektów i katalogów zgodną z eksportami uzyskiwanymi przez API Stripe. Badacze nie logowali się przy użyciu ujawnionych kluczy ani nie uzyskiwali dostępu do aktywnych środowisk merchantów w ramach tej weryfikacji.

To przesuwa prawdopodobny punkt awarii z infrastruktury Stripe na miejsca, w których firmy przechowują lub przypadkowo ujawniają sekrety. Możliwe drogi wycieku obejmują:

• infekcje infostealerami na komputerach deweloperów lub administratorów;
• publiczne repozytoria i historię zmian w Git;
• pliki .env oraz konfigurację serwerów;
• magazyny w chmurze, kopie zapasowe i warstwy obrazów kontenerów;
• systemy CI/CD oraz logi GitHub Actions;
• błędnie skonfigurowane serwery i automatyczne skanowanie ujawnionych zmiennych.

Nie ustalono jednak, w jaki sposób początkowo skradziono poświadczenia 659 merchantów. Powyższe scenariusze są możliwymi drogami ekspozycji, a nie potwierdzonym wspólnym źródłem całego zbioru.

Powiązana publikacja i problem z liczbami

Hudson Rock przypisał temu samemu sprawcy powiązaną publikację na forum Pwnforums. Początkowy zrzut miał obejmować 669 folderów dostawców i 1 033 przejęte klucze API; reklamowany rozmiar wynosił 33 GB, choć wskazany plik do pobrania miał być mniejszy.

Sprawca twierdził również, że ma około 20 tys. kolejnych przejętych kluczy API Stripe i może opublikować następne partie. To niezweryfikowane twierdzenie, a nie potwierdzona liczba. Różnice między 659 kontami, 669 folderami i 1 033 kluczami mogą wynikać z odmiennych zbiorów danych, wielu kluczy przypisanych do jednego konta, duplikatów albo różnych metod liczenia. Nie należy sumować tych wartości w jeden zweryfikowany bilans.

Kraje z największą liczbą merchantów

Według dostępnych raportów najwięcej dotkniętych kont znajdowało się w:

• Stanach Zjednoczonych — 212 merchantów;
• Wielkiej Brytanii — 81;
• Francji — 57;
• Kanadzie — 38;
• Brazylii — 30;
• Australii — 27.

To rozkład geograficzny opisywanego zbioru, którego pełny zakres nadal podlegał ocenie.

Co firmy korzystające ze Stripe powinny zrobić

1. Natychmiast wymienić aktywne klucze

Należy unieważnić i zastąpić każdy aktywny klucz, który mógł trafić do kodu źródłowego, logów, kopii zapasowych, telemetrii urządzeń, obrazów kontenerów lub publicznej infrastruktury. Nie warto czekać na pierwsze oznaki oszustwa.

2. Przeanalizować aktywność API i operacje płatnicze

Trzeba sprawdzić logi API i bezpieczeństwa pod kątem nieznanych wywołań, nowych linków płatniczych, testowych lub nieautoryzowanych obciążeń, nietypowych zwrotów, zmian uprawnień i podejrzanych adresów IP. Istotne logi należy zabezpieczyć, aby móc odtworzyć oś czasu zdarzeń.

3. Zweryfikować konfigurację wypłat

Warto sprawdzić ustawienia wypłat, dane podpiętych rachunków bankowych oraz miejsca docelowe przelewów. Podejrzane zmiany należy niezwłocznie zgłosić Stripe i odpowiednim instytucjom finansowym, zgodnie z procedurami reagowania na incydenty.

4. Zastąpić szerokie uprawnienia kluczami ograniczonymi

Każdy klucz powinien mieć wyłącznie uprawnienia potrzebne danemu serwisowi. Środowiska produkcyjne i testowe oraz role operacyjne należy rozdzielać zamiast używać jednego szerokiego sekretu w wielu aplikacjach.

5. Przeszukać wszystkie miejsca, w których sekrety mogły pozostać

Należy sprawdzić bieżące i historyczne repozytoria, historię Git, wyniki CI/CD, logi GitHub Actions, pliki .env, warstwy kontenerów, magazyny chmurowe, dokumentację i kopie zapasowe pod kątem wartości sk_live. Każdy znaleziony klucz trzeba unieważnić i zastąpić — również wtedy, gdy nie występuje już w aktualnej wersji kodu.

6. Nie polegać wyłącznie na skanowaniu GitHub

GitHub automatycznie skanuje publiczne repozytoria, natomiast skanowanie prywatnych i wewnętrznych repozytoriów organizacji wymaga włączenia GitHub Secret Protection w kwalifikujących się planach. Skanowanie nie wykryje sekretów, które trafiły do logów poza GitHub, kopii zapasowych, telemetrii urządzeń lub już pobranych archiwów. Powinno uzupełniać, a nie zastępować centralne zarządzanie sekretami, krótkie okresy ważności poświadczeń, kontrolę dostępu i ciągłe monitorowanie.

Najważniejsza lekcja dla merchantów

Dostępne informacje nie potwierdzają włamania do infrastruktury Stripe. Pokazują jednak, że wyciek jednego produkcyjnego klucza API może bardzo szybko przerodzić się w incydent obejmujący dane klientów, oszustwa płatnicze i ryzyko nieautoryzowanych wypłat. Klucze produkcyjne należy traktować jak poświadczenia o wysokim wpływie: trzymać je poza kodem i logami, ograniczać ich uprawnienia, szybko rotować i badać każdą nietypową operację API lub wypłatę.

Najtrafniej opisywać to zdarzenie jako ujawnienie danych i poświadczeń należących do merchantów, a nie jako potwierdzone naruszenie infrastruktury Stripe. Dostępne dowody wskazują, że przestępcy wykorzystywali prawidłowe klucze API poszczególnych firm, aby pobierać dane za pośrednictwem legalnych endpointów Stripe.

Jakie dane znalazły się w archiwum

Raportowane materiały obejmowały okres od stycznia 2022 do czerwca 2026 r. Wśród wymienianych kategorii znalazły się:

• obiekty klientów Stripe i dane kontaktowe klientów;
• obciążenia, intencje płatności, sesje Checkout, faktury, zwroty i spory;
• wypłaty oraz transakcje na saldzie;
• subskrypcje, produkty i ceny;
• metadane związane z kartami, w tym marka, cztery ostatnie cyfry, data ważności, typ finansowania, kraj wydawcy i fingerprint płatności.

Raporty nie wskazywały na obecność pełnych numerów kart. Ogranicza to część ryzyka bezpośredniej kradzieży danych kartowych, ale nie eliminuje zagrożeń wynikających z ujawnienia aktywnych kluczy API oraz szczegółowych danych klientów i transakcji.

Badacze mieli znaleźć 650 aktywnych kluczy tajnych sk_live oraz dziewięć kluczy z ograniczonymi uprawnieniami. Spośród analizowanych kont 573 mogły przyjmować płatności, 531 realizować wypłaty, a 519 wykonywać oba rodzaje operacji.

Jeden aktywny klucz mógł wystarczyć do nadużycia

Tajny klucz Stripe nie jest zwykłym identyfikatorem — to poświadczenie umożliwiające dostęp programistyczny. Zakres działania zależy od uprawnień klucza i konfiguracji konta, ale jego przejęcie może otworzyć drogę do danych merchantów oraz nieautoryzowanych operacji płatniczych.

W testach opisanych w raportach pojedynczy aktywny klucz pozwalał uzyskać dostęp do list klientów, tworzyć fałszywe linki płatnicze i wykonywać testowe obciążenia. Potencjalne skutki obejmowały:

• wyliczanie i porządkowanie danych klientów oraz transakcji;
• nadużycia płatnicze i oszustwa z wykorzystaniem linków;
• nieautoryzowane zwroty;
• ukierunkowany phishing i socjotechnikę;
• próby manipulowania ustawieniami wypłat.

Konta z możliwością realizowania wypłat wymagały dodatkowo sprawdzenia ustawień wypłat, podpiętych rachunków bankowych i danych odbiorców.

Skąd mogły pochodzić klucze

Analiza opublikowanych plików, przeprowadzona offline, wykazała strukturę obiektów i katalogów zgodną z eksportami uzyskiwanymi przez API Stripe. Badacze nie logowali się przy użyciu ujawnionych kluczy ani nie uzyskiwali dostępu do aktywnych środowisk merchantów w ramach tej weryfikacji.

To przesuwa prawdopodobny punkt awarii z infrastruktury Stripe na miejsca, w których firmy przechowują lub przypadkowo ujawniają sekrety. Możliwe drogi wycieku obejmują:

• infekcje infostealerami na komputerach deweloperów lub administratorów;
• publiczne repozytoria i historię zmian w Git;
• pliki .env oraz konfigurację serwerów;
• magazyny w chmurze, kopie zapasowe i warstwy obrazów kontenerów;
• systemy CI/CD oraz logi GitHub Actions;
• błędnie skonfigurowane serwery i automatyczne skanowanie ujawnionych zmiennych.

Nie ustalono jednak, w jaki sposób początkowo skradziono poświadczenia 659 merchantów. Powyższe scenariusze są możliwymi drogami ekspozycji, a nie potwierdzonym wspólnym źródłem całego zbioru.

Powiązana publikacja i problem z liczbami

Hudson Rock przypisał temu samemu sprawcy powiązaną publikację na forum Pwnforums. Początkowy zrzut miał obejmować 669 folderów dostawców i 1 033 przejęte klucze API; reklamowany rozmiar wynosił 33 GB, choć wskazany plik do pobrania miał być mniejszy.

Sprawca twierdził również, że ma około 20 tys. kolejnych przejętych kluczy API Stripe i może opublikować następne partie. To niezweryfikowane twierdzenie, a nie potwierdzona liczba. Różnice między 659 kontami, 669 folderami i 1 033 kluczami mogą wynikać z odmiennych zbiorów danych, wielu kluczy przypisanych do jednego konta, duplikatów albo różnych metod liczenia. Nie należy sumować tych wartości w jeden zweryfikowany bilans.

Kraje z największą liczbą merchantów

Według dostępnych raportów najwięcej dotkniętych kont znajdowało się w:

• Stanach Zjednoczonych — 212 merchantów;
• Wielkiej Brytanii — 81;
• Francji — 57;
• Kanadzie — 38;
• Brazylii — 30;
• Australii — 27.

To rozkład geograficzny opisywanego zbioru, którego pełny zakres nadal podlegał ocenie.

Co firmy korzystające ze Stripe powinny zrobić

1. Natychmiast wymienić aktywne klucze

Należy unieważnić i zastąpić każdy aktywny klucz, który mógł trafić do kodu źródłowego, logów, kopii zapasowych, telemetrii urządzeń, obrazów kontenerów lub publicznej infrastruktury. Nie warto czekać na pierwsze oznaki oszustwa.

2. Przeanalizować aktywność API i operacje płatnicze

Trzeba sprawdzić logi API i bezpieczeństwa pod kątem nieznanych wywołań, nowych linków płatniczych, testowych lub nieautoryzowanych obciążeń, nietypowych zwrotów, zmian uprawnień i podejrzanych adresów IP. Istotne logi należy zabezpieczyć, aby móc odtworzyć oś czasu zdarzeń.

3. Zweryfikować konfigurację wypłat

Warto sprawdzić ustawienia wypłat, dane podpiętych rachunków bankowych oraz miejsca docelowe przelewów. Podejrzane zmiany należy niezwłocznie zgłosić Stripe i odpowiednim instytucjom finansowym, zgodnie z procedurami reagowania na incydenty.

4. Zastąpić szerokie uprawnienia kluczami ograniczonymi

Każdy klucz powinien mieć wyłącznie uprawnienia potrzebne danemu serwisowi. Środowiska produkcyjne i testowe oraz role operacyjne należy rozdzielać zamiast używać jednego szerokiego sekretu w wielu aplikacjach.

5. Przeszukać wszystkie miejsca, w których sekrety mogły pozostać

Należy sprawdzić bieżące i historyczne repozytoria, historię Git, wyniki CI/CD, logi GitHub Actions, pliki .env, warstwy kontenerów, magazyny chmurowe, dokumentację i kopie zapasowe pod kątem wartości sk_live. Każdy znaleziony klucz trzeba unieważnić i zastąpić — również wtedy, gdy nie występuje już w aktualnej wersji kodu.

6. Nie polegać wyłącznie na skanowaniu GitHub

GitHub automatycznie skanuje publiczne repozytoria, natomiast skanowanie prywatnych i wewnętrznych repozytoriów organizacji wymaga włączenia GitHub Secret Protection w kwalifikujących się planach. Skanowanie nie wykryje sekretów, które trafiły do logów poza GitHub, kopii zapasowych, telemetrii urządzeń lub już pobranych archiwów. Powinno uzupełniać, a nie zastępować centralne zarządzanie sekretami, krótkie okresy ważności poświadczeń, kontrolę dostępu i ciągłe monitorowanie.

Najważniejsza lekcja dla merchantów

Dostępne informacje nie potwierdzają włamania do infrastruktury Stripe. Pokazują jednak, że wyciek jednego produkcyjnego klucza API może bardzo szybko przerodzić się w incydent obejmujący dane klientów, oszustwa płatnicze i ryzyko nieautoryzowanych wypłat. Klucze produkcyjne należy traktować jak poświadczenia o wysokim wpływie: trzymać je poza kodem i logami, ograniczać ich uprawnienia, szybko rotować i badać każdą nietypową operację API lub wypłatę.