Уязвимость Unsloth Studio превращала обычную проверку AI-модели в запуск произвольного Python-кода. Проблема была связана с настройкой trust_remote_code: вредоносная модель могла выполнить код еще до загрузки весов и инференса. Для команд, которые тянут модели из Hugging Face и быстро гоняют эксперименты, это неприятное напоминание: модельный репозиторий давно перестал быть просто папкой с данными.
Проблему описал исследователь Pillar Security Ариэль Фогель, сообщает Dark Reading. Речь идет о Web UI-фронтенде Unsloth Studio для Unsloth — популярной open source-библиотеки, которую используют для дообучения и квантизации больших языковых моделей. По данным публикации, достаточно было выбрать вредоносную модель в интерфейсе Studio: при чтении config.json backend мог скачать и выполнить Python-код из репозитория модели.
Ключевая деталь здесь не в том, что кто-то запустил подозрительный скрипт руками. Код срабатывал во время операции, которую пользователь разумно воспринимает как инспекцию метаданных. Не запуск модели, не инференс, не обучение на GPU за деньги компании, а обычная проверка конфигурации. Именно поэтому баг выглядит опаснее типичного предупреждения «не запускайте непонятный код из интернета» — пользователь мог вообще не понимать, что дал коду шанс выполниться.
Pillar Security связала уязвимость Unsloth Studio с использованием trust_remote_code=True при проверке конфигурации модели. Эта настройка в экосистеме Transformers нужна для случаев, когда модель требует собственного Python-кода: например, нестандартной архитектуры или кастомной логики загрузки. Функция полезная, но с очевидной ценой. Если инструмент включает ее автоматически, он фактически принимает решение доверять удаленному репозиторию за пользователя.
По словам Фогеля, в корпоративной AI-среде такой сценарий мог открыть доступ к данным и секретам, доступным процессу Unsloth Studio: проприетарным обучающим наборам, артефактам моделей, ключам облаков, SSH-ключам и другим учетным данным. Это не обязательно production-контур, но внутренние песочницы для экспериментов часто живут рядом с чувствительными данными. Иногда даже ближе, чем хотелось бы безопасникам.
Unsloth получил отчет от Pillar Security в начале июня и закрыл проблему позднее в том же месяце в версии 2026.6.9. Исследователи проверили вектор атаки и подтвердили, что он больше не работает. При этом, по данным Dark Reading, CVE у проблемы не появилось: Pillar утверждает, что Unsloth отказался публиковать предложенный security advisory. Также компания, по словам исследователей, спорила с частью оценки риска, ссылаясь на malware-сканирование Hugging Face и beta-статус Studio.
Отдельно важно: Pillar не видел признаков эксплуатации именно этой конфигурации в реальных атаках. Это снижает температуру новости, но не убирает проблему. В экосистеме ML уже были похожие истории вокруг trust_remote_code: Dark Reading упоминает LMDeploy с CVE-2026-46432, vLLM с CVE-2026-4944 и InstructLab с CVE-2026-6859. Когда один и тот же класс ошибок всплывает в нескольких инструментах за год, это уже не случайная заноза в одном проекте, а дефект привычек.
Практический вывод для разработчиков простой: обновить Unsloth Studio до 2026.6.9 или новее и проверить, где в ML-пайплайнах автоматически включается trust_remote_code. Для внутренних платформ стоит явно разделять «прочитать метаданные модели» и «выполнить код из репозитория модели». Хорошая граница здесь скучная, зато полезная: sandbox, отдельные учетные данные, минимальные права, allowlist доверенных источников и логирование случаев, когда инструменту действительно нужно исполнять удаленный код.
Для бизнеса эта уязвимость Unsloth Studio показывает более широкий риск: цепочка поставки AI теперь включает не только Docker-образы, npm-пакеты и CI/CD, но и модельные репозитории. Пока команды будут относиться к моделям как к пассивным файлам, атаки будут прятаться в местах, где никто не ждет исполнения кода. Следующий зрелый шаг для MLOps — проверять модели так же придирчиво, как зависимости в production-сервисах.