Атака через LiteLLM: полный список безопасных и уязвимых локальных ИИ-инструментов (Ollama, LM Studio, ComfyUI)

Тихая война в вашем conda environment

24 марта 2026 года. Вы запускаете свой локальный Llama-4 через Ollama, генерируете изображение в ComfyUI или тестируете новую модель в LM Studio. Все работает. Но в фоне, через импорт одной библиотеки, ваши API-ключи уже летят на сервер в неведомом дата-центре.

Атака на цепочку поставок LiteLLM – не просто новость для параноиков. Это реальная угроза для каждого, кто работает с локальными ИИ-инструментами. Проблема в том, что многие даже не знают, что их софт использует эту библиотеку.

Как атака попадает в локальные инструменты

Вы думаете: «Я же не вызываю LiteLLM напрямую». Вот и ошибка. Половина современных ИИ-тулзов ставит его как транзитивную зависимость. Особенно те, что написаны на Python и используют единый интерфейс для разных моделей.

Механика простая и мерзкая:

• Вы устанавливаете Ollama через официальный инсталлятор – вроде бы безопасно.
• Потом ставите Python-скрипт для анализа логов или кастомный плагин – он тянет за собой зависимости.
• В requirements.txt указано «litellm>=1.0.0» – и pip качает последнюю доступную версию, которая оказывается поддельной.
• При первом импорте скрытый payload сканирует ~/.bashrc, .env файлы, конфиги в /etc/ и выгребает все ключи, какие найдет.

Список инструментов: от безопасных до опасных

Я разделил популярные тулзы на три категории по уровню риска. Критерий простой: используют ли они Python-зависимости и могут ли потянуть за собой скомпрометированный LiteLLM.

1 Шаг первый: Диагностика вашего окружения

Прежде чем паниковать, узнайте врага в лицо. Откройте терминал и выполните эти команды.

# Проверяем, установлен ли вообще LiteLLM в вашем основном Python
pip list | grep -i litellm

# Если видите что-то кроме официального пакета версии 2.0.8 или выше – тревога
# Пример вывода, который должен вас испугать:
# litellm-fork 1.2.3
# litellm-utils 0.5.1

# Глубокое сканирование всех виртуальных окружений
# (если вы, как нормальный человек, используете venv или conda)
find ~ -name "pip" -type f 2>/dev/null | while read pip_path; do
  env_dir=$(dirname $(dirname $pip_path))
  echo "\n=== Проверяем окружение: $env_dir ==="
  $pip_path list | grep -i litellm
 done

2 Шаг второй: Целенаправленная проверка инструментов

Теперь пройдемся по конкретным программам. Начнем с самых рискованных.

ComfyUI: гнездо уязвимостей

Запустите эту проверку внутри папки с ComfyUI (где лежит main.py).

# Активируем виртуальное окружение ComfyUI, если оно есть
source venv/bin/activate  # или для Windows: venv\Scripts\activate

# Смотрим зависимости
pip list | grep -i litellm

# Особое внимание – папка custom_nodes
# Именно там живут плагины, которые тянут сомнительные зависимости
find ./custom_nodes -name "requirements.txt" -o -name "setup.py" | xargs grep -l "litellm" 2>/dev/null

Если нашли упоминания – откройте эти файлы и посмотрите, как указана зависимость. Строка вроде litellm>=1.0.0 – красный флаг.

LM Studio: проверка серверного компонента

LM Studio сам по себе безопасен, но его Python-сервер для плагинов – нет.

# Путь может отличаться, но обычно сервер здесь:
cd "~/Library/Application Support/LM Studio/Server"  # macOS
# или %APPDATA%\LM Studio\Server на Windows

# Проверяем окружение сервера
pip list | grep litellm

# Если сервер запущен – остановите его через настройки LM Studio перед проверкой

Ollama: проверка оберток и скриптов

Сам Ollama чист. Но вы могли установить Python-библиотеку ollama-python или другие утилиты для работы с ним. Проверьте их.

# Ищем любые Python-пакеты, связанные с Ollama
pip list | grep -i ollama

# Если нашли, смотрите их зависимости
pip show [имя_пакета] | grep -A 10 "Requires:"

3 Шаг третий: Очистка и замена

Нашли подозрительные пакеты? Действуйте быстро, но без паники.

# 1. Удаляем все пакеты с именами, похожими на litellm
pip uninstall -y litellm-fork litellm-utils lite-llm litellm-client

# 2. Устанавливаем официальную безопасную версию
pip install "litellm>=2.0.8" --force-reinstall

# 3. Проверяем, что поставилась правильная версия
python -c "import litellm; print(f'Версия: {litellm.__version__}')"

Глупые ошибки, которые совершают все

За 10 лет в DevOps я видел одни и те же косяки. Вот топ-3, которые сведут на всю вашу безопасность.

1. Доверять pip по умолчанию. Выполнять pip install some-package без проверки хэшей – все равно что пить из лужи в подворотне. Всегда используйте --require-hashes если есть requirements.txt, или хотя бы фиксируйте версию точной зависимостью: litellm==2.0.8.
2. Запускать скрипты от root. Ваш ИИ-агент не должен работать из-под sudo. Создайте отдельного пользователя с ограниченными правами. Если вредоносный код выполнится от root – прощай, система.
3. Хранить ключи в переменных окружения навсегда. Да, это удобно. И именно поэтому это первое, что сканирует malware. Используйте секреты вроде HashiCorp Vault или хотя бы временные переменные. Подробнее в гайде по защите локальных LLM.

Частые вопросы (на которые уже поздно спрашивать)

Следующая большая атака будет не через PyPI, а через модельные хабы вроде Hugging Face. Кто-то загрузит популярную fine-tuned версию Llama-5 с backdoor'ом в веса, и тысячи разработчиков скачают его себе. Проверка целостности модели станет такой же рутиной, как проверка хэшей в pip.

Начните сегодня. Потом будет поздно.

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