Akademia NIS2/KSC2 od sekuraka. 19 października start drugiej edycji!
Zobacz nasz aktualny kalendarz szkoleń!
Railway podało szczegóły incydentu bezpieczeństwa. Zagrożone mogły być zmienne środowiskowe 100 tys. workspaces
20 października 2026 r. w Railway (platforma chmurowa do uruchamiania aplikacji, usług i baz danych) wykryto nietypowy ruch w systemach przechowujących zmienne środowiskowe klientów. Ustalono, że nieupoważniona osoba mogła uzyskać dostęp do zaszyfrowanych zmiennych środowiskowych, a w przypadku niektórych z nich również do ich odszyfrowanej zawartości. W zmiennych środowiskowych klienci przechowują m.in. klucze/tokeny API, dane uwierzytelniające do baz danych i inne poświadczenia.
TLDR:
- Railway ujawniło incydent bezpieczeństwa, w wyniku którego atakujący mógł uzyskać dostęp do zaszyfrowanych zmiennych środowiskowych klientów, a w przypadku części z nich również do ich odszyfrowanej zawartości.
- Według Railway potencjalnie zagrożone zmienne środowiskowe mogły znajdować się w maksymalnie 100 tys. workspaces, co stanowi 1,85% wszystkich workspaces na platformie.
- Prawdopodobnym celem ataku było pozyskanie kluczy API dostawców AI. Railway współpracowało z zewnętrznymi podmiotami, aby zapobiegawczo unieważnić klucze API przechowywane na platformie.
- Firma poinformowała, że atakujący nie uzyskał dostępu do kont użytkowników. Nie wykluczono jednak możliwości uzyskania dostępu do kodu źródłowego.
- Railway przywróciło możliwość tworzenia buildów i wdrażania nowych wersji. Firma zaleca sprawdzenie zmiennych środowiskowych oraz rotację przechowywanych w nich kluczy API i innych poświadczeń.
W pierwszym opublikowanym komunikacie wskazano, że – według wstępnej analizy – problem dotknął tylko części użytkowników. Wszystkim klientom zalecono jednak natychmiastową rotację wszystkich zmiennych środowiskowych przechowywanych w Railway oraz sprawdzenie logów tych usług pod kątem nietypowej aktywności. Po wykryciu incydentu wszystkie wdrożenia (deployments) zostały wstrzymane na czas dochodzenia.
22 października użytkownicy Railway (lub część z nich) otrzymali taką wiadomość:
Tego samego dnia firma opublikowała drugi komunikat na swoim blogu. Wskazała, że prawdopodobnym celem ataku było pozyskanie kluczy API dostawców AI. W ocenie Railway atak trwał od 20 października (godz. 15:58) do 22 października (godz. 5:32). Incydent uznano za zakończony w momencie, w którym potwierdzono, że atakujący nie miał już dostępu do żadnych systemów wewnętrznych.
Następnego dnia Railway wysłało taki komunikat:
Firma wskazuje, że jej systemy zaprojektowane są tak, aby w przypadku przejęcia jednego zestawu kluczy nie doszło do naruszenia bezpieczeństwa całego systemu. Potwierdzono, że przejęte mogły zostać zmienne środowiskowe maksymalnie 100 tys. workspaces (stanowiących 1,85% wszystkich na platformie). W ramach obsługi incydentu Railway zapobiegawczo powiadomiło zewnętrznych dostawców o konieczności unieważnienia wszystkich przechowywanych przez platformę kluczy (także tych, których nie objął potwierdzony zakres ataku).
Railway kontaktuje się z klientami, w przypadku których potwierdzono bezpośredni wpływ incydentu oraz tymi, których uznano za objętych wysokim ryzykiem. Firma wskazała, że choć nie można wykluczyć dostępu do kodu źródłowego użytkowników, atakujący nie uzyskał dostępu do ich kont na platformie.
W ramach obsługi incydentu podjęto współpracę z GitHub, GitLab, Anthropic, OpenAI, OpenRouter, SpaceXSI, Stripe i innymi podmiotami, aby unieważnić potencjalnie przejęte klucze. Z uwagi na fakt, że działanie to dotknęło wszystkich kluczy przechowywanych na platformie, otrzymanie powiadomienia o unieważnieniu kluczy nie oznacza, że dane konkretnego użytkownika zostały naruszone w wyniku tego incydentu.
W komunikacie firma poinformowała również, że wyłączone wcześniej wdrożenia (deployments) zostały przywrócone. Aplikacje klientów nie zostały wstrzymane podczas obsługi incydentu, zablokowana była za to możliwość wydawania nowych wersji.
Użytkownikom Railway polecamy sprawdzenie, jakie klucze API i inne poświadczenia przechowują w zmiennych środowiskowych i rozważenie ich zrotowania. Docelowo warto – w miarę możliwości – wszelkie tego typu tokeny ograniczać do konkretnych adresów IP oraz nie przyznawać im niepotrzebnie dużych uprawnień.
Źródła:
~Tymoteusz Jóźwiak
