В этой статье
Если у вашей компании есть ИИ-приложение, чат-бот или внутренний инструмент, подключённый к моделям вроде GPT, Claude или Gemini, задайте сегодня технической команде один вопрос: устанавливал ли 21 октября 2026 года какой-нибудь сервер, ноутбук или конвейер сборки LiteLLM версии 1.107.0? Эту версию опубликовали злоумышленники, и она провисела в PyPI около двух часов, с 14:39 до 16:23 по времени Эр-Рияда, набрав около 49 000 загрузок. Она крадёт облачные ключи, ключи поставщиков ИИ, пароли баз данных и ключи SSH. Если ответ «да», удалить её недостаточно: пересоберите машину из чистого образа и смените все ключи, к которым она имела доступ. Безопасная версия — 1.106.2.
Что именно произошло?
LiteLLM — это библиотека и шлюз с открытым исходным кодом, которые позволяют одному приложению общаться с десятками моделей ИИ через единый интерфейс, поэтому многие компании ставят его в центр своих ИИ-продуктов. По данным Chainguard, за последний месяц его скачали из PyPI более 100 миллионов раз, и от него зависят более 2 000 других пакетов, так что многие команды устанавливают его, даже не зная об этом.
Согласно официальному отчёту LiteLLM об инциденте, злоумышленники получили токены доступа GitHub, которые утекли в журналы проекта. 21 октября в 10:08 UTC они воспользовались привилегированной учётной записью разработчика, чтобы обойти защиту ветки и изменить процесс публикации так, чтобы сборка шла из репозитория с похожим названием: «Berri-AI/litellm» вместо «BerriAI/litellm». В 11:39 UTC вредоносные файлы попали в PyPI, а в 11:46 UTC вышли заражённые образы Docker с тегами v1.107.0, latest, main-latest и main-stable. PyPI удалил версию к 13:23 UTC, а теги Docker очистили в 14:20 UTC, то есть в 17:20 по времени Эр-Рияда.
Это вторая атака на тот же проект в этом году. Chainguard напоминает, что в марте 2026 года группа с помощью украденного токена PyPI опубликовала версии 1.82.7 и 1.82.8.
Что крадёт вредоносная версия?
Опасность в том, что она не ждёт, пока ваше приложение начнёт использовать LiteLLM. Версия добавила стартовые файлы Python, которые выполняются при каждом запуске Python на этой машине, даже для совершенно посторонней команды. Согласно анализу Wiz, похититель собирал:
- Облачные ключи AWS, Google Cloud и Azure из файлов конфигурации, переменных окружения и метаданных сервера.
- API-ключи OpenAI, Anthropic, Cohere и других поставщиков ИИ, то есть ваш счёт и ваши данные.
- Закрытые ключи SSH, историю командной строки, а также пароли и cookie, сохранённые в браузерах.
- До 500 учётных данных поставщиков, хранящихся в базе данных LiteLLM Proxy.
Злоумышленники не медлили. Wiz зафиксировала, что украденные учётные данные AWS начали проверять примерно через 4,5 часа после кражи — с серверов сборки и узлов Kubernetes. Вредоносная программа также устанавливала второй этап, который каждый час загружает удалённый код, поэтому машина остаётся открытой даже после удаления пакета.
Затронута ли моя компания?
Скорее всего, нет, если ваша команда фиксирует точные версии и ничего не обновляла 21 октября с 14:39 до 17:20 по времени Эр-Рияда. Вы могли пострадать, если верно хотя бы одно из следующего:
- Сервер или контейнер выполняет «pip install litellm» без фиксированной версии или скачивает тег Docker «latest».
- Конвейер CI/CD пересобирался в тот день после обеда.
- Разработчик пробовал LiteLLM на своём ноутбуке в тот день.
- Ваша система использует другой пакет, зависящий от LiteLLM.
LiteLLM сообщает, что клиентов её частной версии Enterprise атака не затронула.
Пять шагов на сегодня
- Найти: версию 1.107.0 в lock-файлах, журналах сборки и образах контейнеров, а также файлы cook.pth и sitecustomize.py в папке пакетов Python.
- Пересобрать: если нашли, не ограничивайтесь удалением. Официальный отчёт предупреждает, что запуск pip в заражённой среде может снова активировать вредоносную программу. Пересоберите машину или контейнер из чистого образа.
- Сменить все ключи: облачные ключи и роли, ключи поставщиков ИИ, пароли баз данных и ключи SSH, до которых могла дотянуться машина. Исходите из того, что они уже у злоумышленников.
- Проверить журналы: просмотрите активность в облаке с 21 октября на предмет необычных вызовов вроде GetCallerIdentity и следите за счётом поставщика ИИ, чтобы заметить незнакомые расходы.
- Закрепить версии: установите litellm==1.106.2 или более позднее официальное исправление и фиксируйте каждую библиотеку lock-файлом, а не скачивайте «latest» автоматически.
Если вы читали нашу предыдущую статью о забытых ключах в коде ИИ-агентов, урок тот же, только с другой стороны: ключи ИИ теперь входят в число самых ценных секретов вашей компании, и место, где они собраны, становится мишенью.
Мнение Origami
Сам код LiteLLM здесь никто не взламывал. Злоумышленники изменили способ его сборки и публикации, поэтому одна лишь проверка исходного кода ничего бы не выявила. Вот почему защита ИИ-продуктов зависит не столько от выбора библиотеки, сколько от того, как её эксплуатировать: фиксированные версии, отдельный ключ для каждой среды только с нужными правами, лимиты расходов у каждого поставщика ИИ и чёткий учёт того, кто к чему имеет доступ. Когда мы в Origami создаём ИИ-системы для компаний, мы считаем шлюз к моделям самой чувствительной частью системы, потому что в нём хранятся ключи ко всему. Если вы хотите проверить своё ИИ-приложение на последствия этого инцидента или навести порядок в его ключах и правах, свяжитесь с нами.
Источники
Частые вопросы
Как понять, установила ли моя компания взломанную версию LiteLLM?
Попросите команду поискать litellm 1.107.0 в lock-файлах, журналах сборки и образах контейнеров, а также файлы cook.pth или sitecustomize.py в папке пакетов Python. Окно риска пришлось на 21 октября 2026 года, с 14:39 до 17:20 по времени Эр-Рияда.
Достаточно ли удалить пакет?
Нет. Вредоносная программа запускается при каждом старте Python и устанавливает второй этап, который каждый час загружает код. Пересоберите машину или контейнер из чистого образа, а затем смените все ключи, к которым у неё был доступ.
Какая версия LiteLLM безопасна?
LiteLLM рекомендует закрепить версию 1.106.2 или более раннюю. Согласно официальному отчёту об инциденте, клиентов частной версии Enterprise атака не затронула.
Мы не используем LiteLLM напрямую. Могли ли мы пострадать?
Да. Более 2 000 пакетов зависят от LiteLLM, поэтому он мог установиться как зависимость другой библиотеки. Проверьте полный список зависимостей, а не только то, что ваша команда установила сама.
Следите за Origami в Google
Добавьте Origami в предпочтительные источники, и наши статьи будут показываться вам первыми в Google Поиске и главных новостях.








