Согласно текущим сообщениям и материалам исследователей безопасности, LiteLLM 1.107.0 был вредоносным релизом, распространённым 21 октября 2026 года через PyPI и некоторые официальные теги контейнеров. Безопасной версией для отката названа 1.106.2. Тем, кто установил или запускал затронутые артефакты, недостаточно обычного обновления: необходимо изолировать среду, пересобрать её из чистой базы и сменить все доступные учётные данные.

Какие артефакты LiteLLM могли быть скомпрометированы

Текущие сообщения указывают на LiteLLM 1.107.0 как на скомпрометированный релиз; риск, предположительно, распространялся как на пакет в PyPI, так и на официальные контейнерные образы. В представленном предупреждении упоминаются пакеты PyPI и Docker-образы, включая latest и main-stable, тогда как в исследованиях Виз и Айкидо также названы v1.107.0 и main-latest.

Масштаб инцидента важен, поскольку часть пострадавших могла не выбирать версию 1.107.0 напрямую. Команды, использовавшие меняющиеся теги образов, могли получить заражённую сборку в рамках обычного процесса развёртывания, а не вследствие явного обновления версии.

В рамках описанного инцидента наиболее важны следующие сведения:

Сроки очистки в разных каналах, согласно доступным сообщениям, различались. В одном фрагменте GitHub issue, связанном с BerriAI/litellm, говорилось, что PyPI уже был очищен, тогда как плавающие Docker-теги на определённом этапе 21 октября всё ещё оставались заражёнными. Позднее Виз сообщила об удалении этих тегов. Это подтверждает общую картину инцидента, но не позволяет установить единое окончательное время очистки.

Почему описанная вредоносная нагрузка была особенно опасна

По данным ДжейФрог, вредоносный wheel-пакет LiteLLM использовал хук запуска Python. Это позволяло нагрузке выполняться при старте Python в затронутой среде, не дожидаясь прямого импорта LiteLLM приложением. В доступном фрагменте ДжейФрог связывает это поведение с файлом cook.pth, который обрабатывается во время стандартной инициализации site в Python.

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

В представленном предупреждении среди потенциально скомпрометированных данных названы облачные учётные данные, API-ключи ИИ-сервисов и закрытые ключи SSH. Отдельный материал за март 2026 года пересказывал публикацию Андрея Карпати о более масштабной атаке на LiteLLM в PyPI, при которой похищались ключи SSH, облачные учётные данные, конфигурации Kubernetes, учётные данные Git, переменные окружения, ключи CI/CD и пароли к базам данных. Однако тот ранний отчёт не устанавливал ни охват Docker-тегов, ни точный перечень артефактов версии 1.107.0 для октябрьского инцидента.

Что следует сделать затронутым пользователям сейчас

Согласно сообщениям, необходимо прекратить использование 1.107.0, откатиться или зафиксировать версию 1.106.2, изолировать любой хост или контейнер, где был установлен либо запущен затронутый артефакт, пересобрать среду из чистой базы и сменить учётные данные, к которым эта среда имела доступ. И Айкидо, и ДжейФрог рассматривают ключевым фактором установку или выполнение вредоносного пакета либо образа, а не его текущую доступность.

Это различие принципиально. Обновление поверх существующей среды может удалить вредоносную версию в дальнейшем, однако не отвечает на вопрос, не были ли секреты раскрыты, пока заражённый wheel-пакет или образ был активен.

Для операторов критерий для принятия мер должен быть широким: любой, кто установил litellm==1.107.0, загрузил один из названных затронутых плавающих тегов или запускал Python в подверженной риску среде, должен считать хост или контейнер потенциально скомпрометированным. Доступные сообщения поддерживают рекомендацию пересобрать систему из чистых образов или сред и сменить все облачные, API-, SSH-, базы данных и другие аналогичные учётные данные, доступные из этой среды выполнения.