Railway повідомила, що в частини розробників відкликали щойно замінені API-ключі: вони помилково потрапили до списку для запобіжного відкликання, переданого постачальникам ШІ. Уточнення від 24 жовтня пояснює тривожну ознаку: черговий недійсний ключ сам по собі не означав, що зловмисник викрав і його заміну. Водночас під час початкового жовтневого інциденту частину збережених секретів справді розкрили, тому незавершена ротація залишається необхідною. [1]
Новий ключ потрапив до наступного списку
Після припинення доступу зловмисника 22 жовтня о 03:32 UTC Railway продовжила узгоджувати відкликання облікових даних з іншими компаніями. 23 жовтня постачальники ШІ попросили ще одну групу потенційно зачеплених ключів. Railway передала її OpenAI та Anthropic, але, за її словами, не могла відфільтрувати ключі за часом додавання на платформу. Через це до списку ненавмисно включили новіші ключі.
Отже, розробник міг замінити облікові дані вже після вторгнення, а потім побачити, що заміна теж перестала працювати. Railway пояснює це надто широким списком для реагування, а не доказом компрометації нового ключа. У повідомленні від 24 жовтня компанія зазначила, що на той момент атака не тривала. 25 жовтня о 06:26 UTC повідомлення позначили як закрите; цей адміністративний статус не скасовує початкового розкриття секретів.
Якщо постачальник справді відкликав ключ, Railway радить створити заміну, оновити відповідну змінну середовища на платформі та повторно розгорнути сервіси, які її використовують. Якщо ключі працюють, а попередню ротацію завершено, це уточнення не вимагає повторювати її. Перевіряти долю конкретного ключа слід у повідомленні постачальника та в його кабінеті.
Як зашифровані змінні стали доступними
Попередній звіт, опублікований 22 жовтня, описує серйознішу послідовність, яка спричинила початкові відкликання. Змінні середовища — це параметри, які застосунок використовує під час роботи; серед них можуть бути API-ключі, паролі баз даних або облікові дані реєстру контейнерів. Застосунок здатен працювати як раніше, навіть коли скопійований ключ уже дає сторонній людині доступ до пов’язаного сервісу. [2]
Хронологія Railway починається з незвичної затримки в роботі систем 20 жовтня. Інженери перевіряли можливе підвищення привілеїв в інфраструктурі збирання, зупинили конвеєри та застосували захисні заходи. Пізніше того дня нові докази показали, що зловмисник може розширювати доступ одразу до кількох частин системи. Перше видиме виправлення не перекрило всіх шляхів.
Уранці 21 жовтня розслідування встановило: зловмисник отримав зашифровані секрети, але спочатку не міг їх розшифрувати. Далі відбувся вирішальний перехід. Доступ до облікових даних середовища безперервної інтеграції (CI) Railway дозволив розшифрувати артефакти з додатковим доступом до API. Компанія також знайшла докази несанкціонованого запиту зашифрованих змінних середовища; поєднання скомпрометованих облікових даних дозволило розшифрувати частину з них.
Шифрування мало значення, проте захист залежав і від відокремлення допоміжних облікових даних від викрадених даних. За словами Railway, сам запит до бази не дозволяє визначити, які саме ключі в зачепленому проєкті чи сервісі розшифрували. Повної механіки експлуатації та остаточного експертного звіту компанія ще не оприлюднила.
Три різні значення слова «постраждалі»
Попередня верхня оцінка Railway — 1,85% робочих просторів, приблизно 100 000, у яких могли скомпрометувати частину змінних. Це оцінка робочих просторів, а не кількості людей; вона не доводить прочитання кожного секрету в кожному з них.
Запобіжне реагування охопило ширше коло. Деяким постачальникам Railway передала всі наявні на платформі ключі їхнього сервісу, зокрема ті, для яких компрометацію не встановили. Компанія також зв’язувалася з клієнтами підвищеного ризику. Тому повідомлення про відкликання, попередження про ризик і підтверджене розкриття облікових даних — різні висновки. Пізніша проблема з новими ключами додатково показує, чому саме відкликання не доводить викрадення.
Railway вважає, що зловмисника цікавили ключі платформ і постачальників ШІ, можливо, для дистиляції моделей. Це попередня інтерпретація намірів з боку компанії. Звіт не встановлює копіювання конкретної моделі та залишає відкритим питання можливого доступу до вихідного коду.
Відновлений сервіс не знешкоджує старий ключ
Railway повідомляє, що вже запущені клієнтські сервіси працювали, поки нові збирання та розгортання були призупинені. Згодом основна сторінка інциденту повідомила про нормальну роботу збирань, розгортань, API та панелі керування. Відновлення сервісу й відновлення безпеки облікових даних — окремі завдання. [3]
Якщо конфіденційні облікові дані зберігалися на Railway до 21 жовтня і ви ще не виконали ротацію, дотримуйтеся початкової рекомендації: відкличте старі дані в сервісах, що їх видали, створіть заміни, оновіть відповідні змінні та повторно розгорніть залежні сервіси. Проста зміна значення в Railway не відкликає скопійований ключ у його постачальника. Перевірте активність пов’язаних сервісів, журнал аудиту GitHub, дозволи застосунків і журнали реєстрів контейнерів. Railway також рекомендує прибрати публічний доступ до баз даних.
Компрометація LiteLLM через запуск Python показує інший шлях до секретів розробника: локальне виконання коду замість вторгнення в інфраструктуру хостингу. В обох випадках відновлений застосунок не робить старі облікові дані безпечними. Для користувачів Railway зараз важливо розрізняти незавершену початкову ротацію та пізніше запобіжне відкликання вже нового ключа.
Джерела
- Railway. «Уточнення: відкликання API-ключів 24 жовтня є запобіжними». 24 жовтня 2026 року, 13:57 UTC; статус оновлено 25 жовтня. Переглянуто 25 жовтня 2026 року. Офіційне уточнення.
- Jacob Cooper, Angelo Saraceno. «Попередній звіт про інцидент безпеки 21 жовтня». Railway, 22 жовтня 2026 року. Попередній звіт.
- Railway. «Збій платформи Railway». Оновлення про відновлення роботи від 23 жовтня 2026 року, 22:06 UTC. Переглянуто 25 жовтня 2026 року. Статус інциденту та рекомендації.
