LiteLLM на PyPI заразили: урок о цепочке поставок

21 октября 2026 года в популярный пакет LiteLLM на PyPI попала заражённая версия 1.107.0. Вредоносный код крал облачные ключи, секреты разработчика и данные браузеров. Заражённая версия провисела на PyPI около полутора часов, но этого хватило. История — наглядный пример атаки на цепочку поставок, от которой не застрахован ни один проект, использующий чужие пакеты.

Что произошло

LiteLLM — шлюз для работы с разными ИИ-моделями через единый интерфейс. По данным проекта, 21 октября злоумышленники получили доступ к конвейеру выпуска через учётные записи нескольких инженеров и выпустили заражённые версии: пакет на PyPI и образы в Docker Hub и GHCR. По словам директора по безопасности LiteLLM, похоже, были украдены токены OAuth командной строки GitHub.

Заражённый код не менял саму программу: он добавлял несколько файлов, которые запускались при каждом старте Python. Цель — собрать и отправить наружу облачные токены, ключи ИИ-сервисов, секреты и данные браузеров. Приватную корпоративную версию, по словам проекта, атака не затронула.

Почему это опасно для любого проекта

Современное приложение состоит на 80–90% из чужого кода: пакеты npm, PyPI, образы Docker. Вы доверяете им так же, как своему коду. Если злоумышленник подменит пакет, вредоносный код окажется на вашем сервере с теми же правами, что и приложение.

Особенность именно этой атаки — заражённый код запускался при любом старте Python, в том числе когда разработчик пытался разобраться в проблеме. Поэтому «зайду посмотрю, что не так» на заражённой машине только усугубляет ситуацию.

Что делать, если вы используете LiteLLM

1. Проверьте, не устанавливалась ли версия 1.107.0 или заражённые образы Docker в указанные окна.
2. Если да — считайте все секреты на этой машине скомпрометированными и смените их из чистого окружения.
3. Откатитесь на чистую версию до атаки (по данным источников — 1.106.2) и закрепите её по контрольной сумме.
4. Пересоберите заражённые контейнеры из доверенных образов.
5. Не запускайте Python в заражённом окружении для «проверки»: вредоносный код сработает снова.

Как защитить проект на будущее

Атаку на цепочку поставок нельзя предотвратить полностью, но риск снижается.

• Фиксируйте версии по контрольным суммам. Lock-файл с хешами не даст молча подменить пакет.
• Не обновляйтесь вслепую в день выхода. Для критичных зависимостей выдержите паузу и следите за сообщениями о проблемах.
• Отключите автоматические скрипты установки, где можно. Новые версии npm, например, по умолчанию их не запускают.
• Держите секреты вне кода и с коротким сроком жизни, чтобы украденный токен быстро протух.
• Разделяйте окружения: ключи боевого сервера не должны лежать на машине разработчика.

Наше мнение

Мы не призываем отказываться от чужих пакетов — без них разработка невозможна. Но относиться к ним стоит как к поставщикам, которых нужно контролировать. Для заказчика практический вопрос к подрядчику простой: как у вас устроено управление зависимостями, фиксируете ли версии, как быстро реагируете на сообщения о заражённых пакетах.

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

Что проверить прямо сейчас

Даже если вы не используете именно LiteLLM, потратьте полчаса на три вещи. Во-первых, посмотрите, есть ли в проекте lock-файл с хешами и фиксированы ли версии ключевых зависимостей. Во-вторых, проверьте, где хранятся секреты: если ключи лежат в коде или в репозитории, их нужно вынести и сделать короткоживущими. В-третьих, убедитесь, что машина разработчика и боевой сервер не делят одни и те же ключи. Эти три проверки не защитят от всех атак на цепочку поставок, но снимают самые частые последствия.

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

Ещё один практический приём — отделять установку зависимостей от их выполнения. Сборка в CI может ставить пакеты в изолированном окружении, где нет боевых секретов, а на сервер попадает уже проверенный артефакт. Тогда даже заражённый пакет при установке не получит доступа к ключам продакшена.

Что это значит для заказчика

Если вы заказываете разработку, вам не нужно разбираться в тонкостях npm и PyPI. Достаточно задать подрядчику несколько вопросов и получить внятные ответы: фиксируете ли вы версии зависимостей, как реагируете на сообщения о заражённых пакетах, где хранятся секреты проекта и разделены ли окружения. Если на эти вопросы отвечают расплывчато, это повод для отдельного разговора: цепочка поставок — одна из самых частых точек входа в 2026 году, и экономия на дисциплине здесь оборачивается инцидентами.