Ключи ко всем LLM-провайдерам утекли через pip: заражены две версии litellm

Библиотека роутит запросы между LLM-провайдерами через один API, поэтому в ней по определению лежат ключи всех подключённых провайдеров. Загрузок у неё больше 95 млн в месяц (Endor Labs, 24.03).

Проверить можно за минуту. `pip show litellm` покажет версию: опасны ровно 1.82.7 и 1.82.8. Дальше ищем файл-закладку в site-packages — `find /usr/lib/python3.13/site-packages/ -name "litellm_init.pth"`. Нашёлся, удаляем.

В requirements.txt закрепляем чистую версию: 1.82.6 и всё, что раньше, либо 1.83.0 и новее (блог LiteLLM, 24.03). Официальный Docker-образ `ghcr.io/berriai/litellm` не затронут, там зависимости зафиксированы. Удар пришёлся только по установке через pip.

После этого LiteLLM требует ротировать все секреты, которые видел процесс: ключи провайдеров ИИ, облачные учётные данные, пароли БД, SSH-ключи и токены Kubernetes. Инциденты команда принимает на security@berri.ai. В сети признак заражения — трафик на models.litellm[.]cloud и checkmarx[.]zone, официальный домен проекта только litellm.ai.

**Цифра 2500 компаний означает не то, что кажется.** CloudSEK реконструировала засветку учётных данных по 434 000 CI/CD-пайплайнов и прямо предупреждает: попадание в список не доказывает взлом компании (SecurityWeek, 12.08). Свою засветку организация проверяет на exposure.cloudsek.com/ai-supply-chain-incident.

Вход был не в самом LiteLLM. CI-пайплайн проекта ставил сканер Trivy незакреплённой версией через apt, и скомпрометированный сканер сам приехал в сборку. Дальше пейлоад собрал секреты, прошёл по Kubernetes через привилегированные поды на каждой ноде и оставил systemd-бэкдор.