Разбор инцидента LiteLLM 1.107.0: взлом релизного конвейера за 1,5 часа, подпись не спасла

21 октября 2026 года на PyPI (главный репозиторий пакетов Python) появилась версия litellm==1.107.0 со встроенным стилером учётных данных. Заражёнными оказались и образы Docker с тем же тегом. По данным отчёта BerriAI (разработчик LiteLLM), заражённый пакет пролежал на PyPI около 1 часа 45 минут, а образы Docker Hub под плавающими тегами были доступны около 2 часов 30 минут. Для LiteLLM это второй подобный случай за год: в марте 2026 были скомпрометированы версии 1.82.7 и 1.82.8.

Ниже разбираю инцидент пошагово: как проверить, затронуты ли вы, и что делать прямо сейчас. Факты взяты из отчёта BerriAI (обновление 21.10, 20:30 UTC), разборов StepSecurity, Wiz и Socket.

Что понадобится

• Доступ к серверам и CI-раннерам (средам автоматической сборки), где установлен LiteLLM
• Терминал с правами на чтение файловой системы и просмотр Docker-образов
• Доступ к DNS-настройкам или сетевому фильтру на выходе из сети
• Около 30 минут на проверку одного хоста, плюс время на ротацию ключей по числу сервисов

Как атака прошла через защиту?

После мартовского инцидента BerriAI перестроила выпуск релизов. Появились:

• Релизный кандидат, тесты, сборка артефактов в приватном репозитории, повторные тесты
• Публикация через Trusted Publishers (механизм PyPI, который привязывает публикацию к конкретному репозиторию) с отдельного аккаунта
• Неизменяемые теги Docker для релизов
• Подписанные образы Docker

По оценке авторов разбора, это заметно лучше среднего по опенсорсу. И всё равно атака прошла.

Пошаговая инструкция: проверка и реагирование

1. Не запускайте Python на подозрительном хосте. Стилер срабатывает при любом вызове интерпретатора в заражённом окружении, даже команда pip show litellm запустит вредоносный код заново.

2. Проверьте lock-файлы и зависимости на наличие версии 1.107.0:

grep -rn "litellm.*1\.107\.0" --include="requirements*.txt" --include="*.lock" --include="pyproject.toml" .

1. Найдите файлы стилера в файловой системе:

find / \( -name cook.pth -o -name cook.py -o -name 'cook*.pyc' -o -name 'sitecustomize*.pyc' \
  -o -name 'litellm-1.107.0*' \) 2>/dev/null
ls -l /tmp/remote_code_loader.lock /tmp/.pc_once_* 2>/dev/null

1. Проверьте Docker-образы по дайджесту (уникальному хешу образа):

docker images --digests | grep -i litellm
# заражённый дайджест: sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e

1. Убейте процесс, который держит /tmp/remote_code_loader.lock, и заблокируйте домены litellm.dev и www.litellm.dev на уровне DNS или сетевого фильтра.

2. Пересоберите образы и виртуальные окружения с нуля. Не пытайтесь просто удалить три файла: стилер мог уже выгрузить данные и установить загрузчик второго этапа.

3. Закрепите версию litellm==1.106.2 или используйте образ по дайджесту. Удалите 1.107.0 из внутренних зеркал и реестров.

4. Ротируйте все секреты, к которым хост имел доступ. По данным StepSecurity, стилер собирал пароли и cookies браузеров, SSH-, GPG- и TLS-ключи, учётные данные AWS, Azure, gcloud, Kubernetes, Docker, GitHub, реестров пакетов, файлы .env, секреты CI-инфраструктуры (Vault, Jenkins, Terraform), конфигурации и токены более 20 ИИ-инструментов для разработки, а при заданном DATABASE_URL выгружал базу прокси LiteLLM целиком.

5. Проверьте сетевые логи на предмет запросов к litellm.dev. Запрос на путь /codepy означает, что выполнялся второй этап атаки. Но отсутствие следов не доказывает чистоту хоста, потому что архив с украденными данными шифровался AES-256-CBC и уходил обычным HTTP POST.

Пять шагов атакующего: почему подпись не помогла

Атака заняла полтора часа и прошла так.

• Окно расширенных прав. За день до атаки двум инженерам временно выдали права на публикацию, чтобы выпустить бэкпорты исправлений.
• Три набора токенов. У атакующего были OAuth-токены GitHub CLI трёх разработчиков. Одним он запустил workflow (скрипт автоматической сборки), вторым прошёл шаг ручного одобрения, третьим стёр записи о запусках.
• Обход защиты веток. Первая попытка правки релизного workflow была отклонена. Через пять секунд токеном владельца организации защиту отключили и принудительно запушили изменение.
• Подмена источника. Изменённый workflow собирал код не из BerriAI/litellm, а из двойника Berri-AI/litellm, отличающегося одним дефисом.
• Легитимная подпись. Конвейер подписал и опубликовал артефакты штатным образом. Проверка подписи показала бы легитимный релиз.

Официальный тег v1.107.0 в исходном репозитории чистый: артефакты были собраны из чужого кода. Клиентов приватного enterprise-реестра, по словам BerriAI, инцидент не затронул.

По версии BerriAI, атакующий попал во внутренний деплой LiteLLM, открытый в интернет, вероятно через недавно закрытую уязвимость. Этот деплой записывал в логи тела ответов, и в них могли оказаться OAuth-токены GitHub CLI разработчиков. Расследование продолжается.

Что делать прямо сейчас, по ролям

Разработчику и DevOps-инженеру. Проверьте все среды по инструкции выше. Закрепляйте версии зависимостей и Docker-образы по дайджесту, не по плавающим тегам. Если используете LiteLLM, зафиксируйте 1.106.2 до выхода подтверждённо чистой версии.

Руководителю команды и предпринимателю. Инцидент показывает: LLM-шлюз (система, через которую проходят запросы ко всем моделям) это точка концентрации секретов. Один скомпрометированный пакет даёт доступ ко всем подключённым провайдерам. Проведите аудит: какие ключи хранятся в переменных окружения, кто имеет доступ к CI, есть ли мониторинг зависимостей.

Автору Дзена и маркетологу. Если вы работаете с ИИ-инструментами через API и используете Python-обёртки, проверьте, нет ли LiteLLM в цепочке зависимостей ваших инструментов. Многие SaaS-сервисы для работы с нейросетями строят интеграцию поверх LiteLLM.

Пользователям из РФ и СНГ. Из открытых LLM-шлюзов в российском контексте чаще используют прямые SDK провайдеров (YandexGPT SDK, GigaChat API). Если вы подключены к зарубежным моделям через LiteLLM, вся инструкция выше применима полностью.

Инцидент с LiteLLM 1.107.0 напоминает: между «мы внедрили лучшие практики» и «мы в безопасности» лежит пропасть размером в один дефис в названии репозитория. Расследование продолжается, и перед применением рекомендаций стоит свериться с последним обновлением отчёта BerriAI.