Представители LiteLLM сообщили, что проект пострадал от атаки на цепочку поставок: на прошлой неделе злоумышленники скомпрометировали инфраструктуру выпуска релизов и распространили вредоносную версию 1.107.0 в PyPI, Docker Hub и GHCR. Модифицированный пакет содержал инфостилер и бэкдор, которые похищали учетные данные жертв, а также позволяли удаленно выполнять код.
LiteLLM представляет собой популярный опенсорсный SDK для Python и ИИ-шлюз, который позволяет приложениям получать доступ к ИИ-моделям от разных поставщиков через общий API. Проект имеет более 61 800 звезд на GitHub и насчитывает порядка 92 млн ежемесячных загрузок в PyPI.
По информации разработчиков, 21 октября 2026 года малварь проникла во все семь установочных пакетов LiteLLM 1.107.0 в формате wheel (.whl) для Windows, Linux и macOS. В PyPI зараженная версия была доступна с 14:39 до 16:23 по московскому времени. В Docker Hub вредоносные образы распространялись под тегами v1.107.0, latest, main-latest и main-stable с 14:46 до 17:20 по московскому времени, а в GitHub Container Registry (GHCR) — примерно с 14:47 до 16:51 по московскому времени. При этом отдельно подчеркивается, что атакующие не вносили изменений в исходный код самого LiteLLM.
Как сообщили исследователи из компаний Socket и Endor Labs, злоумышленники добавили в установочные пакеты три файла (cook.pth, cook.py и sitecustomize.py) и злоупотребили штатными механизмами Python. В результате вредонос запускался еще до момента импорта LiteLLM — при старте интерпретатора.
Дело в том, что при запуске Python обрабатывает .pth-файлы из директории установленных библиотек. Вредоносный cook.pth содержал команду import cook, которая загружала cook.py и тем самым запускала инфостилер. Кроме того, Python автоматически пытается импортировать модуль sitecustomize, если такой файл присутствует в окружении, а в данном случае sitecustomize.py запускал отдельный фоновый загрузчик для удаленного выполнения кода.
В результате для активации малвари достаточно было запустить Python в зараженном окружении, и вредонос мог срабатывать даже при запуске pip во время проверки или удаления скомпрометированного пакета.
По словам специалистов, злоумышленники использовали стилер privcollect, который собирал учетные данные AWS, Azure и Google Cloud, секреты Kubernetes и Docker, токены GitHub, npm и PyPI, SSH-, GPG- и TLS-ключи, .env-файлы, конфигурации ИИ-инструментов, данные из браузеров и переменные окружения. Вся собранная в системе жертвы информация передавалась по адресу litellm[.]dev/healthcheck.
Помимо стилера, упомянутый выше файл sitecustomize.py запускал отдельный фоновый загрузчик, который обеспечивал удаленное выполнение кода. Раз в час он обращался к репозиторию letters9813/pythonclient-test на GitHub и читал файл domain.txt, где злоумышленники могли указать адрес актуального управляющего сервера. В случае получения адреса загрузчик обращался к <domain>/codepy, скачивал оттуда Python-скрипт и выполнял его в зараженной системе.
Как показало расследование инцидента, хакеры использовали OAuth-токены GitHub CLI сразу трех инженеров LiteLLM. Так, один из токенов принадлежал владельцу организации GitHub и имел повышенные права. С его помощью злоумышленники отключили правила защиты ветки и принудительно отправили изменения, позволявшие системе сборки использовать другой исходный репозиторий.
После этого хакеры запустили измененный воркфлоу GitHub Actions, указав в качестве источника репозиторий-двойник Berri-AI/litellm (вместо настоящего BerriAI/litellm). В результате вредоносные пакеты прошли штатную процедуру подписи и были опубликованы как официальный релиз.
Учетные данные другого разработчика использовались для подтверждения публикации, а третьего — для удаления записей о запусках рабочего процесса в тестовом и production-окружениях, что сократило объем логов, доступных при проведении расследования.
Изначально специалисты LiteLLM связали эту атаку с внутренним инстансом, который по какой-то причине оказался доступен из интернета и имел подозрительную учетную запись. Кроме того, обнаружилось, что использованные хакерами OAuth-токены GitHub CLI могли случайно попасть в логи. Дело в том, что в некоторых случаях Claude Code включает токены в тело ответа, которое затем попадает в логи. Поэтому исходная теория гласила, что атакующие могли получить доступ к упомянутому инстансу, извлечь GitHub-токены из логов и затем использовать их для компрометации процесса выпуска релизов.
Однако позже разработчики заявили, что проблема была не в этом. Как оказалось, еще 27 мая 2026 года в публичный репозиторий LiteLLM-Labs/lite-harness случайно попал конфигурационный файл с мастер-ключом от внутренней платформы LiteLLM Agent Platform. Утечку быстро заметили и с помощью force push переписали историю ветки, убрав проблемный коммит. Однако сам скомпрометированный ключ, который следовало отозвать, так и остался действующим.
10 октября 2026 года злоумышленники использовали этот ключ для доступа к API платформы и получили OAuth-токен GitHub CLI владельца GitHub-организации LiteLLM. С его помощью они создали временные ветки в двух внутренних репозиториях и запустили вредоносные рабочие процессы через GitHub Actions, которые отправили хранившиеся в CI секреты на подконтрольный хакерам сервер. В результате атакующие получили OAuth-токены еще двух мейнтейнеров LiteLLM.
По информации специалистов из компании Wiz, примерно через 4,5 часа после кражи данных злоумышленники уже начали использовать похищенные учетные данные AWS. В нескольких случаях злоумышленники также проводили энумерацию IAM: запрашивали списки ролей, пользователей и ключей доступа, а также собирали другую информацию об AWS-окружении.
Исследователи полагают, что такая активность характерна для так называемого LLMjacking — использования чужих учетных данных для доступа к ИИ-сервисам за счет жертвы.
В настоящее время все вредоносные релизы удалены. Всем, кто устанавливал LiteLLM 1.107.0 или использовал затронутые образы, рекомендуется изолировать затронутые системы, полностью пересобрать их из чистых образов, а также сменить все секреты. Безопасной версией следует считать LiteLLM 1.106.2.

4 часов назад
6








English (US) ·
Russian (RU) ·