Взлом Auto Mode в Claude Code через ZIP-архив: что упустила защита от опасных команд

Исследователь Johann Rehberger обошёл защиту Auto Mode в Claude Code через ZIP-архив с подставным struct.py: агент сам написал Python-декодер, который подключил вредоносный модуль вместо штатного, а в части попыток Auto Mode ещё и заблокировал команду очистки после того, как заражение уже случилось. Anthropic закрыла отчёт об уязвимости как информационный: авто-режим - это удобство с best-effort классификатором, не гарантия безопасности. Разбираюсь, как устроена атака, и заодно проверяю, не наступлю ли на те же грабли в своём агентском конвейере.

Как работает атака на Auto Mode в Claude Code

Атака Rehberger не ломает классификатор напрямую - она подсовывает агенту вредоносный файл под именем стандартного модуля Python, и Claude Code выполняет чужой код, даже не поняв, что это подмена. Работает до 80% попыток.

Сценарий такой. Агента просят засаммарить сайт, который выдаёт себя за архив записных книжек. Claude уговаривают дёрнуть страницу через curl вместо своего WebFetch - и получает в ответ HTTP 303 с редиректом на ZIP-архив. Внутри архива - метаданные каталога, README, семь Base85/zlib-закодированных JSON-записей, бинарник decoder-darwin и один файл, который туда подложили специально: struct.py.

Claude отказался запускать чужой decoder-darwin (тут защита сработала), но чтобы прочитать записи и выполнить задачу, написал свой Python-декодер. А декодеру для работы понадобился модуль struct - стандартная библиотека Python. Вот только Claude запустил свой скрипт из той же папки, куда распаковал архив, и Python подхватил не системный struct, а тот самый поддельный struct.py рядом. Достаточно было просто импортировать модуль - и вредоносный код выполнился.

Ключевая деталь тут не в хитрости архива, а в том, что Claude сам, добровольно, написал и запустил код в потенциально скомпрометированной директории - никто не заставлял агента писать декодер именно туда. Классификатор Auto Mode в этот момент видел вполне обычную команду "прочитать JSON-файлы Python-скриптом" и не имел механизма понять, что рядом лежит модуль-самозванец. Это и есть слепое пятно: классификатор оценивает команду саму по себе, а не файловое окружение, в котором она выполняется.

Почему это не классическая промпт-инъекция

В заголовках атаку называют промпт-инъекцией, но точнее - "confused environment attack": не текст обманывает модель, а окружение (рабочая папка с одноимённым файлом) обманывает интерпретатор Python, которым модель пользуется.

30 августа 2026 года, через три дня после первой публикации, комментатор hyperpape уточнил формулировку именно так - и это важно для защиты: тут не поможет фильтрация текста на признаки инъекции, потому что инъекции как таковой в привычном виде нет. Есть эксплуатация того, как Python ищет модули - сначала в текущей директории, потом в системных путях. Agent просто оказался в директории, которую контролирует атакующий.

Что упустил классификатор Auto Mode

Самое тревожное в разборе Rehberger - не сам факт компрометации, а то, что классификатор Auto Mode активно мешал её устранить: агент обнаружил заражение, но Auto Mode заблокировал команду очистки, посчитав её опасной, хотя вредоносный процесс к тому моменту уже был запущен.

По цифрам самого исследователя (выборка маленькая, сам это подчёркивает): вариант с C2-цепочкой через python3 -I -c сработал в 3 из 5 попыток, вариант с сабпроцессом claude -p - тоже в 3 из 5, а вариант с claude -p плюс подложенными файлами - в 4 из 5. Anthropic на отчёт ответила статусом "Informative" - не баг, а известное ограничение: Auto Mode - convenience-функция с best-effort классификатором, а не гарантия безопасности, и настоящая граница защиты - это изоляция на уровне ОС и контроль сетевого трафика, а не решения самой модели.

Тут есть и неудобное противоречие: глава Claude Code Борис Черни на выступлении в Y Combinator говорил, что промпт-инъекцию "мы больше не можем продемонстрировать". Разбор Rehberger вышел спустя время после этого заявления и наглядно его опровергает - пусть и не в чистом виде промпт-инъекции, а в соседнем классе атак на агента.

Чем рискует пайплайн с Auto Mode без дополнительных проверок

Auto Mode - это не пустая защита: в контролируемом эксперименте Anthropic с 1053 платными тестировщиками классификатор поймал 89% опасных команд против 13,6% у ручного ревью, а анализ реальных сессий за май-июнь 2026 показал 2,4% серьёзных инцидентов продакшен-уровня против 6,3% у сессий с ручным подтверждением. Я разбирал эту статистику отдельно, когда Auto Mode стал дефолтом для Pro, Max и Team-подписок с 14 августа 2026 года.

Но атака Rehberger показывает изнанку этой статистики: 89% - это средняя эффективность против широкого класса опасных команд, а не гарантия против целевой атаки, заточенной именно под слепое пятно классификатора. Если конвейер держит Auto Mode как единственную линию защиты, риск не в том, что классификатор ошибается часто, а в том, что при направленной атаке шанс обхода может быть кратно выше среднего - Rehberger получил 80% на своём сценарии.

Что я нашёл в своём агентском конвейере

Проверил тот самый blog-pipeline, который сейчас генерирует эту статью - и не обрадовался. В .claude/settings.json у меня разрешён Bash(rm:*) без ограничений, а sandbox.enabled стоит false:

{
  "permissions": {
    "allow": ["Bash(node:*)", "Bash(python3:*)", "Bash(rm:*)", "Read", "Glob", "Grep", "WebFetch", "WebSearch", "Write(/tmp/**)", "Write(data/tmp/**)"]
  },
  "sandbox": { "enabled": false }
}

Полез смотреть, откуда взялась именно такая конфигурация - и нашёл в git-логе конвейера историю почти в тему статьи. 11 июля 2026 года sandbox был включён, но с сетевым allowlist только на t.me: агенту разрешалось стучаться в Telegram и никуда больше. В тот же вечер, в 00:31, коммит "fix: bypassPermissions в headless-прогоне, sandbox off" убрал и allowlist, и сам sandbox - я пытался обойти баг workspace trust на сервере через --permission-mode bypassPermissions. Через две минуты, в 00:33, следующий коммит откатил permission-mode обратно на acceptEdits: bypassPermissions оказался запрещён под root. А вот sandbox обратно так и не включили - откат вернул только один параметр из двух, второй остался как временный костыль. То есть sandbox.enabled: false, который я нашёл в начале разбора, - не осознанное решение в пользу удобства, а забытый хвост чужого бага полугодовой давности.

Плюс мои cron-обёртки дёргают claude -p "/blog-draft <id>" --permission-mode acceptEdits без участия человека - то же самое для сбора беклога, проверки черновиков и правок по комментам. Это не Auto Mode в смысле того самого классификатора Anthropic, а мой собственный плоский allow-лист, но логика та же: агент действует без ручного подтверждения, полагаясь на список разрешённых команд. И у меня этот список даёт rm без ограничений на директорию, а песочница выключена - то есть ровно та конфигурация, от которой Rehberger и сам Anthropic советуют защищаться в первую очередь.

Читает ли мой пайплайн внешние сайты и архивы, как в сценарии атаки? WebSearch и WebFetch в allow-листе есть, значит теоретически да - на этапе ресёрча тем и черновиков агент ходит по внешним URL. Правда, curl у меня не в allow-листе (только Bash(node:*) и Bash(python3:*)), так что сценарий "обмани через curl вместо WebFetch" в лоб не повторить - но это везение конфигурации, а не осознанная защита.

Неприятно писать про дыру в собственном конвейере в статье, которую этот же конвейер и сгенерировал headless, без меня за плечом - но именно так и всплывают такие вещи. Пока пишешь про чужой инцидент, начинаешь примерять его на свой allow-лист, и там, где рассчитывал увидеть аккуратный список разрешений, находишь Bash(rm:*) без единого ограничения по пути. Не самое приятное чувство, но лучше найти это в черновике статьи, чем в логах после того, как что-то пойдёт не так.

Как защитить агентский конвейер от похожей уязвимости

Три вещи, которые я после разбора беру в работу первым делом: сузить Bash(rm:*) до конкретных путей вроде data/tmp/**, включить sandbox.enabled: true там, где это не ломает cron-скрипты, и не заводить агенту рабочую директорию, куда одновременно попадают скачанные архивы и исполняемый код агента - Rehberger эксплуатировал именно это соседство.

Общий принцип из разбора Anthropic и Rehberger одинаковый: approval-классификатор, будь то встроенный Auto Mode или самодельный allow-лист, снижает число проблем в среднем, но не заменяет изоляцию среды. Песочница, ограничение сетевого доступа и мониторинг действий агента - это не опция "на будущее", а обязательная вторая линия для любого конвейера, где агент запускает код без человека на каждом шаге. Разбор атаки на Auto Mode как дефолт стоит читать вместе с этим текстом - там цифры о пользе классификатора, здесь - о его слепом пятне.

Похожая логика "агент был уверен, что всё под контролем" уже подводила меня и в других разборах: три реальные кибератаки, которые изучила сама Anthropic, показывают, что агентам не хватает не мощности, а внешних ограничителей. А когда я разбирал случай, где мой собственный агент одной командой снёс папку проекта, решением стал именно PreToolUse guard - внешняя проверка, которая не доверяет решению модели вслепую. Похоже, после этого разбора PreToolUse guard в blog-pipeline тоже придётся докрутить - Bash(rm:*) без разбора путей теперь выглядит не упрощением, а дырой.

Частые вопросы

Нужно ли отключать Auto Mode в Claude Code после этой атаки? Нет, но нельзя считать его единственной защитой: Anthropic сама называет Auto Mode удобством с best-effort классификатором, а не гарантией безопасности, и советует держать агента в песочнице или контейнере с ограниченным сетевым доступом.

Что делать, если Auto Mode заблокировал команду очистки после компрометации? Останавливать процесс агента снаружи - через систему, а не через сам Claude Code, потому что классификатор может продолжать считать команду очистки опасной уже после того, как заражение произошло.

Атака Rehberger работает только на Claude Code? Нет, механизм - это подмена модуля Python одноимённым файлом в рабочей папке, а не баг конкретно Claude Code. Под угрозой любой агент, который пишет и выполняет код в директории, куда может попасть чужой файл.