Брат по несчастью Trivy — LiteLLM
Ранее я обсуждал атаку на Trivy, а именно внедрение вредоносных артефактов. Более подробно можно ознакомиться ниже. ➥ https://setka.ru/posts/019d0ecd-4473-7732-bfee-db6ef7e36c4b?view_from_feed=tru
В этом же посте я хотел бы поговорить о похожей проблеме, но уже в AI-стеке. Речь про LiteLLM — библиотеку, которую многие используют как единый слой для работы с разными LLM-провайдерами.
В марте 2026 года история вокруг неё стала очень неприятным продолжением кейса с Trivy.
━━━━━━━━━━━ Что произошло ━━━━━━━━━━━
24 марта 2026 года в PyPI появились скомпрометированные версии • litellm==1.82.7 • litellm==1.82.8
Сама команда LiteLLM позже прямо указала, что связывает этот инцидент с более ранним компромиссом Trivy, который использовался в их CI/CD security scanning workflow.
То есть проблема была не в “каком-то левом пакете-клоне”. Под удар попали именно реальные релизы настоящего проекта, опубликованные в официальный канал поставки Python-зависимостей. В этом и есть вся боль supply chain атак: ➣ ты ставишь вроде бы доверенный пакет, а вместе с ним получаешь чужой код.
━━━━━━━━━━━ Что именно было внутри ━━━━━━━━━━━
По данным LiteLLM, вредоносная нагрузка была нацелена на сбор секретов: • переменных окружения • SSH-ключей • cloud credentials • Kubernetes-токенов и паролей к БД с последующей отправкой данных на models.litellm.cloud, который не относится к официальным доменам проекта.
Отдельно показателен кейс с 1.82.8: исследователи обратили внимание на litellm_init.pth. И это уже особенно неприятная деталь, потому что .pth может запускать код при старте Python-интерпретатора — то есть проблема была не на уровне “ты импортнул библиотеку”, а глубже. **В опубликованном разборе прямо указано, что код мог сработать даже без import litellm.**
━━━━━━━━━━━ **Кто мог пострадать** ━━━━━━━━━━━
**Команда LiteLLM отдельно предупредила**, что под риск попадали те, кто ставил или обновлял LiteLLM через pip 24 марта 2026 года в окно между 10:39 UTC и 16:00 UTC, собирал в это время Docker-образы с непинованным pip install litellm, либо подтягивал библиотеку транзитивно через другие AI/agent-инструменты. При этом официальный Docker image LiteLLM и установка из GitHub-репозитория не считались затронутыми.
**Пострадать мог не только тот, кто сознательно ставил LiteLLM руками**, но и тот, у кого он приехал “где-то внутри” зависимостей. А такие сценарии я вижу всё чаще, особенно в экосистеме AI-обвязок, где_ люди собирают пайплайны из десятка библиотек и редко реально проверяют всю цепочку._
━━━━━━━━━━━ **Моё мнение_** ━━━━━━━━━━━
По моему мнению, история с LiteLLM ещё раз показывает, что проблема давно уже не в “опасных библиотеках для AI” и не только в “скомпрометированных security tools”.
Проблема в избыточном доверии к автоматизированной цепочке поставки: если в пайплайн однажды попал заражённый инструмент, дальше он начинает отравлять всё, что вокруг него считает себя безопасным.
