Утечка ключей Railway после октябрьской атаки уже обернулась примерно $740 тыс. несанкционированных расходов на AI-сервисы. PaaS-платформа пообещала оплатить спорные счета сама, если провайдеры моделей не вернут деньги клиентам. Для разработчиков это неприятное напоминание: переменная окружения с API-ключом — не просто удобная настройка деплоя, а фактически платёжный инструмент с доступом к чужому бюджету.
Атакующие получили доступ к ключам AI-провайдеров, которые пользователи Railway хранили в environment variables, сообщает The Hacker News. По данным компании, злоумышленник сумел расшифровать переменные максимум в 1,85% рабочих пространств — это верхняя оценка примерно для 100 тыс. workspaces. Логи Railway позволяют определить затронутые окружения, но не дают точного перечня расшифрованных переменных. Поэтому фактический масштаб компрометации может быть меньше.
Интерес преступников был вполне прикладным: в запросах к базе они искали ключи AI-провайдеров. Такие ключи можно быстро превратить в оплаченные чужим счётом запросы к моделям, а затем использовать доступ в сервисах-посредниках или для перепродажи. Railway полагает, что украденные учётные данные могли применяться в инфраструктуре, которая переправляет или перепродаёт доступ к AI для задач дистилляции. При этом компания не утверждает, что сама группа взломщиков управляла этими сервисами.
Помимо AI-ключей атакующий искал данные облачных сервисов, баз данных и платёжных систем. Railway заявляет, что расследование не нашло признаков доступа к клиентским базам данных или выгрузки репозиториев пользователей. Были затронуты токены связанных аккаунтов 1852 пользователей: ключи BYOK-агентов и GitHub OAuth-токены. Их сбросили, владельцев уведомили; признаков входа в клиентские аккаунты с украденными реквизитами компания не обнаружила. Отдельно злоумышленник прочитал истории 353 сборок, куда могли попадать переданные на этапе build переменные и секреты.
Как одна учётная запись дошла до ключей клиентов
Атака началась 20 октября в системе сборок. В 07:28 UTC злоумышленник использовал неизвестную на тот момент уязвимость и частично вышел за пределы файловой изоляции build-окружения, получив доступ к файлам на хостовой виртуальной машине. Там он нашёл учётные данные, которыми build-серверы отправляют готовые образы в реестр и обращаются к части внутренних систем. Первый сигнал сработал только в 13:58 UTC: мониторинг заметил необычные обращения к сервису реестра.
Дальше сработала классическая цепочка из лишних доверительных связей. Внутренняя система Temporal приняла build-credential как доверенный клиент, хотя этот реквизит предназначался лишь для сборки. Через неё атакующий прочитал истории других сборок и получил кэшированные снимки кода, включая внутренний монорепозиторий Railway. Изучив устройство платформы, он обнаружил неверно настроенную OIDC-привязку в одном из облачных окружений и 21 октября в 03:26 UTC получил короткоживущие облачные учётные данные.
Эти права позволили добыть ещё два секрета: один давал возможность читать зашифрованные переменные из production-базы внутри внутренней сети, второй был SSH-ключом к машине оркестрации. На ней находились реквизиты, нужные для расшифровки переменных при запуске клиентских нагрузок. Railway шифрует переменные каждого окружения отдельным ключом, а эти ключи защищены корневым ключом в KMS облачного провайдера. Между 04:07 и 07:15 UTC 21 октября атакующий выбирал зашифрованные переменные с именами, похожими на ключи AI-сервисов, и расшифровывал часть из них. Полностью удалить злоумышленника из систем удалось к 09:24 UTC.
Кто вернёт деньги и что делать командам
Условия компенсации зависят от поставщика модели. AWS Bedrock и Google Gemini, по данным Railway, уже применяют свои политики возмещения мошеннических расходов. OpenAI и SpaceXSI рассматривают обращения индивидуально: клиенту нужно завести кейс у провайдера и передать его номер в поддержку Railway. Переговоры с Anthropic продолжаются, а расходы по ключам Anthropic платформа обещает закрывать до их завершения. OpenRouter, чьи правила не предусматривают возвратов, Railway намерена компенсировать полностью в пределах ущерба от инцидента. Компания не раскрыла методику оценки $740 тыс., период расчёта, дедлайн подачи заявлений и лимит выплат.
Практический вывод для команд шире конкретной утечки ключей Railway. Все чувствительные переменные, сохранённые на платформе до 21 октября, стоит отозвать и выпустить заново у исходного провайдера: отправка отчёта о расходах сама по себе ключ не отключает. Стоит также убрать публичный сетевой доступ к базам данных, проверить журналы аудита GitHub и список приложений с доступом к организации, а также логи контейнерных реестров. Railway перевела сборки на отдельные короткоживущие виртуальные машины и сузила права build-credentials до отправки одного конкретного образа, но архитектурный урок остаётся прежним: секреты нужно проектировать как потенциально похищаемые, с коротким сроком жизни, минимальными правами и расходными лимитами.
Wiz включила Railway в список как минимум девяти AI-платформ для разработчиков, раскрывших инциденты в октябре. Общая деталь этих случаев — охота за переменными окружения, особенно за доступом к AI-сервисам, а не единая уязвимость или библиотека. Если API-ключ одновременно открывает доступ к модели и не ограничен бюджетом, его компрометация превращается из обычного security-инцидента в счёт, который растёт быстрее, чем команда успевает прочитать уведомление. Детали расследования Railway собраны в материале .
