Взлом LiteLLM затронул все семь Python-wheel-пакетов версии 1.107.0 и несколько Docker-образов проекта. Вредоносный релиз был доступен в PyPI около 1 часа 43 минут, но этого достаточно, чтобы скомпрометировать ключи облаков, токены CI/CD, файлы конфигурации и данные браузеров у команд, автоматически подтягивающих свежие зависимости. Для российских разработчиков это очередное напоминание: «обновить пакет» давно перестало быть безобидной операцией.
Как сообщает BleepingComputer, злоумышленники получили доступ к пайплайну релизов LiteLLM 21 октября и опубликовали скомпрометированную версию 1.107.0 в PyPI и контейнерных реестрах. LiteLLM — популярный open-source SDK и AI-шлюз, который даёт приложениям единый API для разных провайдеров моделей. У проекта 61,8 тыс. звёзд на GitHub и около 92 млн ежемесячных загрузок в PyPI; среди пользователей называются NVIDIA, Netflix, AT&T и Okta. Корпоративная приватная версия LiteLLM, по данным проекта, инцидент не затронул.
В PyPI заражёнными оказались все wheel-файлы litellm==1.107.0: они находились в доступе с 11:39:51 до 13:23 UTC. В Docker Hub теги v1.107.0, latest, main-latest и main-stable с 11:46:56 до 14:20 UTC ссылались на вредоносный индекс образа. Те же теги в GitHub Container Registry были отозваны раньше — к 13:51 UTC. Особенно неприятная деталь для команд с нестрогими правилами поставки: под удар попали не только явно закреплённая версия, но и привычные «плавающие» latest и stable.
Исследователи нескольких компаний по безопасности заметили проблему в течение шести минут после публикации. По их данным, исходный код LiteLLM не меняли. Атакующие добавили в установленное Python-окружение три файла: cook.pth, cook.py и sitecustomize.py. Такой способ обходит ожидания разработчика: Python обрабатывает исполняемые строки из .pth-файлов при запуске, а затем пытается импортировать sitecustomize. В результате вредоносный код стартует раньше приложения — и даже запуск Python или pip для проверки заражённой среды может активировать его.
Полезная нагрузка собирала широкий набор данных. В списке — учётные данные AWS, Azure, Google Cloud, Kubernetes, Docker и инструментов управления инфраструктурой; конфигурация и токены AI-инструментов, а также сохранённые LiteLLM настройки провайдеров и моделей. Инфостилер искал ключи Git, GitHub, npm, PyPI и CI/CD, файлы .env, SSH-, GPG- и TLS-ключи. Отдельно он пытался забрать браузерные cookies, сохранённые пароли, историю, данные автозаполнения и платежные сведения, переменные окружения, историю командной оболочки и сведения о системе и сети.
Собранные данные шифровались AES-256-CBC; ключ шифрования, в свою очередь, защищался RSA-4096. Затем архив уходил на домен, замаскированный под инфраструктуру проекта: litellm[.]dev/healthcheck. Файл sitecustomize.py также запускал отделённый загрузчик. Тот раз в час проверял указатель, размещённый на GitHub, и мог скачать Python-код с внешнего сервера для исполнения на хосте. Иными словами, история не сводится к разовой утечке: заражённое окружение могло получить последующую команду уже после установки пакета.
Практический вывод для пострадавших команд жёсткий: не стоит открывать среду, чтобы «быстро посмотреть, что внутри». Рекомендуемый сценарий — остановить затронутые развёртывания, изолировать хосты и исследовать файловую систему без запуска интерпретатора Python. После этого окружения следует пересобрать из чистых резервных копий или доверенных образов, а все потенциально доступные секреты — отозвать и выпустить заново. Простого удаления директории LiteLLM недостаточно: в системе могут остаться файлы автозапуска или работающий загрузчик. В качестве последней чистой версии проекта указана LiteLLM 1.106.2.
Взлом LiteLLM примечателен не только масштабом аудитории, но и повторяемостью сценария. В марте проект уже сталкивался с компрометацией: группа TeamPCP разместила вредоносные версии в PyPI после взлома сканера уязвимостей Trivy от Aqua Security, использовавшегося в CI/CD LiteLLM. Два инцидента за несколько месяцев показывают, что защита прикладного репозитория сама по себе не гарантирует безопасность релиза. Реальная граница доверия проходит через учётные записи, секреты CI, сборочные раннеры, реестры пакетов и правила публикации.
Для продуктовых команд это повод проверить не только LiteLLM, но и собственную гигиену зависимостей: фиксируются ли версии и digest контейнеров, кто может публиковать релизы, есть ли отдельные токены для сборки и доставки, насколько быстро можно отозвать скомпрометированный секрет. AI-стек особенно чувствителен к таким атакам: в одном окружении часто соседствуют ключи облачных провайдеров, доступ к моделям, векторным базам, Kubernetes и production-данным. Чем удобнее единый шлюз для моделей, тем дороже компрометация его канала поставки.
