Co się stało w Railway
Railway, platforma do hostowania aplikacji, baz danych i usług w modelu PaaS, wykryła 21 października 2026 r. nietypową aktywność w systemach, które przechowują zmienne środowiskowe klientów. Według firmy nieuprawniona osoba mogła uzyskać dostęp do zaszyfrowanych zmiennych, a w części przypadków także do ich odszyfrowanej zawartości. Railway ocenia, że dotyczy to „podzbioru użytkowników”, ale nie podała liczby kont ani sposobu, w jaki doszło do włamania. Mimo to zaleca rotację sekretów wszystkim klientom, bez czekania na potwierdzenie, że incydent objął ich konto.
Firma łączy incydent z serią ataków na platformy deweloperskie, których celem jest dostęp do dostawców modeli AI. Railway powiadomiła tych dostawców, żeby zawczasu unieważnili klucze. Po swojej stronie unieważniła wszystkie tokeny API Railway i wymienia dane dostępowe do storage bucketów. Na czas dochodzenia wstrzymała buildy i wdrożenia; 22 października przywracała je etapami, najpierw dla planów Enterprise i Pro, potem Hobby, a na końcu Free i Trial.
Dlaczego to poważniejsze niż typowy wyciek haseł
W zmiennych środowiskowych aplikacje trzymają wszystko, czego potrzebują do działania: adresy i hasła baz danych (DATABASE_URL), klucze do AWS i GCP, tokeny GitHuba, klucze do OpenAI czy Anthropic, klucze płatności, SMTP, rejestrów kontenerów. Kto ma te wartości, loguje się do Waszych usług jak Wasza aplikacja. Nie potrzebuje hasła użytkownika ani obejścia MFA. Dlatego oceniamy ryzyko jako wysokie, mimo że Railway mówi o części klientów. Jeśli korzystacie z Railway choćby dla jednego projektu testowego, sprawdźcie, jakie sekrety tam trafiły: często są to te same klucze co na produkcji.
Co dokładnie zmienić
- Klucze chmurowe (AWS access key, konta serwisowe GCP, Azure): wygenerujcie nowe, stare usuńcie.
- Hasła baz danych, także baz uruchomionych w samym Railway i zewnętrznych, do których łączy się aplikacja. Zmiana w Postgresie:
ALTER ROLE app_user WITH PASSWORD '...'; - Klucze API usług zewnętrznych: dostawcy AI, płatności, mailing, SMS, CRM.
- Tokeny wdrożeniowe i dostęp do repozytoriów: tokeny GitHub/GitLab, deploy keys, dane do prywatnych rejestrów kontenerów.
- Tokeny Railway: stare przestały działać, więc w CI/CD trzeba wpisać nowe.
- Sekrety aplikacji: klucze do podpisywania sesji i JWT, sekrety webhooków. Ich zmiana wyloguje użytkowników, ale bez niej ktoś może podrobić sesję.
Listę zmiennych każdej usługi pobierzecie przez CLI: railway variable list --service <usługa> --environment <środowisko> --kv. Plik z wynikiem usuńcie po zakończeniu pracy. Kolejność ma znaczenie: nowy sekret generujecie u dostawcy (AWS, GitHub, dostawca AI), wpisujecie go w Railway, wdrażacie aplikację i dopiero wtedy unieważniacie stary. Jeśli wdrożenia w Waszym planie są jeszcze wstrzymane, a klucz daje szerokie uprawnienia (np. administrator konta AWS), unieważnijcie go od razu i przyjmijcie przerwę w działaniu aplikacji. To mniejszy koszt niż cudzy dostęp do chmury.
Jak sprawdzić, czy ktoś już z tego skorzystał
- AWS: w CloudTrail szukajcie wywołań z kluczy aplikacji spoza znanych adresów IP, nowych użytkowników IAM, nowych kluczy dostępowych i instancji w nieużywanych regionach, np.
aws cloudtrail lookup-events --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=AKIA... - GCP: Cloud Audit Logs dla kont serwisowych, nowe klucze kont serwisowych, zmiany w IAM.
- GitHub: dziennik audytu organizacji, nowe deploy keys, nieoczekiwane klonowania i nowe workflow.
- Bazy danych: logi połączeń z obcych adresów, nietypowe zapytania eksportujące całe tabele.
- Dostawcy AI i inne API: wykres zużycia w panelu dostawcy, nagłe skoki liczby zapytań poza godzinami pracy aplikacji.
- Rozliczenia: faktury i alerty budżetowe w chmurze. Nadużyte klucze często widać najpierw po rachunku.
Ustawcie też alerty budżetowe, jeśli ich nie macie. Railway zapowiedziała, że klientów z potwierdzonym wyciekiem powiadomi mailem, więc pilnujcie skrzynki właściciela konta, ale nie traktujcie braku maila jako potwierdzenia, że Was to nie dotyczy.
Ta sama lista dla każdej platformy PaaS
Zestaw kroków jest uniwersalny: przy podobnym incydencie u Vercel, Heroku, Render, Netlify czy innego dostawcy CI/CD robicie to samo. Spis sekretów, rotacja u źródła, wdrożenie, unieważnienie starych, przegląd logów i rachunków. Wniosek na dłużej: zmienne środowiskowe na platformie PaaS to wygodne, ale skumulowane ryzyko, bo jeden incydent u dostawcy odsłania wszystkie klucze naraz. Pomagają klucze z minimalnymi uprawnieniami, osobne dla każdego środowiska, krótko żyjące poświadczenia (np. federacja OIDC zamiast stałych kluczy AWS) oraz menedżer sekretów, z którego aplikacja pobiera wartości przy starcie. Jeśli nie wiecie dziś, które klucze leżą na której platformie i jak szybko da się je wymienić, ten incydent to dobry moment, żeby taki spis zrobić.