Инцидент с релизом LiteLLM 1.107.0: как злоумышленники обошли конвейер

Осенью 2026 года популярный open-source шлюз для языковых моделей столкнулся с серьезной угрозой безопасности. В открытый доступ попал зараженный пакет litellm==1.107.0 со стилером учётных данных, а также скомпрометированные образы Docker, что затронуло инфраструктуру многих команд разработки.

Подобные инциденты подчеркивают уязвимость инструментов, управляющих доступом к языковым моделям. Рассмотрим детальную хронологию событий, технические особенности вредоносной нагрузки и выводы для специалистов по безопасности.

Хронология инцидента

Согласно отчетам разработчиков и аналитическим материалам информационной безопасности, атака развивалась стремительно. В утренние часы 21 октября 2026 года злоумышленники смогли обойти механизмы защиты репозитория.

Этапы атаки в таймлайне

Сначала автоматика отклонила несанкционированную правку релизного рабочего процесса, однако вскоре защиту отключили токеном с повышенными привилегиями. В результате была запущена сборка из стороннего репозитория-двойника.

После прохождения формального ручного одобрения вторым скомпрометированным токеном вредоносные wheel-пакеты отправились в реестр PyPI, а следом обновились образы на Docker Hub. Записи о выполнении рабочих процессов были оперативно стерты третьим украденным токеном, но пользователи успели заметить аномалию и поднять тревогу в профильном трекере.

Механизмы атаки на релизный конвейер

Организация выпуска обновлений в проекте была выстроена на высоком уровне: использовались изолированные окружения в приватном репозитории, подпись образов и официальные издатели. Тем не менее, атака оказалась успешной из-за человеческого фактора и временных привилегий.

Ключевые уязвимости процесса

Накануне инцидента инженерам временно расширили права для публикации срочных исправлений. У злоумышленников оказались OAuth-токены GitHub CLI сразу нескольких разработчиков, включая владельца организации. Это позволило обойти защиту веток, подменить источник сборки и выпустить подписанные артефакты, которые внешне выглядели абсолютно легитимно.

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

Что делала вредоносная нагрузка

Установленный пакет активировался автоматически при любом старте интерпретатора благодаря специальным файлам конфигурации путей и модулям автозапуска. Для запуска вредоносного кода не требовалось даже явного импорта библиотеки в проект.

Сбор конфиденциальных данных

Скрипт собирал широкий спектр информации на зараженном хосте:

• системные пароли, файлы cookie и историю веб-браузеров;
• учетные данные облачных провайдеров AWS, Azure, Google Cloud, а также Kubernetes и Docker;
• секретные ключи инфраструктурных платформ Vault, Jenkins и Terraform;
• переменные окружения запущенных процессов и токены средств разработки;
• при наличии параметра базы данных шлюза — всю ее структуру целиком с ключами вендоров и главным мастер-ключом.

Собранные данные шифровались комбинированным алгоритмом и передавались методом HTTP POST на сторонний домен. На Unix-системах дополнительно разворачивался фоновый демон, который периодически проверял удаленный репозиторий для выполнения последующих команд.

Диагностика заражения и меры защиты

Под удар попали все хосты и конвейеры непрерывной интеграции, где пакет устанавливался в определенный временной интервал, а также контейнеры с плавающими тегами. Проверку систем следует проводить через поиск характерных артефактных файлов, записей в логах и контроль сетевого трафика.

Практические рекомендации

Эксперты рекомендуют полностью пересобирать скомпрометированные окружения с нуля, а не пытаться удалить отдельные файлы. Необходимо зафиксировать версии зависимостей по точным хэшам, заблокировать нежелательные сетевые адреса и полностью сменить все доступы, к которым зараженный узел мог иметь отношение.