Атака на цепочку поставок LiteLLM: как один pip install мог слить все ваши секреты - UPROGER

25 марта 2026 года сообщество разработчиков искусственного интеллекта всколыхнула новость о критической атаке на цепочку поставок популярнейшей библиотеки LiteLLM. Андрей Карпаши (Andrej Karpathy), бывший директор по ИИ в Tesla и один из основателей OpenAI, назвал произошедшее «программным кошмаром». Один-единственный pip install litellm мог слить злоумышленникам все ваши SSH-ключи, облачные учётные данные, API-токены и пароли баз данных.

Что такое LiteLLM и почему это важно?

LiteLLM — это open-source Python-библиотека, которая служит единым интерфейсом для работы с десятками различных языковых моделей: OpenAI, Anthropic, Google Gemini, Mistral, Ollama и многих других. Она позволяет разработчикам переключаться между провайдерами ИИ, не переписывая код, и является де-факто стандартом в мире LLM-разработки.

Масштаб использования впечатляет: 97 миллионов скачиваний в месяц. Более 2 100 пакетов в экосистеме Python зависят от LiteLLM, среди которых такие известные проекты, как DSPy, Open Interpreter, PraisonAI, MLflow и langchain-litellm. Это означает, что даже если вы не устанавливали LiteLLM напрямую, вы могли оказаться под угрозой через транзитивную зависимость.

Как произошла атака?

Атака была проведена классическим методом компрометации пакета в PyPI — официальном репозитории Python-пакетов. Версия LiteLLM 1.82.8 (а также версия 1.82.7) содержала вредоносный файл litellm_init.pth, закодированный в base64. Этот файл выполнялся автоматически при каждом запуске Python и отправлял на удалённый сервер злоумышленников следующие данные:

SSH-ключи
Учётные данные AWS, GCP, Azure
Конфигурационные файлы Kubernetes
Git-учётные данные
Переменные окружения (все ваши API-ключи)
История командной оболочки (shell history)
Криптовалютные кошельки
SSL/TLS приватные ключи
Секреты CI/CD-пайплайнов
Пароли баз данных

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

Как атаку обнаружили?

Примечательно, что вредоносная версия была активна менее одного часа — и была обнаружена почти случайно. Разработчик Каллум МакМэхон (Callum McMahon) использовал MCP-плагин в IDE Cursor, который подтягивал LiteLLM как транзитивную зависимость. При установке версии 1.82.8 его машина неожиданно исчерпала оперативную память и зависла.

Именно этот сбой стал ключом к разоблачению: злоумышленник допустил ошибку в коде — бесконечный цикл самовоспроизведения поглощал всю память. Как замечает Карпаши, «если бы атакующий не допустил этой ошибки, атака могла бы оставаться незамеченной дни или недели».

Масштаб угрозы: цепочка поставок

Атаки на цепочку поставок (supply chain attacks) — один из наиболее опасных видов угроз в современном программном обеспечении. Их суть в том, что злоумышленник не атакует вашу систему напрямую, а компрометирует зависимость, которой вы доверяете.

В случае с LiteLLM под угрозой оказались не только прямые пользователи библиотеки, но и все, кто использует зависящие от неё пакеты. Например, команда pip install dspy (которая зависит от litellm>=1.64.0) также привела бы к установке заражённой версии. Аналогичная ситуация с любым другим крупным проектом, использующим LiteLLM.

Реакция сообщества и меры по устранению

После обнаружения уязвимости события развивались стремительно. Команда LiteLLM оперативно удалила заражённые версии 1.82.7 и 1.82.8 из PyPI. Платформа PyPI пометила пакет как «карантинный» (quarantined), что предотвращает его установку даже при прямом указании версии в командах pip install или pip et al.

Simon Willison подтвердил: «К счастью, пакет LiteLLM теперь помечен как “карантинный” на PyPI, поэтому попытка установить скомпрометированное обновление через pip не должна работать». Сборки проектов, зависящих от LiteLLM, снова работают в штатном режиме.

Что делать, если вы установили LiteLLM в этот период?

Если вы устанавливали LiteLLM или зависящие от него пакеты в период активности вредоносной версии (около 25 марта 2026 года), необходимо немедленно принять следующие меры:

Ротируйте все SSH-ключи — сгенерируйте новые пары ключей и обновите их на всех серверах.
Обновите облачные учётные данные — смените ключи доступа AWS (Access Key), сервисные аккаунты GCP и секреты Azure.
Отзовите и перевыпустите API-токены — для всех сервисов: OpenAI, Anthropic, GitHub, Hugging Face и других.
Измените пароли баз данных — особенно если строки подключения хранились в переменных окружения.
Проверьте переменные окружения — убедитесь, что в .env-файлах не было чувствительных данных в момент установки.
Проверьте CI/CD-секреты — смените все токены и секреты в GitHub Actions, GitLab CI, Jenkins и других системах.
Проверьте историю в системах мониторинга и логов на предмет подозрительной активности.

Почему атаки на цепочку поставок так опасны?

Андрей Карпаши в своём посте затронул более широкую философскую проблему современной разработки. Традиционная школа программирования учит нас: «зависимости — это хорошо, переиспользуй чужой код». Однако каждая зависимость — это расширение поверхности атаки.

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

Известные атаки на цепочку поставок последних лет — XZ Utils (2024), event-stream (2018), SolarWinds (2020) — показывают, что это не единичные инциденты, а системная проблема. ИИ-экосистема с её быстро растущим числом библиотек и высокой скоростью обновлений представляет особенно привлекательную цель для злоумышленников.

Выводы и рекомендации для разработчиков

Инцидент с LiteLLM — серьёзное напоминание для всех, кто работает в сфере ИИ-разработки. Вот ключевые уроки, которые стоит вынести:

Аудитируйте зависимости — регулярно проверяйте прямые и транзитивные зависимости вашего проекта с помощью инструментов вроде pip-audit или safety.
Закрепляйте версии — используйте точные версии зависимостей (litellm==1.82.6) вместо диапазонов (litellm>=1.64.0).
Мониторьте новые выпуски — подпишитесь на GitHub-уведомления ключевых зависимостей.
Используйте изолированные среды — запускайте установку пакетов в Docker-контейнерах или виртуальных машинах с ограниченным доступом к секретам хост-системы.
Следите за репутацией — скомпрометированные версии пакетов на PyPI теперь помечаются статусом «карантин», но только после обнаружения угрозы.

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