Co znajdziesz w tym artykule?
- 1 Wprowadzenie do problemu / definicja luki
- 2 W skrócie
- 3 Kontekst / historia / powiązania
- 4 Analiza techniczna / szczegóły incydentu
- 5 Praktyczne konsekwencje / ryzyko
- 6 Rekomendacje operacyjne / co zrobić teraz
- 7 Różnice / porównania z innymi przypadkami (jeśli dotyczy)
- 8 Podsumowanie / kluczowe wnioski
- 9 Źródła / bibliografia
Wprowadzenie do problemu / definicja luki
Na początku lutego 2026 r. Substack (platforma do publikowania i monetyzacji newsletterów) zaczął wysyłać do części użytkowników powiadomienia o „incydencie bezpieczeństwa”, który miał skutkować nieautoryzowanym dostępem do ograniczonego zakresu danych kont. Kluczowy kontekst: komunikat pojawił się po tym, jak aktor z forum cyberprzestępczego opublikował/leakował bazę danych, twierdząc, że pochodzi z Substacka.
W skrócie
- Kiedy doszło do dostępu? Substack wskazuje na październik 2025.
- Kiedy wykryto problem? 3 lutego 2026 (Substack mówi o „evidence of a problem” w systemach).
- Jakie dane mogły zostać ujawnione? Co najmniej adresy e-mail, numery telefonów i „wewnętrzne metadane” (bez podania pełnej listy pól).
- Czego nie ujawniono (wg Substacka)? Haseł, numerów kart płatniczych i innych danych finansowych.
- Skala? Brak oficjalnej liczby; w obiegu są roszczenia o ok. 700 tys. rekordów.
Kontekst / historia / powiązania
Z perspektywy bezpieczeństwa informacyjnego to klasyczny scenariusz „najpierw wyciek/roszczenie aktora, potem komunikacja firmy”. SecurityWeek i The Record opisują, że powiadomienia do użytkowników pojawiły się krótko po publikacji danych przez hakera, który przypisał sobie pozyskanie rekordów z Substacka.
Ważny detal: Substack komunikuje „problem z systemami umożliwiający dostęp nieautoryzowanej stronie trzeciej”, podczas gdy aktor zagrożeń opisuje pozyskanie danych jako „scraping” (automatyczne zbieranie danych) oraz określa metodę jako „noisy” i szybko załataną. Te dwie narracje mogą, ale nie muszą, opisywać to samo (scraping może dotyczyć warstwy aplikacyjnej/API; „problem z systemami” może oznaczać błąd autoryzacji, niewłaściwe uprawnienia lub nadużycie endpointu).
Analiza techniczna / szczegóły incydentu
1) Co wiemy z komunikacji Substacka
- Nieautoryzowany dostęp miał objąć ograniczony zakres danych użytkowników: e-mail, telefon oraz „internal metadata”.
- Substack deklaruje brak dostępu do haseł i danych płatniczych.
- Firma twierdzi, że naprawiła problem, prowadzi dochodzenie i wzmacnia zabezpieczenia.
2) Co twierdzi aktor zagrożeń / co krąży w obiegu
Według opisów w mediach branżowych (na podstawie wpisów z forów), w paczce danych mają się znajdować m.in. nazwy, e-maile, telefony, ID użytkowników, zdjęcia profilowe i biosy, a skala to ~697 tys. rekordów. Tych informacji Substack publicznie nie potwierdził w pełnym zakresie.
3) Najbardziej prawdopodobne wektory (bez przesądzania)
Ponieważ firma nie ujawniła technicznej przyczyny, sensowne hipotezy (typowe dla „scrapingu” i wycieków metadanych) to:
- błąd kontroli dostępu / autoryzacji (IDOR/BOLA) w endpointach API, pozwalający enumerować profile/rekordy,
- nadużycie mechanizmów wyszukiwania/eksportu (np. zbyt szerokie odpowiedzi API),
- brak skutecznych limitów (rate limiting) i detekcji automatyzacji przy masowym pobieraniu danych.
W praktyce: jeśli atak był „noisy”, to mogły zadziałać alerty anomalii ruchu, ale dopiero po wyciągnięciu części danych.
Praktyczne konsekwencje / ryzyko
Nawet jeśli wyciek ogranicza się do e-maili i numerów telefonów, to są to dane o wysokiej wartości dla atakujących:
- Phishing / smishing pod Substack i twórców
Wycieki kontaktów zwiększają skuteczność kampanii „reset hasła”, „problem z płatnością”, „weryfikacja konta twórcy”. Substack sam zaleca wzmożoną ostrożność wobec podejrzanych maili/SMS. - Ataki na prywatność (doxxing, łączenie tożsamości)
Telefon + e-mail ułatwiają korelację kont między serwisami i budowę profili (OSINT). - Ryzyko przejęcia numeru (SIM swap) – pośrednio
Sam numer nie wystarczy do SIM swap, ale pomaga w doborze celu i w socjotechnice wobec operatora. - Ryzyko dla twórców i subskrybentów
Jeśli w paczce faktycznie są elementy typu ID, zdjęcia, bio – rośnie ryzyko podszywania się, nękania i kampanii wymierzonych w konkretnych autorów.
Rekomendacje operacyjne / co zrobić teraz
Dla użytkowników Substack (twórców i czytelników)
- Włącz/zweryfikuj MFA na koncie Substack oraz na skrzynce e-mail (to e-mail jest najważniejszym „single point of failure”).
- Uważaj na SMS-y i maile z linkami: weryfikuj domenę, nie klikaj w „pilne potwierdzenia”.
- Zmień hasło, jeśli było współdzielone z innymi serwisami (nawet jeśli hasła nie wyciekły – credential stuffing często idzie „po kontakcie”).
- Ustaw alerty na koncie pocztowym (logowania, reguły przekierowań), bo atak na pocztę bywa kolejnym krokiem po wycieku e-maila.
- Dodaj ostrzeżenie do komunikacji z odbiorcami (banner w newsletterze: „nie prosimy o hasła / płatności SMS”).
- Monitoruj brand abuse (fałszywe domeny, klony stron logowania, kampanie na socialach).
- Wdróż DMARC/DKIM/SPF dla domeny wysyłkowej newslettera, by utrudnić spoofing.
Różnice / porównania z innymi przypadkami (jeśli dotyczy)
To zdarzenie wygląda bardziej jak ekspozycja danych kontaktowych + metadanych (często przez automatyzację i luki w warstwie aplikacji) niż klasyczny „pełny wyciek” z hasłami. W takich incydentach największą szkodą bywa wtórna fala phishingu i nadużyć, nawet gdy firma utrzymuje, że „brak dowodów na wykorzystanie danych”.
Podsumowanie / kluczowe wnioski
- Substack potwierdził incydent wykryty 3 lutego 2026, z dostępem datowanym na październik 2025.
- Ujawnione miały zostać co najmniej e-maile, telefony i metadane; hasła i dane płatnicze – według firmy – nie zostały pozyskane.
- W obiegu są roszczenia o ~700 tys. rekordów i szerszym zestawie pól, ale bez pełnego potwierdzenia po stronie Substacka.
- Najbardziej realne ryzyko „tu i teraz” to phishing/smishing oraz korelacja tożsamości.
Źródła / bibliografia
- SecurityWeek – opis incydentu i roszczeń aktora (~700 tys., scraping, „noisy”). (SecurityWeek)
- The Verge – fragmenty treści maila od CEO i oś czasu (październik 2025 / wykrycie 3 lutego 2026). (The Verge)
- The Record (Recorded Future News) – potwierdzenie zakresu danych i brak finansowych/hasłowych, brak danych o skali. (The Record from Recorded Future)
- BleepingComputer – wzmianka o 697,313 rekordach oraz kontekst BreachForums. (BleepingComputer)