КИБЕРБЕЗОПАСНОСТЬ

Атака на LiteLLM украла облачные ключи и добавила удалённый доступ

Версия LiteLLM 1.107.0 содержала стилер и RAT: разработчикам нужно отозвать ключи, проверить CI/CD и контейнеры.

✍️ Редакция iTech News | 22.10.2026 | ⏱ 4 мин | Источник: The Register
Атака на LiteLLM украла облачные ключи и добавила удалённый доступ

Атака на LiteLLM затронула релиз 1.107.0 популярного AI-шлюза: в пакет попали стилер учётных данных и троян удалённого доступа. Для команд, которые используют LiteLLM в прокси-сервисах, контейнерах и CI/CD, это означает не просто срочный откат версии, а возможную компрометацию ключей облаков, LLM-провайдеров и браузерных сессий.

Вредоносный релиз появился 21 октября 2026 года и был доступен через PyPI и Docker-регистры. Как сообщает The Register, PyPI изолировал пакет в течение нескольких часов, а образ litellm/litellm:1.107.0 затем удалили из Docker Hub и GHCR. Однако удаление дистрибутива не отменяет уже выполненный код: если Python запускался после установки этой версии, секреты следует считать скомпрометированными.

LiteLLM, который разрабатывает BerriAI, даёт единый интерфейс к OpenAI, Anthropic, Google Gemini и другим моделям. У проекта около 23 млн еженедельных загрузок. Такая прослойка обычно находится в особенно интересной точке инфраструктуры: рядом живут API-ключи моделей, строки подключения к базам, облачные роли, переменные окружения и токены автоматизации. Поэтому атака на LiteLLM — это риск не для одного Python-процесса, а для всего контура, в котором этот процесс работает.

Что попало в релиз

Исследователи Wiz Бенджамин Рид и Рами Маккарти связали полезную нагрузку с вредоносными коммитами в репозитории github.com/Berri-AI/litellm — это вариант названия легитимной организации BerriAI с дефисом. Через него злоумышленники внедрили в процесс выпуска три файла. Первый, cook.pth, заставлял Python автоматически загружать cook.py при каждом запуске интерпретатора. Пользователю не требовалось импортировать LiteLLM или запускать отдельный скрипт: достаточно было обычного старта Python в среде, где установлен заражённый пакет.

Файл cook.py собирал данные через 16 модулей. В список целей вошли сохранённые пароли и cookie Chrome, Firefox, Edge и Safari; AWS-учётные данные из ~/.aws/; переменные окружения; метаданные экземпляров EC2 и ECS; сервисные ключи и Application Default Credentials Google Cloud; токены Azure CLI. Отдельно малварь искала ключи OpenAI, Anthropic, Cohere и других AI-сервисов, а также приватные SSH-ключи, GPG-ключи и историю командной оболочки. Это неприятная комбинация: даже если ключ LLM-провайдера был ограничен по бюджету, рядом мог оказаться доступ к облачной подписке или репозиторию.

Третий файл, sitecustomize.py, выполнял роль RAT — трояна удалённого доступа. Он поднимал фоновый процесс, который раз в час обращался к инфраструктуре атакующих за командами. Собранные данные шифровались AES-256-CBC; ключ шифрования упаковывался публичным RSA-4096-ключом, после чего архив отправлялся HTTP-запросом на домен, маскирующийся под ресурс LiteLLM. То есть инцидент нельзя сводить к утечке токенов: заражённая машина могла получить и произвольную команду извне.

Откат версии — только начало

Безопасной последней версией на момент публикации называлась v1.106.2. Команды, использовавшие 1.107.0, должны остановить её развёртывание и проверить, запускался ли Python после установки — в том числе внутри proxy-контейнеров и на CI-раннерах. Охотник за вредоносным ПО Aikido Security Ильяс Макари советует искать файлы /tmp/.pc_once_*: их наличие означает, что эксфильтрация уже сработала. Файл /tmp/remote_code_loader.lock указывает, что управляющий демон запускался или может продолжать работать.

Особое внимание нужно уделить не только явно закреплённому тегу 1.107.0. Проверки требуют также окружения, которые получили образ через теги latest, main-latest или main-stable. После инвентаризации требуется отозвать и перевыпустить все доступные из заражённых сред секреты: ключи LLM-провайдеров, облачные ключи, SSH-ключи, токены CI/CD и сервисные аккаунты. Простая переустановка пакета не возвращает контроль над уже скопированными данными и не гарантирует, что фоновый процесс не успел исполнить команду.

Для российских команд здесь нет географического исключения. Многие используют LiteLLM как внутренний шлюз между приложениями, локальными моделями и зарубежными API, а CI-раннеры нередко получают широкие права ради удобства сборки и деплоя. Инцидент хорошо показывает цену плавающих Docker-тегов и незафиксированных зависимостей: один «безобидный» апдейт библиотеки может оказаться точкой входа в облачную инфраструктуру. Минимальный практический набор — фиксировать версии и digest образов, отделять секреты рантайма от секретов сборки, ограничивать права сервисных аккаунтов и сохранять телеметрию исходящих соединений контейнеров.

Это уже не первый случай проблем в цепочке поставок LiteLLM: мартовский компромисс, по оценке CloudSEK, потенциально затронул свыше 2 500 организаций и 434 000 CI/CD-пайплайнов. Масштаб нынешнего эпизода пока не установлен, а BerriAI на запрос издания не ответила. Главный вопрос теперь не в том, сколько раз пакет успели скачать, а в том, сколько сред запускали Python в заражённый период и какие секреты были в них доступны. Технические индикаторы и детали атаки собраны в материале The Register.

Поделиться: Telegram X LinkedIn