Компрометация LiteLLM 1.82.7 и 1.82.8: инструкция по проверке и срочному обновлению

Тихий взрыв в сердце вашего AI стека

Представьте, что фундамент вашего дома за ночь превратился в сахар. Примерно это произошло 23 марта 2026 года с двумя версиями LiteLLM — популярнейшей библиотекой, которую тысячи разработчиков используют для работы с GPT, Claude, Llama и десятками других моделей.

Версии 1.82.7 и 1.82.8 были скомпрометированы. В пакет на PyPI под видом официального обновления попал вредоносный код. Если вы установили LiteLLM в эти дни, ваш сервер мог уже отправить ключи API, токены аутентификации и конфигурации на внешний сервер.

1 Диагностика: ваш проект под ударом?

Не гадайте. Откройте терминал прямо сейчас.

# Перейдите в директорию вашего проекта
cd /path/to/your/project

# Активируйте виртуальное окружение, если используете
source venv/bin/activate  # или аналогичная команда

# Проверьте установленную версию LiteLLM
python -c "import litellm; print(f'Установлена версия LiteLLM: {litellm.__version__}')"

Если терминал выводит 1.82.7 или 1.82.8 — немедленно остановите все процессы, которые используют эту библиотеку. Серьезно. Выключите демоны, остановите Docker-контейнеры, приостановите задачи в очереди (Celery, RQ).

2 Немедленная изоляция и ротация ключей

Предположим худшее: ваши credentials утекли. Действуйте по этому плану.

1. Отзовите ВСЕ ключи API, которые могли быть переданы через LiteLLM: OpenAI, Anthropic (Claude), Google Vertex, AWS Bedrock, Azure OpenAI. Каждый.
2. Смените пароли и токены к любым внутренним системам, если они хранились в конфиге рядом с LiteLLM.
3. Проверьте логи вашего приложения и системные логи на предмет подозрительных исходящих подключений за последние 48 часов. Ищите домены, которые не относятся к официальным AI-провайдерам.

Для детальной оценки рисков и процедуры ротации загляните в наш специальный материал — Критическая уязвимость в LiteLLM 1.82.8.

3 Чистое обновление до безопасной версии

Нельзя просто сделать pip install --upgrade litellm. Скомпрометированный пакет может оставить следы. Нужна хирургическая чистка.

# 1. Принудительно удалите текущую версию
pip uninstall litellm -y

# 2. Очистите кэш pip (важно!)
pip cache purge

# 3. Установите последнюю подтвержденную безопасную версию.
# На 24.03.2026 это версия 1.82.9 или новее.
# Всегда проверяйте официальный GitHub на предмет последних рекомендаций.
pip install litellm==1.82.9

Типичные ошибки, которые все совершают

• Забывают про контейнеры. Обновили код на хосте, а 15 Docker-образов по-прежнему содержат старый слой с уязвимой версией. Пересоберите все образы с нуля.
• Не очищают кэш pip. Без pip cache purge следующий pip install может достать скомпрометированный пакет из локального кэша.
• Игнорируют косвенные зависимости. Ваш requirements.txt может не содержать явной ссылки на LiteLLM, но она может быть зависимостью другого пакета. Используйте pip list | grep litellm во всех окружениях.

Что делать, если обновление ломает окружение?

Бывает. Новая версия библиотеки может конфликтовать с другими пакетами. Ваша задача — безопасность, а не совместимость. Алгоритм:

1. Заморозьте работу с AI-функционалом в продакшене.
2. Разверните изолированное тестовое окружение.
3. Восстановите безопасную версию LiteLLM (1.82.9) и проверьте, не ломает ли она вашу логику. Если ломает — ищите проблему в своем коде или обновляйте зависимости.
4. Никогда не откатывайтесь на скомпрометированные версии 1.82.7/1.82.8. Это хуже, чем просто выключить функционал.

Если проблемы со стабильностью всего AI стека вам знакомы, возможно, стоит посмотреть на альтернативные решения для инференса, например, vLLM 0.14.0, или погрузиться в сравнение локальных инструментов.

Вопросы, которые вы стеснялись задать

И последнее. Эта история — не про баг в коде. Это про доверие к цепочке поставок программного обеспечения (software supply chain). Сегодня это LiteLLM, завтра — любая другая библиотека из вашего requirements.txt. Пересмотрите свои процессы. Сейчас.

Подписаться на канал