Security Disclosure Railway

Новина оновлюється в міру появи нових даних.

Railway — популярна хмарна платформа для деплою застосунків, якою користуються тисячі стартапів і розробників. Інцидент зачіпає не лише саму платформу: якщо ключі до зовнішніх сервісів зберігалися в її змінних оточення, під загрозою опиняються й ці сервіси. Нижче — що відомо на зараз, що каже компанія і що робити користувачам.

📚 Зміст статті

• 📌 Що сталося
• 📌 Хронологія інциденту
• 📌 Що каже Railway
• 📌 Чому зупинено деплої
• 💼 Як це проявляється у ваших проєктах
• ✅ Що робити користувачам Railway
• 📌 Що поки невідомо
• ❓ Часті питання (FAQ)

🎯 Розділ 1. Що сталося

За даними Railway, вранці 21 жовтня компанія виявила аномальну активність у системах, які зберігають змінні оточення клієнтів. Попереднє розслідування показало, що стороння особа могла отримати доступ до зашифрованих змінних, а для частини з них — і до розшифрованого вмісту.

У змінних оточення розробники зазвичай тримають найчутливіші дані: API-ключі, паролі до баз даних, облікові дані приватних registry контейнерів. Тому інцидент зачіпає не лише саму платформу, а й усі зовнішні сервіси, ключі до яких у ній зберігалися.

🎯 Розділ 2. Хронологія інциденту

• 21 жовтня, ранок — Railway виявляє аномальну активність у системах зі змінними оточення.
• 21 жовтня, ~20:44 UTC — компанія публікує security disclosure у своєму блозі й зупиняє всі деплої.
• 21–22 жовтня — користувачі отримують email-сповіщення від Railway; AI-провайдери, зокрема OpenRouter, превентивно відключають ключі й повідомляють власників.

🎯 Розділ 3. Що каже Railway

Компанія вважає, що атака — частина серії нападів на платформні компанії, мета яких — дістатися до ключів AI-inference провайдерів. Railway повідомила цих провайдерів, щоб ті заздалегідь відкликали ключі.

За попередньою оцінкою, постраждала лише частина користувачів. Проте Railway рекомендує всім клієнтам негайно ротувати всі змінні оточення, API-ключі та облікові дані приватних registry, а також перевірити логи відповідних сервісів на підозрілу активність. Компанія обіцяє окремо написати тим, чиї акаунти підтвердять як постраждалі.

🎯 Розділ 4. Чому зупинено деплої

Поки розслідування триває, будь-який новий деплой означає, що платформа знову читає й розшифровує секрети — зокрема нові ключі, які користувачі щойно вписали. Якщо вразливість ще не закрита, свіжі ключі теж можуть витекти. Тому Railway спершу закриває діру, а вже потім відновлює збірки.

Уже запущені сервіси продовжують працювати. Заблоковані лише нові деплої, перезапуски й застосування змінених змінних.

🎯 Розділ 5. Як це проявляється у ваших проєктах

Якщо ваш застосунок на Railway працює з AI-API, найімовірніше, ви вже бачите:

• помилки 401 Unauthorized (або 402 Payment Required) від OpenRouter та інших AI-провайдерів, хоча баланс у плюсі й код не змінювався;
• банер «Limited Access — Deploys have been paused temporarily» у дашборді Railway при спробі передеплою;
• нові значення у Variables не застосовуються: контейнер працює зі старими змінними, доки його не перезапустять.

Ми зіткнулися з цим на практиці: в одному з наших проєктів на Spring Boot, розгорнутому на Railway, близько 01:30 UTC 22 жовтня всі запити до OpenRouter почали падати:

401 Unauthorized on POST request for "https://openrouter.ai/api/v1/chat/completions": [no body]
org.springframework.web.client.HttpClientErrorException$Unauthorized

Баланс був у плюсі, код не змінювався. Невдовзі прийшов лист від OpenRouter про превентивне відключення ключа. Новий ключ локально запрацював одразу, але на продакшн його не викотити: Variables оновлено, а контейнер і далі працює зі старим, уже відкликаним ключем. Пізніше 401 змінився на 402 — і це теж був старий ключ, а не проблема з оплатою.

Тобто ключ уже відкликано, а викотити новий неможливо, доки Railway не відновить деплої. Справа не у вашому коді.

🎯 Розділ 6. Що робити користувачам Railway

1. Ротуйте всі секрети, а не лише AI-ключі

Пріоритет — там, де можна втратити гроші чи дані:

1. База даних — пароль PostgreSQL/MySQL. Якщо БД зовнішня (Neon, Supabase тощо), змінюйте одразу.
2. AI-провайдери — OpenRouter, OpenAI, Anthropic тощо, навіть ключі, які ще не відключили.
3. Сховища й медіа — S3, Cloudinary, R2.
4. Пошта — SMTP, SendGrid, Resend.
5. Секрети застосунку — JWT, сесійні ключі, OAuth client secret.
6. Приватні registry — Docker Hub, GHCR.

2. Перевірте логи на чужу активність

• AI-провайдери: сторінка Activity/Usage — незнайомі моделі, нетипові обсяги, запити вночі.
• БД: підключення з незнайомих IP.
• Хмарні сховища: несподівані завантаження чи видалення.

3. Підготуйте нові значення заздалегідь

Згенеруйте нові ключі зараз, збережіть їх у менеджері паролів і впишіть у Variables. Вони застосуються після першого деплою, коли Railway зніме паузу. Після відновлення, ймовірно, знадобиться ручний редеплой.

4. Остерігайтеся фішингу

На хвилі таких новин завжди з'являються підроблені листи «від Railway» чи «від OpenRouter». Заходьте в дашборди напряму, а не за посиланнями з листів.

Нюанс: база даних на тому ж Railway

Якщо змінити пароль БД зараз, застосунок втратить з'єднання, доки ви не задеплоїте новий пароль, а деплої заблоковані. Вибір такий: короткий простій або ризик, що базою скористається хтось інший. Якщо в базі є дані користувачів — краще ротувати одразу.

Як організувати зберігання секретів так, щоб наступний подібний інцидент коштував мінімум часу й грошей, — у нашому гайді «Секрети в SaaS: зберігання, ротація та план дій при витоку».

🎯 Розділ 7. Що поки невідомо

• Скільки саме акаунтів постраждало.
• Як саме зловмисник отримав доступ до систем зі змінними.
• Коли відновлять деплої — Railway терміну не називає.

Оновлення компанія публікує на status.railway.com.

❓ Часті питання (FAQ)

Мій сервіс на Railway працює. Мене це стосується?

Запущені сервіси працюють, заблоковані лише нові деплої. Але якщо ваші секрети зберігалися у змінних Railway, ротувати їх варто в будь-якому разі — так радить сама компанія всім користувачам.

Чому мій застосунок раптом отримує 401 від OpenRouter?

Найімовірніше, OpenRouter превентивно відключив ключ, що зберігався в Railway. Перевірте сторінку ключів в акаунті OpenRouter і пошту. Відключений ключ не відновлюється — потрібен новий.

Чому замість 401 з'явилася помилка 402 Payment Required?

Якщо баланс у вашому акаунті OpenRouter позитивний, а застосунок досі працює зі старим ключем, 402 найімовірніше теж пов'язана з відкликаним ключем, а не з оплатою. Перевірте новий ключ локально: якщо він працює, проблема зникне після деплою з новим значенням.

Я змінив змінну в Railway, але нічого не змінилося. Чому?

Змінні оточення застосовуються лише під час деплою чи перезапуску контейнера. Поки деплої на паузі, працює стара версія зі старими значеннями.

Чи можна вставити новий ключ просто в код?

Ні: зміна коду так само потребує деплою. А ключ у репозиторії — окремий ризик: OpenRouter та інші провайдери автоматично відкликають ключі, знайдені на GitHub.

Джерело: Railway — Security Disclosure: Wednesday October 21st