Railway to platforma chmurowa typu PaaS, używana do wdrażania aplikacji. 10 listopada 2026 roku opublikowała pełny raport z naruszenia, które trwało 20 i 21 października.
Liczba podana przez samą firmę: „Nieautoryzowane wydatki na skradzionych kluczach oszacowano na około 740 000 dolarów".
Przebieg ataku
Kiedy (UTC) | Co |
|---|---|
20 października, 13:50 do 15:30 | Napastnik odczytuje zapisane historie 353 procesów budowania, łącznie z zapieczętowanymi zmiennymi |
20 października, 13:58 | Railway wykrywa nietypowe wywołania API rejestru i stwierdza nieuprawniony dostęp |
21 października, 04:07 do 05:21 | Napastnik pobiera zaszyfrowane zmienne z bazy, odpytując o nazwy pasujące do kluczy dostawców AI |
21 października, 07:14 | Railway wyłącza wszystkie aktywne poświadczenia chmurowe, unieważnia poświadczenia statyczne i zatrzymuje usługę odszyfrowywania kluczy |
21 października, 09:25 | Powiadamia GitHub, GitLab, Anthropic, OpenAI, OpenRouter, SpaceXSI, Google i Stripe, przekazując listy potencjalnie ujawnionych kluczy |
22 października | Publiczne ujawnienie, wezwanie klientów do wymiany sekretów |
10 listopada | Pełny raport z incydentu |
Droga wejścia łączyła ucieczkę z izolacji systemu budowania z błędną konfiguracją zaufania w chmurze, co pozwoliło napastnikowi przejść przez systemy wewnętrzne i uwierzytelnić się w usłudze zarządzania kluczami, by odszyfrować pasujące pozycje.
Zakres
Do około 100 000 przestrzeni roboczych, czyli mniej więcej 1,85% wszystkich. Railway opisuje to jako populację potencjalnie narażoną, a nie potwierdzoną liczbę skradzionych sekretów.
1852 użytkowników straciło tokeny kont powiązanych, w tym tokeny GitHub OAuth i klucze agentów AI. Railway je zresetowało i powiadomiło właścicieli.
Brak przesłanek wskazujących na logowania do kont Railway przy użyciu skradzionych poświadczeń, dostęp do baz danych klientów czy pobieranie repozytoriów Git.
Napastnika nie wskazano. Railway sądzi, że klucze trafiły do usług pośredniczących lub odsprzedających dostęp do AI, potencjalnie na potrzeby destylacji modeli, ale zaznacza, że nie ustaliło, czy napastnik sam te usługi prowadził.
Napastnik szukał po nazwach
To szczegół, przy którym warto się zatrzymać, bo mówi, co się właściwie zmieniło.
Napastnik nie zabrał wszystkiego. Analiza śledcza Railway wykazała, że zapytania dotyczyły konkretnie poświadczeń AI, a część celowała dodatkowo w klucze chmurowe, bazodanowe i płatnicze. Intruz pobrał zaszyfrowane zmienne, poszukał nazw pasujących do wzorców kluczy dostawców AI, a następnie odszyfrował wyłącznie pasujący podzbiór.
To lista zakupów, a nie wyniesienie wszystkiego, co się da. Ktoś dokładnie wiedział, czego chce, a chciał tego, co przelicza się bezpośrednio na moc obliczeniową.
Na skutek tego procederu przyjęła się nazwa LLMjacking: wykorzystywanie skradzionych poświadczeń do konsumowania płatnych usług AI na koszt ofiary. Zaobserwowane przez Railway użycie obejmowało od agentów programistycznych po potoki trenowania modeli.
Kwestia tego, kto płaci
Stanowisko Railway się zmieniło i ta zmiana ma znaczenie.
26 października, odpowiadając klientom pytającym o zwroty, firma stwierdziła, że „Railway nie jest w stanie zwrócić klientom kosztów wydatków poniesionych przy użyciu skompromitowanych kluczy API", zachęcając do kontaktu bezpośrednio z dostawcami AI i oferując eskalację zgłoszeń.
W listopadowym raporcie zobowiązuje się natomiast do pokrycia kosztów związanych z naruszeniem z własnych środków tam, gdzie dostawcy odmówią zwrotu, przy jednoczesnej pracy z dostawcami nad refundacjami.
Ten zwrot wart jest odnotowania, a nie przemilczenia. Pierwsze stanowisko było do obrony i jest powszechne. Drugie jest nietypowe i przenosi koszt, który inaczej spadłby na klientów, których jedyną winą było przechowywanie klucza tam, gdzie platforma kazała im go trzymać.
Dla poszkodowanych praktyczna kolejność pozostaje trójstronna: najpierw roszczenie u dostawcy AI, potem zgłoszenie obciążenia do Railway, a na końcu oczekiwanie, że Railway pokryje to, czego dostawca odmówi.
To kampania, a nie incydent
Railway jest jedną z wielu platform. Wiz skatalogował ten wzorzec jako Black October, licząc co najmniej dziewięć platform deweloperskich AI, które w ciągu miesiąca ujawniły kradzież poświadczeń.
Obok Railway wymieniane są OpenCode, Warp, Fireworks AI, Northflank, Lightning AI oraz Zeabur. Własny raport Railway odnotowuje, że OpenCode, Warp, Fireworks AI i inni ujawnili podobne kradzieże między 6 a 23 października, i ocenia własne naruszenie jako jedno z serii ataków na platformy przechowujące klucze AI.
Odrębne naruszenie w Zeabur miało według doniesień przynieść około 100 000 dolarów nieuprawnionych obciążeń. Doniesienia powołujące się na Wall Street Journal szacują łączne straty na ponad 1,1 miliona dolarów, licząc razem z kradzieżą kryptowalut na około 371 000 dolarów.
Wniosek jest prosty. Platformy przechowujące sekrety deweloperów stały się zdefiniowaną kategorią celów, bo jedno włamanie daje tysiące kluczy, które przeliczają się na pieniądze bez żadnej dalszej eksploatacji.
Co zrobić
Jeśli korzystałeś z Railway
Wymień wszystko, co tam przechowywałeś, nie tylko klucze AI. Październikowy komunikat wymieniał klucze API, poświadczenia bazodanowe i poświadczenia rejestru.
Sprawdź rozliczenia u dostawców od 18 października, w usługach AI, chmurowych i płatniczych. Jeden z klientów opisał klucz Gemini obciążony kwotą 2,22 dolara 1 października, a następnie 100 dolarów 21 października i 200 dolarów 22 października.
Zgłoś nieautoryzowane obciążenia najpierw dostawcy, a potem Railway przez jego formularz. W przypadku części dostawców Railway prosi o otwarcie zgłoszenia u producenta i przekazanie numeru sprawy.
Sprawdź, czy jesteś wśród 1852 osób. Tym użytkownikom zresetowano tokeny kont powiązanych, w tym GitHub OAuth.
Jeśli przechowujesz sekrety na jakiejkolwiek platformie
Zakładaj, że Twój magazyn sekretów jest wskazanym celem. Napastnik szukał po nazwach zmiennych. Typowe nazwy w rodzaju
OPENAI_API_KEYto dokładnie to, co pasowało do zapytania.Ustaw twarde limity wydatków na każdym koncie dostawcy AI. To jedyny mechanizm ograniczający szkodę i prawie nikt go nie ustawia przed pierwszym incydentem.
Włącz alerty o anomaliach w rozliczeniach i zadbaj, żeby ktoś je czytał. W opisanym przypadku klient przeoczył wiadomość z ostrzeżeniem o nietypowym skoku kosztów.
Nadawaj kluczom wąskie uprawnienia i wymieniaj je cyklicznie, zamiast tworzyć jeden długowieczny klucz z pełnym dostępem.
Wybieraj poświadczenia krótkoterminowe lub tożsamość obciążenia zamiast kluczy statycznych tam, gdzie dostawca to umożliwia. Klucz, który wygasa, ma znacznie niższą wartość odsprzedażową.
Czym to się różni od zwykłego naruszenia
Skradzione poświadczenia zwykle wymagają pracy, zanim przyniosą pieniądze. Trzeba je sprzedać, przetestować wobec innych usług, wykorzystać do dostępu prowadzącego gdzieś dalej. Między kradzieżą a zyskiem jest łańcuch.
Klucz dostawcy AI pomija to wszystko. To token na okaziciela uprawniający do mocy obliczeniowej, rozliczanej na kogoś innego, użyteczny natychmiast i na tyle płynny, by odsprzedać go usługom pośredniczącym. Bez ruchu bocznego, bez negocjacji okupu, bez szukania nabywcy na bazę danych. Kradzież i zarobek są tym samym działaniem.
Dlatego dziewięć platform ujawniło incydenty w jeden miesiąc i dlatego napastnik odpytywał o nazwy kluczy, zamiast zabrać całą bazę. Ekonomika kradzieży poświadczeń zmieniła się w momencie, gdy poświadczenia zaczęły wskazywać na rozliczaną moc obliczeniową, a platformy je przechowujące nie skończyły jeszcze dostosowań.
