Для кого: разработчики и операторы, которые запускают приложения или базы данных на Railway, платформе хостинга приложений (PaaS), особенно те, кто хранит в переменных окружения API-ключи ИИ, платёжные данные, учётные данные GitHub, облака или баз данных.
Статья основана на официальных публикациях блога Railway (сообщение о раскрытии, предварительный отчёт и руководства для пользователей) и на её странице статуса. Методы атаки в ней не рассматриваются: компания их тоже не раскрывала.
Ситуация развивается: статья будет обновляться по мере новых публикаций организации
По состоянию на 11:00 UTC, 24 октября 2026 года (20:00 JST)Пока неизвестно
- Какие переменные окружения были расшифрованы (компания заявляет, что не может их определить)
- Был ли доступ к исходному коду (будет подтверждено в итоговом отчёте)
- Подробности атаки
- Использовались ли раскрытые ключи
Предварительный отчёт компании датирован 22 октября; по данным страницы статуса, он опубликован в 16:38 UTC 23 октября. Компания заявляет, что расследование продолжается и что она опубликует дополнение после его завершения. Дата итогового отчёта не указана.
Страница статуса отметила инцидент как решённый в 22:06 UTC 23 октября; сборки и развёртывания работают в обычном режиме. Новые регистрации по-прежнему приостановлены.
Что пользователям Railway делать сегодня
Шаги 1 и 2 касаются всех пользователей. Компания говорит, что воздействие может быть ограниченным, но в качестве меры предосторожности рекомендует эти действия всем.
Замените секреты: перевыпустите у источника и отзовите старые значения
Компания просит отозвать и заново задать все чувствительные переменные окружения, сохранённые на Railway до 21 октября. Сюда входят API-ключи и учётные данные частных реестров.
Действуйте в таком порядке:
- Составьте список переменных окружения. Откройте вкладку Variables каждого сервиса и отметьте секретные значения (API-ключи, токены, пароли, ключи подписи, строки подключения)
- Выпустите новые значения в панели управления каждого источника: API ИИ, платёжный провайдер, GitHub, облако, внешние базы данных и т. д.
- Обновите переменные Railway и повторно разверните сервисы. Контейнеры читают переменные только при запуске, поэтому до повторного развёртывания они продолжают работать со старыми значениями (руководство компании)
- Когда новые значения заработают, отзовите или удалите старые значения у источника
Если изменить значение только внутри Railway, раскрытое значение останется рабочим, пока вы не отзовёте его у источника (примечание сайта).
Если вы меняли секреты до 03:32 UTC 22 октября
В сообщении от 21 октября компания просила пользователей немедленно заменить все переменные окружения. Позже она сообщила, что в 03:32 UTC 22 октября подтвердила: у атакующего больше нет доступа к её системам. В предварительном отчёте объясняется, что компания хотела сначала вытеснить атакующего, а уже потом просить пользователей менять секреты, чтобы новые учётные данные не были сразу скомпрометированы снова. Поэтому секреты, заменённые до 03:32 UTC 22 октября, безопаснее заменить ещё раз (примечание сайта). Страница статуса сообщает, что одно это обновление не требует повторять замены, уже выполненные с момента локализации инцидента.
Базы данных: сгенерируйте пароли заново и закройте публичный доступ
Компания советует всем пользователям закрыть публичный сетевой доступ к базам данных. В её руководстве сказано, что к базе данных с включённым публичным доступом (TCP-прокси) можно подключиться с её учётными данными из любой точки интернета, пока вы не смените их.
- Для PostgreSQL, MySQL, Redis и MongoDB используйте Regenerate в представлении базы данных. Это за один шаг меняет пароль внутри базы и переменные и сбрасывает открытые сеансы (руководство компании)
- Не редактируйте вручную переменные с паролями, такие как POSTGRES_PASSWORD, и не меняйте пароль напрямую в базе. Переменная и база перестанут совпадать (руководство компании)
- Повторно разверните каждый сервис, который ссылается на эти переменные (например,
${{ Postgres.DATABASE_URL }}). Вставленные вручную строки подключения замените ссылками - В разделе Settings, Networking отключите Public Access, если он не нужен ничему вне проекта. Всё внешнее (локальная разработка, CI, BI-инструменты) потребует вручную вставить новый
DATABASE_PUBLIC_URL
GitHub и реестры: проверьте журналы аудита и подключённые приложения
Компания рекомендует проверить журналы аудита GitHub и доступ приложений, а также журналы аудита реестров, таких как Docker Hub. В её руководстве приведены такие проверки:
- Личная учётная запись: журнал безопасности GitHub (90 дней), авторизованные приложения OAuth и GitHub Apps, ключи SSH и GPG, персональные токены доступа. Отзовите всё незнакомое и создайте токены заново
- Организация: журнал аудита организации (180 дней). Экспортируйте журнал, прежде чем что-либо отзывать. По каждому репозиторию проверьте deploy keys, секреты, вебхуки и соавторов
- GitHub Container Registry (ghcr.io): Railway удалила сохранённые у неё токены GitHub, но эти токены продолжают работать на GitHub, пока не будут отозваны. Удалите старый токен на GitHub, создайте новый с областью read:packages и задайте его в каждом сервисе
В руководстве также предупреждается, что атакующий с правом push может добавить вебхук или секрет, который переживёт сброс пароля.
API ИИ и платежи: ищите использование и списания, которых вы не совершали
Согласно предварительному отчёту компании, атакующий, по-видимому, искал API-ключи поставщиков ИИ. Компания опубликовала руководства по проверке использования для OpenAI, Anthropic, OpenRouter, Grok, Stripe, AWS и GCP. Например, в руководстве по OpenAI предлагается:
- Удалить возможно раскрытый ключ и создать новый в том же проекте
- Открыть статистику использования, сгруппировать по API-ключу и сравнить объём токенов, число запросов и набор моделей в период раскрытия с обычным трафиком
- Проверить в биллинге расходы за период и использованные кредиты
- Проверить участников и состав проекта на наличие людей, которых вы не приглашали
- Сохранить данные об использовании и обратиться в поддержку поставщика, если обнаружите злоупотребление
Проверяйте как минимум период от начала окна атаки (13:58 UTC 20 октября) до момента, когда вы заменили ключ (примечание сайта).
Внутри Railway: войдите заново, создайте токены и разверните повторно
В ходе реагирования компания отозвала все сеансы входа, токены доступа Railway, подключения GitHub и учётные данные хранилищ (buckets). Коммиты, отправленные во время приостановки развёртываний, развёрнуты не были.
- Входите с тем же аккаунтом Gmail, GitHub или адресом электронной почты, с которым регистрировались. Вход с другой учётной записью создаёт новый пустой аккаунт (руководство компании)
- Заново подключите GitHub в настройках аккаунта, заново подключите репозиторий в Settings сервиса и разверните последний коммит
- CLI: выполните
railway logout, затемrailway login. CI: заново создайте токен проекта (RAILWAY_TOKEN) или токен аккаунта/рабочего пространства (RAILWAY_API_TOKEN) и замените его в секретах CI - Повторно разверните сервисы, использующие хранилища, чтобы они получили новые учётные данные. Также проверьте хранилища на файлы, которые вы не загружали, и удаления, которых вы не делали (автоматических резервных копий у хранилищ нет, говорит компания)
- В журнале аудита рабочего пространства найдите чтения переменных, изменения учётных данных реестров и развёртывания в период раскрытия, которые выполнила не ваша команда и не Railway (отображается как "Railway Staff")
Секрет, сохранённый на Railway до 21 октября
Считать раскрытым, связывались с вами или нет
↓→
1. Выпустить новое значение у источника
Обновить переменную и развернуть повторно, затем отозвать старое значение
База данных с публичным доступом
Доступна из интернета с утёкшим паролем
↓→
2. Сгенерировать пароль заново и закрыть публичный доступ
Повторно развернуть каждый сервис, который на неё ссылается
API ИИ, платежи, GitHub
Ключи, которые, по-видимому, искал атакующий
↓→
3. Проверить использование, списания и журналы аудита
С 13:58 UTC 20 окт. до момента замены
Осторожнее с сообщениями от имени поддержки Railway
Компания заявляет, что будет писать затронутым клиентам напрямую по электронной почте. В её руководстве по восстановлению доступа сказано не отправлять в поддержку пароли, коды входа, коды восстановления, API-токены и значения секретов. Если сообщение, связанное с этим инцидентом, просит значения секретов или коды входа, считайте, что оно поддельное (примечание сайта).
Уведомления об отзыве от GitHub, OpenAI и других поставщиков приходят по запросу Railway, и компания говорит, что они не означают, что ваши учётные данные были затронуты. Не переходите по ссылкам в таких сообщениях; открывайте панель каждого поставщика напрямую.
Что произошло (по данным Railway)
Ниже изложено на основе публикаций в блоге Railway "Security Disclosure: Wednesday October 21st" (21 октября 2026 года) и "Preliminary Report: Oct 21st Security Incident" (датирована 22 октября; по данным страницы статуса, опубликована в 16:38 UTC 23 октября), а также страницы статуса. Время указано в UTC.
20 окт., 13:58
Мониторинг фиксирует аномальную активность в виде повышенной задержки; дежурный инженер начинает расследование.20 окт., 14:03–16:51
Активность определена как попытка повышения привилегий враждебной внешней стороной. В инфраструктуре сборки обнаружена возможность повышения привилегий, конвейеры сборки остановлены.20 окт., 18:05–19:53
Меры защиты внедрены, эксплойт больше не воспроизводится. В 19:53 появляются новые свидетельства того, что атакующий мог повышать доступ в большем масштабе сразу в нескольких частях системы параллельно.21 окт., 04:24–05:23
Криминалистический анализ показывает, что атакующий вытянул секреты в зашифрованном виде, не имея на тот момент возможности их расшифровать.21 окт., 05:27–07:25
Атакующий получает учётные данные среды CI и расшифровывает артефакты, дающие дополнительный API-доступ.21 окт., 07:25–09:18
Данные базы показывают неавторизованный запрос зашифрованных переменных окружения; часть была расшифрована с использованием сочетания скомпрометированных учётных данных.21 окт., 09:25
Railway уведомляет поставщиков о поверхностях, к которым получил доступ атакующий, и просит отозвать ключи (в FAQ отчёта указано 09:35).21 окт., 20:19–22:10
Railway объявляет о сбросе пользовательских сеансов и публикует сообщение о безопасности и рекомендации для клиентов.22 окт., 03:32
Railway подтверждает, что у атакующего больше нет доступа ни к каким внутренним системам, и начинает повторную инициализацию внутренних систем с новыми учётными данными.22 окт., 17:00–22:49
Сообщается о полном восстановлении API и нормальных развёртываниях для всех тарифов.23 окт., 16:38
Предварительный отчёт, датированный 22 октября, опубликован (страница статуса).23 окт., 18:57
Уведомление рабочих пространств, оценённых как более рискованные, завершено (страница статуса).23 окт., 22:06
Страница статуса отмечает инцидент как решённый. Новые регистрации по-прежнему приостановлены.
- Что произошло
- Неавторизованная третья сторона получила доступ к внутренним системам, получила зашифрованные переменные окружения клиентов и расшифровала их часть
- Масштаб
- Не более 1,85% всех рабочих пространств (около 100 000 рабочих пространств) имели переменные окружения, часть из которых могла быть скомпрометирована. По одним записям запросов нельзя определить, какие именно переменные затронуты, поскольку ключи были зашифрованы по схеме конвертного шифрования (ключ, шифрующий данные, сам зашифрован другим ключом), сообщает компания
- Цель атакующего (оценка компании)
- Получить API-ключи поставщиков ИИ для «дистилляции» моделей (обучения другой модели на ответах модели; пояснение сайта). Компания считает, что это часть серии атак на платформенные компании с целью скомпрометировать поставщиков ИИ-инференса
- Среды повышенного риска
- Рабочие пространства с очень большим числом переменных окружения и среды с большим числом ключей поставщиков ИИ
- Заявлено как не затронутое
- В учётные записи пользователей Railway входов не было
- Пока не подтверждено
- Доступ к исходному коду не исключён и будет подтверждён в итоговом отчёте
- Уведомления поставщиков
- Railway уведомила GitHub, GitLab, Anthropic, OpenAI, OpenRouter, Google, Stripe и других о потенциально расшифрованных ключах и попросила их отозвать. Некоторым поставщикам она передала все ключи, зарегистрированные на платформе, независимо от известного воздействия. Запросы поставщиков на сброс затронули более 100 000 пользователей
- Влияние на сервисы
- Работающие сервисы оставались в сети. Новые сборки и развёртывания, панель управления, API, CLI и поддержка временами были недоступны
- Действия компании
- Отключила потенциально скомпрометированные внутренние инструменты; заменила все ключи и заменила их повторно после проверки, что злоумышленник удалён; привлекла внешнюю криминалистическую компанию; перевела сборщики в однопользовательские (single-tenant) среды; заменила учётные данные всех хранилищ; пересобрала внутренние инструменты из проверенного исходного кода; добавила способ массово отзывать разрешения приложений Railway
Что известно и что неизвестно
Состояние на 24 октября 2026 года. Таблица будет обновляться по мере новых публикаций компании.
| Пункт | Что раскрыто | Статус |
|---|---|---|
| Получены зашифрованные переменные окружения | Получены через неавторизованный запрос | Подтверждено (компания) |
| Расшифровка | Часть расшифрована с использованием сочетания скомпрометированных учётных данных | Подтверждено (компания) |
| Рабочие пространства в зоне воздействия | Не более 1,85% всех рабочих пространств (около 100 000) | Возможно (компания) |
| Какие переменные расшифрованы | Нельзя определить по одним записям запросов | Расследуется |
| Учётные данные частных реестров | Указаны для замены | Возможно (компания) |
| Учётные записи пользователей | Атакующий не получал доступ к учётным записям пользователей Railway | Опровергнуто (компания) |
| Исходный код | Доступ не исключён; будет подтверждён в итоговом отчёте | Расследуется |
| Работающие сервисы | Оставались в сети | Подтверждено (компания) |
| Окно атаки | С 13:58 UTC 20 окт. до 03:32 UTC 22 окт. | Подтверждено (компания) |
| Подробности атаки | Не раскрыты, чтобы защитить клиентов | Расследуется |
| Злоупотребление раскрытыми ключами | Не заявлено | Не заявлено |
| Время уведомления поставщиков | 09:25 UTC в хронологии отчёта, 09:35 UTC в его FAQ | Расхождение в отчёте |
Как читать цифры: что означают 100 000
Цифра «около 100 000» в предварительном отчёте — это число рабочих пространств (1,85% от всех), у которых некоторые переменные окружения могли быть скомпрометированы. В отчёте сказано, что запросы поставщиков на отзыв затронули более 100 000 пользователей и что число клиентов, с которыми компания связалась как с группой высокого риска, превышает эти 1,85%. Само по себе обращение к вам или отзыв ключа не подтверждает раскрытие. И наоборот, компания говорит, что рабочие пространства вне групп повышенного риска не считаются подтверждённо безопасными.
Почему целью становятся API-ключи ИИ
Далее изложено в общем виде и не означает, что всё это произошло в данном инциденте. Цель этого атакующего, по описанию компании, — получить API-ключи ИИ для дистилляции моделей.
API-ключ ИИ — это деньги и вычислительные ресурсы, которые может потратить любой, у кого он есть. Если украденный ключ активно используют, счёт приходит его владельцу. Если под именем владельца собирают большие объёмы выходных данных, поставщик может заблокировать аккаунт за нарушение правил, например запрета на дистилляцию. Как это работает и как оспорить блокировку, рассказано в материале почему аккаунт блокируют после кражи API-ключа.
Платформа хостинга хранит ключи многих клиентов в одном месте. Вероятно, поэтому компания считает рабочие пространства с множеством переменных окружения или множеством ключей ИИ более рискованными. В том же месяце разработчик LiteLLM также заявил, что атакующий в его инциденте в основном искал ключи поставщиков LLM (это отдельный инцидент; связь между ними не раскрыта). Более широкую картину атак с использованием ИИ или нацеленных на ключи ИИ см. в материале защита от кибератак с использованием ИИ.
Что пользователям Railway стоит пересмотреть: выводы из раскрытых фактов
Этот раздел не оценивает действия компании. Он посвящён тому, что пользователи могут сделать, чтобы подготовиться к следующему инциденту, исходя из раскрытых фактов.
Исходите из того, что шифрование на стороне платформы не защищает при компрометации самой платформы
Переменные окружения Railway были зашифрованы, но, согласно предварительному отчёту, атакующий расшифровал часть из них, используя сочетание скомпрометированных учётных данных. Чтобы запустить ваше приложение, платформа хостинга должна превращать переменные обратно в открытые значения, поэтому после захвата привилегий внутри платформы одно шифрование не может полностью их защитить (примечание сайта).
Помимо шифрования на платформе, храните секреты так, чтобы утечка наносила ограниченный ущерб. Первый шаг — установить лимиты расходов и оповещения у поставщиков API ИИ и платёжных систем. Отдельные ключи для продакшена, тестовой и среды разработки также сокращают объём замены. О хранении секретов рассказано в материале что на самом деле опасно в .env и API-ключах.
Не выставляйте базы данных в публичный интернет
Согласно руководству компании, к базе данных с включённым публичным доступом можно подключиться из любой точки интернета с утёкшей строкой подключения. База данных, используемая только по частной сети проекта, недоступна напрямую снаружи, даже если строка подключения утекла.
Внешний доступ обычно нужен только для локальной разработки, CI или BI-инструментов. Но и тогда стоит рассмотреть возможность открывать его только на время необходимости или использовать отдельного пользователя только для чтения (примечание сайта).
Передавайте секреты через ссылки, чтобы замена выполнялась в одном месте
Руководство компании рекомендует передавать строки подключения и ключи через ссылочные переменные, такие как ${{ Postgres.DATABASE_URL }}, а не вставлять их в каждый сервис. При использовании ссылок изменение исходного значения и повторное развёртывание доходят до каждого сервиса, и ни одна вставленная копия не забывается.
В том же духе ведите актуальный список того, какой секрет использует каждый сервис и где он перевыпускается (примечание сайта). Когда нужно заменить всё сразу, как сейчас, от этого списка зависит, сколько займёт работа. В похожем случае, инциденте безопасности Vercel, важно было, хранились ли секреты в категории, значения которой нельзя потом отобразить.
Ограничивайте подключения GitHub нужными репозиториями и областями доступа
В этом инциденте компания отозвала хранившиеся у неё токены GitHub и рекомендует проверить журналы аудита GitHub и доступ приложений. Ограничьте доступ GitHub, который вы даёте платформе хостинга, репозиториями, которые она развёртывает, а токенам реестра контейнеров давайте только доступ на чтение (read:packages), чтобы утечка затрагивала меньше (примечание сайта). Проблема утёкших учётных данных, остающихся действующими, рассмотрена в материале утёкшие учётные данные, которые остаются действующими.
Источники (открытые данные)
Факты в этой статье основаны на следующих открытых источниках. Подробности атаки не воспроизводятся.
- Railway, "Security Disclosure: Wednesday October 21st" (21 октября 2026 года; страница статуса опубликовала "We have published a security notice" в 22:10 UTC 21 октября) — blog.railway.com
- Railway, "Preliminary Report: Oct 21st Security Incident" (датирован 22 октября 2026 года; по данным страницы статуса, опубликован в 16:38 UTC 23 октября) — blog.railway.com
- Railway, "Railway Platform Outage" (страница статуса, проверена до обновления "Resolved" в 22:06 UTC 23 октября) — status.railway.com
- Руководства для пользователей Railway (22–23 октября 2026 года): "Rotate PostgreSQL Database Credentials" blog.railway.com / "Check for Anomalous GitHub Access" blog.railway.com / "Check for Unexpected OpenAI Usage" blog.railway.com / "Redeploy Buckets and Reconnect GitHub After the Credential Reset" blog.railway.com / "Recover Failing Deploys" blog.railway.com / "Resolving Login Issues" blog.railway.com
- Руководства по другим сервисам (MySQL, Redis, MongoDB, Anthropic, OpenRouter, Grok, Stripe, AWS, GCP) перечислены в инженерном блоге компании — blog.railway.com
История обновлений
2026-10-24: первая версия на основе сообщения Railway о раскрытии (21 октября), предварительного отчёта (22 октября) и страницы статуса (до обновления в 22:06 UTC 23 октября). В тот же день исправлена после сверки с источниками: время публикации предварительного отчёта теперь соответствует странице статуса (16:38 UTC, 23 октября), а статус доступа к учётным записям пользователей теперь «Опровергнуто (компания)». Объём расшифровки и сведения о доступе к исходному коду будут добавлены после публикации итогового отчёта.
Читайте также
- Похожие инциденты: что делать разработчикам после инцидента безопасности Vercel / компрометация LiteLLM 1.107.0
- Почему целью становятся ключи ИИ: защита от кибератак с использованием ИИ / украденные API-ключи и блокировка аккаунтов
- Хранение секретов: что на самом деле опасно в .env и API-ключах / API-ключи, утёкшие из кода, написанного ИИ
- Другие инциденты 2026 года: список утечек данных и кибератак