ИИ-агент взломал Hugging Face. Другие ИИ-агенты разгребали логи :D

Скайнет пока отменяется. Кожаные всё ещё у пульта — просто у каждого теперь свой рой агентов :D

Один такой рой проломил часть продовой инфраструктуры Hugging Face. Другой, уже со стороны HF, помог понять, куда первый успел залезть и что утащил.

Короткий пересказ вышел в «Лосе в проде». Здесь разбираю цепочку целиком: почему «датасет» вообще смог выполнить код, чем агентная атака отличается от обычного скрипта и почему защитникам понадобилась локальная open-weight модель.

Основной источник — официальное раскрытие Hugging Face от 16 июля 2026 года. Компания ещё продолжала оценивать влияние на партнёрские и клиентские данные, поэтому ниже я отдельно разделяю подтверждённые факты и выводы из них.

Что Hugging Face подтвердили

HF обнаружили вторжение в часть production-инфраструктуры. Они подтвердили несанкционированный доступ к ограниченному набору внутренних датасетов и нескольким credentials, которые использовали их сервисы.

На момент публикации компания не нашла признаков изменения публичных пользовательских моделей, датасетов или Spaces. Цепочку поставки — контейнерные образы и опубликованные пакеты — проверили и назвали чистой.

Оценка влияния на данные партнёров и клиентов ещё шла. Потенциально затронутым сторонам обещали сообщить напрямую.

Это важная граница. Фраза «взломали Hugging Face» звучит так, будто все модели на Hub ночью получили по бэкдору. Официальный отчёт такого не говорит. Инцидент был серьёзным, но подтверждённый контур уже.

Как датасет вообще выполняет код

Датасет хочется представить пассивной пачкой JSON, CSV и картинок. На AI-платформе вокруг него живёт обработка:

• загрузчик понимает формат и достаёт файлы;
• конфигурация описывает колонки, шаблоны и преобразования;
• worker строит превью и вычисляет статистику;
• иногда поддерживается пользовательская логика для нестандартного формата.

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

По данным Hugging Face, вредоносный датасет использовал сразу два пути выполнения кода:

1. remote-code dataset loader;
2. template injection в конфигурации датасета.

Оба пути сработали внутри pipeline обработки и дали выполнение кода на processing worker.

вредоносный датасет
        ↓
обработка превью и конфигурации
        ↓
выполнение кода на worker
        ↓
доступ уровня node
        ↓
credentials → соседние кластеры

Сам файл не ожил и не пошёл по сети. Уязвимая обработка доверилась управляемым данным. Это тот же класс проблемы, который много лет встречается в импорте архивов, шаблонизаторах и плагинах. AI-платформа добавила новые форматы и огромный поток чужого контента.

От worker до внутренних кластеров

После первого выполнения атакующий поднялся до доступа на уровне узла. Дальше началась знакомая часть любой облачной атаки:

• поиск credentials в окружении и файловой системе;
• сбор облачных и кластерных токенов;
• проверка доступных сервисов;
• боковое перемещение;
• закрепление в нескольких внутренних кластерах.

Необычным был исполнитель. Кампанию вела автономная agent framework, похожая на agentic security-research harness. Hugging Face не знают, какая именно LLM стояла внутри.

Система выполнила многие тысячи отдельных действий через рой короткоживущих песочниц. Command-and-control переезжал между публичными сервисами. Кампания шла в течение выходных и затронула несколько кластеров.

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

Почему семнадцать тысяч событий — отдельная проблема

В action log осталось больше 17 000 записанных событий. Это команды, ответы, перемещения, обращения к сервисам и следы временных окружений.

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

• какое действие было первым;
• какие credentials агент только увидел, а какие использовал;
• какие хосты и кластеры ответили;
• где лежали ложные следы;
• что изменилось;
• какие токены нужно отозвать немедленно.

При ручной работе аналитик строит timeline, связывает идентификаторы и постоянно переключается между источниками. Семнадцать тысяч событий превращают это в несколько дней очень внимательного чтения. Атакующий тем временем продолжает работать с машинной скоростью.

Атаку заметил ИИ

Первый сигнал появился благодаря AI-assisted detection. У Hugging Face LLM участвуют в разборе security telemetry и помогают отделять реальные аномалии от ежедневного шума.

Компрометацию показала корреляция нескольких сигналов. То есть модель не просто увидела строку с известной сигнатурой, а помогла связать события в подозрительную последовательность.

После обнаружения HF запустили LLM-агентов уже по полному action log. Они восстанавливали timeline, извлекали indicators of compromise, сопоставляли затронутые credentials и отделяли реальный ущерб от decoy activity.

По оценке компании, анализ занял часы вместо нескольких дней.

Получилась почти симметричная сцена: агент атакующего генерирует огромный поток действий, агент защитника помогает этот поток свернуть обратно в объяснимую историю.

Safety-фильтр вышел на перекур

Сначала расследование попробовали вести через frontier-модели за коммерческими API.

Для форензики им нужно было отправлять настоящие команды атакующего, exploit payloads и C2-артефакты. Safety-системы провайдеров видели опасный код и блокировали запросы. Отличить инженера, который расследует атаку, от человека, который просит помочь с атакой, они не смогли.

Хакеру политику acceptable use уже было поздновато показывать :D

В итоге анализ перенесли на GLM 5.2 — open-weight модель, запущенную внутри инфраструктуры Hugging Face.

Это решило две задачи:

1. модель могла работать с материалами инцидента без блокировки внешнего провайдера;
2. команды атакующего и упомянутые в логах credentials не покидали защищённый контур.

HF отдельно уточняют: этот опыт не является аргументом против safety-мер облачных моделей. Он показывает операционный пробел. У команды реагирования должен быть заранее проверенный инструмент для задач, где опасные артефакты являются предметом расследования.

Во время пожара поздно впервые собирать локальный inference, согласовывать модель и выяснять, помещается ли контекст в доступную VRAM.

Что сделали после обнаружения

Hugging Face перечислили следующие действия:

• закрыли оба пути выполнения кода, через которые произошёл initial access;
• удалили присутствие атакующего из затронутых кластеров;
• пересобрали скомпрометированные узлы;
• отозвали и сменили затронутые credentials и токены;
• начали более широкую предупредительную ротацию секретов;
• добавили guardrails и более строгие admission controls;
• усилили detection и paging для критических сигналов;
• подключили внешних специалистов по форензике;
• сообщили об инциденте правоохранительным органам.

Для пользователей рекомендация короткая: сменить access tokens и проверить недавнюю активность аккаунта. О подозрительных событиях HF просят писать на security@huggingface.co.

Что здесь действительно нового

Каждый отдельный технический элемент существовал раньше: code execution, кража токенов, lateral movement, C2 на публичных сервисах.

Новая часть — экономика и темп кампании.

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

Защита получает похожее преимущество. LLM умеет свернуть тысячи событий, извлечь сущности и помочь построить timeline. Но защитнику нужны объяснимость, сохранность доказательств, доступ к секретам и юридические ограничения. Атакующий такими вещами себя обычно не утруждает.

Получается асимметрия: наступательный агент свободно перебирает варианты, а оборонительный может упереться в политику API в самый неприятный момент.

Локальная модель как часть аварийного набора

После этой истории я ещё сильнее смотрю в сторону локальных моделей.

LLM внутри защищённого контура уже тянет на часть аварийного набора инфраструктуры — рядом с бэкапами, runbook и людьми, которым потом всё это разгребать.

Но строка «скачаем open-weight модель» в runbook не спасёт. До инцидента нужно проверить:

1. Развёртывание. Модель действительно запускается на доступном железе без внешних API.
2. Контекст. В неё помещается нужный объём логов или работает понятная схема разбиения.
3. Инструменты. Агент умеет читать хранилище событий, но не может незаметно менять оригиналы.
4. Секреты. Промпты, кеш и трассы остаются внутри контура.
5. Качество. На старых инцидентах измерены полнота timeline и количество ложных выводов.
6. Доказательства. Каждый вывод ссылается на исходные события.
7. Ресурсы. Зарезервированы GPU, диск и время инженера, который умеет всё это поднять.

Модель не заменяет форензика. Она уменьшает объём механической работы и помогает быстрее находить куски, которые должен проверить человек.

Минимальный runbook для agentic-инцидента

Если атака состоит из тысяч автономных действий, я бы добавил к обычному реагированию несколько пунктов.

Сохранить сырой журнал

До активной очистки нужен неизменяемый снимок telemetry и action log. Агенту для анализа выдаётся копия с read-only доступом.

Связать временные окружения

Короткоживущие sandbox могут исчезнуть раньше, чем начнётся расследование. Нужны общие идентификаторы запусков, сетевых запросов и credentials.

Отделить наблюдение от вывода

Агент должен показывать, какое событие подтверждает каждый шаг timeline. «Вероятно, токен использовали» и «вот запрос с этим токеном» — разные уровни уверенности.

Ограничить действия защитного агента

Аналитическому агенту не обязательно давать право отзывать токены и пересобирать узлы. Он готовит список и доказательства; рискованные операции проходят отдельное подтверждение.

Иметь запасной inference

Облачная модель может быть недоступна из-за сети, политики или характера данных. Локальный путь должен быть проверен заранее на реальном объёме логов.

Если у вас есть токен Hugging Face

Практические действия после такого раскрытия довольно скучные, а значит, полезные:

• отозвать старые токены и выпустить новые;
• проверить список недавней активности;
• удалить неиспользуемые credentials;
• разделить токены разработки, CI и production;
• ограничить scope до реально нужных операций;
• убедиться, что секреты не записаны в репозиториях и логах;
• проверить downstream-системы, куда токен мог быть скопирован.

Ротация на стороне HF не заменяет ротацию вашей копии секрета. Особенно если она два года честно лежала в старом CI, который «вроде уже не запускается».

Огнетушитель покупают до пожара

Этот инцидент хорошо показывает обе стороны agentic AI без презентационного блеска.

Атакующий получил масштаб, терпение и возможность менять план. Защитники получили способ разобрать больше 17 000 событий за часы. Затем их облачные инструменты остановились на правилах безопасности, и работу спас заранее доступный класс локальных моделей.

Автономные offensive tools уже не теоретический сценарий. Защитные агенты тоже становятся рабочим инструментом. Между ними остаётся инфраструктура: журналы, права, изоляция, модели, eval-наборы и люди, которые отвечают за решение.

Огнетушитель тоже покупают до пожара. Модель, похоже, теперь тоже :D

Источники: официальный разбор Hugging Face и исходный пост в Telegram.