Компрометация LiteLLM 1.107.0 в PyPI: кража учётных данных через Python startup hooks

21 октября 2026 года скомпрометированный релиз LiteLLM 1.107.0 был опубликован в Python Package Index (PyPI) и распространён через официальные контейнерные образы. Особенность атаки в том, что вредоносный код запускался при обычной инициализации интерпретатора Python: приложению не нужно было импортировать LiteLLM — достаточно было запустить Python в затронутом окружении. Это существенно расширяет периметр компрометации и меняет подход к реагированию.

Подробности

LiteLLM обычно развёртывается как шлюз между приложениями и провайдерами моделей. В этой роли он может иметь доступ к API-ключам провайдеров моделей, строкам подключения к базам данных, workload-идентичностям, конфигурации маршрутизации и данным политик тенантов. Тот же пакет используется на рабочих станциях разработчиков, сборочных агентах, тестовых системах и в контейнерах — что и расширило набор потенциально затронутых сред.

По данным мейнтейнеров LiteLLM, украденные учётные данные разработчика GitHub были использованы для изменения процесса релиза с перенаправлением на похожий репозиторий Berri-AI/litellm вместо легитимного BerriAI/litellm. Затем учётная запись другого разработчика была использована для прохождения шага production-одобрения. Microsoft не устанавливала независимо, как именно атакующий первоначально получил доступ к upstream-среде и этим учётным данным.

Microsoft проанализировала два пути исполнения в затронутых wheel-пакетах: сборщик учётных данных, запускаемый через path extension, и Unix-ориентированный загрузчик, закреплённый через site-specific конфигурацию. Сборщик нацеливался на аутентификационные материалы в инструментах разработки, AI-приложениях, облачных средах, браузерах и инфраструктуре. Отдельный модуль для работы с базой данных пытался читать отдельные записи с учётными данными и конфигурацией моделей из прокси LiteLLM.

Наблюдения на конечных точках Windows и macOS совпали с поведением обнаруженного сборщика: разведка окружения, шифрование и исходящие подключения. В одном примере на Windows обычный вызов Python для установки несвязанной зависимости активировал сборщик. Поэтому не следует запускать Python или pip внутри подозрительного окружения для проверки наличия вредоносного пакета — это может привести к исполнению payload.

Что делать

Удаления пакета или релизного тега недостаточно для восстановления. Необходимо обработать затронутое окружение Python, все сохранившиеся процессы и учётные данные, доступные скомпрометированной идентичности.

Рекомендуется: не запускать Python и pip в подозрительных средах — проводить проверку средствами EDR и анализом файловой системы; выявлять окружения, где устанавливался LiteLLM 1.107.0, включая контейнерные образы и сборочные агенты; завершать подозрительные процессы и пересоздавать затронутые окружения с чистого состояния; считать скомпрометированными все секреты, доступные из затронутых систем, — API-ключи провайдеров моделей, токены GitHub, строки подключения к БД, облачные учётные данные — и выполнить их ротацию; проверить журналы исходящих подключений на предмет аномалий, соответствующих поведению сборщика; использовать детектирование Microsoft Defender и запросы advanced hunting, приведённые в исходной публикации, для оценки экспозиции.

Итог: компрометация LiteLLM 1.107.0 демонстрирует, что механизмы автозапуска Python превращают заражение зависимости в компрометацию всего окружения. Ключевой приоритет при реагировании — ротация всех доступных секретов, а не только удаление пакета.

Источник: Microsoft Security Blog