ZCode упаковал 42 411 файлов в архив, который мог открыть только Zhipu

18 сентября 2026 года разработчик, пишущий под именем ferstar, опубликовал разбор ZCode — настольного ИИ-агента для программирования, созданного китайским разработчиком моделей Zhipu AI, после того как заметил, что скрытая папка в его домашнем каталоге превысила 700 МБ. Внутри он обнаружил зашифрованный архив на 313 МБ, содержащий 42 411 файлов, взятых из рабочей области объёмом 345 МБ, причём 86,6% этой рабочей области составляла история Git; архив был упакован клиентом и подготовлен к загрузке в объектное хранилище Alibaba Cloud. Архив был запечатан ключом, который могли распаковать только серверы Zhipu, а в клиенте не было никакого переключателя, который остановил бы его создание. Zhipu принесла извинения в тот же вечер. Полная запись, вместе с оценкой достоверности и статусом ущерба, указанными в самом архиве, находится в Orca AI Incident Archive, где каждый задокументированный ИИ-инцидент регистрируется вместе с указанными источниками.

ZCode — это настольный агент Zhipu для программирования: он читает проект, выполняет shell-команды и пишет код. Компания торгуется в Гонконге под тикером 2513.HK, а своё международное подразделение продвигает под брендом Z.ai — именно это имя встречается на серверах ZCode, которые проверил ferstar. The Paper — шанхайское новостное издание, которое позже взяло интервью у него и ещё нескольких разработчиков, — сообщает, что его пост назывался примерно так: «Приподнимая завесу над тем, как ZCode молча загружает всю историю Git», и что он распространился по китайским группам разработчиков в течение нескольких часов после публикации.

Что было внутри скрытой папки?

Собственные цифры Ferstar — это стержень дела, и их последовательно воспроизводили The Next Web, InfoQ и финансовая редакция China National Radio. Архив в его каталоге контрольных точек ZCode занимал 313 МБ. Файл состояния рядом с ним фиксировал рабочее пространство объёмом около 345 МБ, содержащее 42 411 файлов. .git — этот каталог дал 86,6% общего объёма: 196,1 МБ кэша Git для хранения больших файлов, 102,2 МБ объектов Git, содержащих полную историю коммитов, и небольшая доля reflog. На собственно исходный код и документацию пришлось примерно 13,4%.

Это различие важно, потому что история Git — это место, где обычно сохраняется материал, удалённый из текущего дерева. В статье это прямо подчёркивается: архив такого рода может содержать историю изменений проекта начиная с первого коммита, удалённое содержимое, незакоммиченные черновики и более старые файлы конфигурации, включая учётные данные, которые были удалены из кода давным-давно, но остаются в более ранних коммитах и в кэше больших файлов.

Собственный архив Ferstar размером 313 МБ так и не покинул его машину. В его журнале состояния было показано 564 неудачных попытки загрузки, и он застрял в состоянии ожидания, превысив ограничение по размеру. Чтобы проверить, работает ли конвейер вообще, он попробовал небольшой публичный репозиторий из 538 файлов; этот снимок сжался и зашифровался примерно до 15 КБ и был принят сервером. Именно эта передача в записи подтверждена как завершённая от начала до конца, и именно она превращает находку из упражнения по чтению кода в эксфильтрацию с продемонстрированным принимающим концом.

Сбор не был привязан ни к какому действию, которое пользователь распознал бы как «загрузку моего репозитория». Согласно реконструкции ferstar, один триггер срабатывал перед каждым запросом, отправляемым модели, а другой выполнялся как задача обновления Repo Wiki. Удаление ожидающего архива не останавливало его: в публикации в сообществе разработчиков Tencent Cloud указано, что пакет был пересобран в течение 30 минут, а счётчик сбоев увеличился с 564 до 565. Единственной надёжной остановкой, которую нашёл автор, было сделать каталог чекпоинтов недоступным для записи, чтобы сбор завершался ошибкой на записи на диск, ценой потери отката к чекпоинтам и интерфейса таймлайна.

Ключ, который мог бы использовать только поставщик

Шифрование было классическим конвертным шифрованием, и именно эту часть пользователи не могли обойти. Реконструкция InfoQ, основанная на обратной разработке ferstar, описывает, как клиент получал ID снимка, открытый ключ RSA и учётные данные для загрузки в Alibaba Cloud OSS с zcode.z.ai, локально упаковывал и шифровал рабочее пространство, а затем отправлял шифротекст напрямую в OSS. Содержимое шифровалось с помощью AES-256-CTR; симметричный ключ был обёрнут по схеме RSA-OAEP-SHA256 открытым ключом сервера, закрытая половина которого оставалась в облаке Zhipu.

Маршрутизация не менее важна, чем криптография. Поскольку клиент загружал данные напрямую в Alibaba Cloud, а не через собственные серверы приложений Zhipu, трафик не проходил через сервис Zhipu, который мог бы его логировать или фильтровать, поэтому на пути не было ни одного сервиса Zhipu, способного логировать или фильтровать то, что уходило. А поскольку закрытый ключ никогда не находился на устройстве, ferstar не мог открыть свой собственный архив: The Next Web сообщает, что он перепробовал все закрытые ключи на своей машине и потерпел неудачу. В своём посте он описал эту схему как ключ, которым может пользоваться только сервер и у которого есть лишь одно назначение.

Две настройки в клиенте выглядели так, будто должны были это остановить, но ни одна не сработала. Переключатель «optimise experience» определял, можно ли использовать данные для обучения модели; переключатель «repository snapshot indexing» определял, строит ли сервер индекс по уже поступившим снимкам. Оба действуют после этапа захвата. Ferstar обнаружил, что захват работает безусловно, а The Next Web сообщает, что, по его прочтению политики конфиденциальности, в ней описывался сбор текста бесед и файлов, но ничего не говорилось об автоматических снимках рабочего пространства, содержащих полную историю Git.

Объяснение, которое дал Zhipu, и четыре дня после него

Zhipu ответила в тот же день — через официальную группу пользователей ZCode, а не через пресс-релиз. Как сообщила Global Times, а Security Inside перепечатало материал, компания связала такое поведение с функцией под названием индексация кодовой базы, которая поддерживает локальное индексирование, восстановление сеанса из контрольной точки, откат версий и генерацию Repo Wiki, и заявила, что именно этап Repo Wiki стал причиной загрузки репозиториев в облако. Функция была включена по умолчанию с момента запуска. Zhipu заявила, что загруженные данные использовались только для генерации страницы Repo Wiki и были немедленно уничтожены после этого, что они не сохранялись и не использовались для обучения, и принесла извинения пострадавшим пользователям. Компания пообещала открыть исходный код ZCode, пригласить сторонних специалистов для проверки и опубликовать результаты, а также предложила каждому пользователю ZCode один дополнительный сброс недельной квоты в качестве компенсации.

Исправление появилось на следующий день. The Paper сообщает, что ZCode 3.14.0 вышел 19 сентября с записью в журнале изменений: «исправлена проблема аномальной загрузки вики репозитория», и что ferstar в тот же день подтвердил, что цепочка загрузки и её эндпоинт исчезли. 20 сентября платформа MaaS от Zhipu анонсировала предстоящую опцию нулевого хранения, при которой входные и выходные данные не будут храниться статически; The Paper отмечает, что она подключается по заявке, не распространяется на Batch API и File API и по-прежнему допускает хранение в течение 30 дней или дольше, если этого требуют закон или расследование злоупотреблений. 21 сентября исходный код клиента стал публичным на GitHub под лицензией Apache 2.0, охватывая настольное приложение, веб-клиент, бэкенд, agent CLI и среду выполнения агента.

Были заказаны два аудита, а их выводы опубликованы в виде резюме. Китайская академия информационных и коммуникационных технологий обнаружила, что бакет zcode-prod сервиса Alibaba Cloud OSS находится в том, что Zhipu называет состоянием нулевых данных. Компания по безопасности NSFOCUS сообщила, что все объекты данных и сам бакет были удалены, и что она не обнаружила в ZCode 3.14.0 оставшегося пути, который мог бы запустить снимок локального репозитория или отправить файлы вовне. Полный отчет об оценке не появился, и, по сообщению The Next Web, Zhipu не назвала дату его публикации.

Клиент, который заявил о большем, а затем отозвал это.

Самое серьёзное утверждение о фактическом ущербе поступило не от ferstar. 19 сентября, по данным China National Radio, Taiyuan Chengming Technology направила Zhipu юридическое письмо под номером Chengming [2026] Legal Letter No. 1, которое подробно воспроизвёл ChainCatcher. Компания сообщила, что шесть её рабочих пространств для программирования были загружены без согласия — 34 500 файлов и около 425 МБ в открытом виде — и перечислила полный исходный код, системную архитектуру, историю версий, пароли к базам данных, учётные данные облачных сервисов и персональные данные сотрудников. Она сообщила, что седьмое рабочее пространство из 1 947 файлов и примерно 144 МБ было упаковано и зашифровано, но 32 повторные попытки загрузки завершились неудачей. Она также отметила, что её клиент обновился до версии 3.12.3 16 сентября, однако загрузки всё ещё обнаруживались в 00:28 18 сентября — утром того дня, когда Zhipu принесла извинения.

В письме был задан вопрос, на который аудиты не дают ответа: покидали ли данные страну. Chengming заявил, что сетевые запросы ZCode были направлены на сингапурское юрлицо, тогда как соглашение об оказании услуг было подписано с Beijing Zhipu Huazhang, и в письме Zhipu попросили указать, какая сторона несет ответственность и имела ли место какая-либо передача или хранение за пределами материкового Китая. В письме были изложены двенадцать требований, включая удаление всех загруженных данных и производных от них, кэшей и резервных копий с предоставлением письменного подтверждения; объяснение того, куда ушли данные и передавались ли они третьим сторонам или использовались ли для обучения; описание того, как хранится закрытый ключ, и предоставление журналов доступа; определение точного объема утверждения о том, что данные «уничтожены»; и письменное обязательство больше никогда не загружать данные. В нем Zhipu дали срок до 10 октября для ответа в письменной форме и оставили за собой право требовать возмещения убытков и обращаться с жалобами в регулирующие органы. Caixin Global сообщает, что Zhipu назвала эти обвинения не соответствующими действительности.

Через два дня Chengming отозвала их. Финансовая служба China National Radio сообщает, что 21 сентября компания опубликовала опровержение, в котором говорилось, что её прежние заявления опирались на ошибочные доказательства, неточное описание и преувеличенные формулировки, что они нанесли ущерб репутации Zhipu и что компания прекратит общаться со СМИ. Согласно The Next Web, об отзыве также сообщил Reuters. Архивная запись об этом инциденте датирована 18 сентября, днём обнаружения; письмо, указанный в нём срок 10 октября и опровержение появились после этой даты. Согласно публичным данным по состоянию на конец октября, ни одна названная компания не подтверждает утверждение о том, что её секреты были раскрыты.

Открытый релиз с сотрённой историей

Открытие исходного кода клиента было средством, на которое Zhipu опирался сильнее всего, и у него был изъян. The Paper сообщает, что опубликованный репозиторий содержит два коммита: пустой начальный коммит и единственный коммит, добавляющий около 6 973 файлов и 1,03 млн строк, при этом пул-реквесты заблокированы, а issues закрыты. Каким был конвейер загрузки на момент выпуска и в какие релизы он входил — этого нет в истории, которую теперь может прочитать кто угодно.

Последующее сообщение самого Ferstar делает это ограничение явным. Он подтвердил, что конвейер загрузки был удалён, а оставшийся механизм контрольных точек выполняет только локальные операции Git, после чего указал, что аудит бакета может и чего не может показать: очистка и удаление бакета — правильная мера по ограничению ущерба, но проверка третьей стороной, выполненная после 20 сентября, может установить лишь то, что на тот момент бакет был пуст. Она не может восстановить, что проходило через него до 18 сентября, было ли что-либо расшифровано, скопировано или сохранено в резервную копию, а также как долго работал конвейер. Утверждение об удалении по-прежнему в значительной степени опирается на слова стороны, выполнившей удаление.

Анализ InfoQ перечисляет вопросы, которые остаются открытыми, в тех же формулировках: сколько снимков репозитория было успешно загружено и сколькими пользователями, как долго хранились объекты, какие серверные системы или сотрудники могли их расшифровать, существует ли полный журнал доступа и охватило ли удаление резервные копии и другие копии. В нём также отмечается, чем ZCode остаётся после исправления. Собственный NOTICE проекта предупреждает, что общая среда выполнения агента по умолчанию не обеспечивает песочницу на уровне операционной системы, а клиент сохраняет поверхности оболочки, терминала, Git, MCP, плагинов и встроенного браузера, которые могут читать файлы, запускать процессы и обращаться к сети в пределах разрешений учётной записи пользователя.

Что установлено, а на что не отвечает ни один источник

Сам механизм не оспаривается. Собственные заявления Zhipu признают, что данные репозитория были загружены, что функция была включена по умолчанию и что данные попали в облачное хранилище, контролируемое компанией. Измерения Ferstar, извинения поставщика, два заказанных аудита и выпуск открытого исходного кода — все описывают одну и ту же цепочку. Ничто в материалах не оспаривает, что рабочие пространства покидали машины без работоспособного способа отказа. Зафиксированный в материалах вред является реализованным, а не гипотетическим: передачи произошли, и люди, чей код находился внутри них, не могли ни предотвратить их, ни проверить.

Спорным — или просто неизвестным — остаются масштаб и последствия. Ни один источник не указывает, сколько пользователей использовали затронутые настройки по умолчанию, как долго конвейер работал до 18 сентября или был ли когда-либо расшифрован какой-либо загруженный объект. Заверение Zhipu о том, что данные уничтожались после генерации вики и никогда не использовались для обучения, — это заявление самой компании; выводы CAICT и NSFOCUS описывают состояние бакета после исправления, а не то, что через него проходило. Архив ставит этому делу оценку A за документацию, и эта документация сильна в описании механизма, но скудна в отношении охвата.

Что изменилось, а что нет

Коммерческий ущерб не заставил себя ждать. Китайское национальное радио сообщает, что акции Zhipu, котирующиеся в Гонконге, упали на 1,79% 21 сентября, на 6,55% 22 сентября и на 12,4% 23 сентября — совокупное снижение более чем на 16% за три торговые сессии, — а также что Zhipu не сообщила, сколько пользователей пострадало и были ли исторические данные расшифрованы или сохранены в резервных копиях.

Что на самом деле получил пользователь ZCode за четыре дня после обнаружения:

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

• 19 сентября: ZCode 3.14.0, из которого удалили Repo Wiki и вырезали локальную генерацию снимков и путь загрузки. Ferstar подтвердил на следующий день, что цепочка загрузки исчезла.

• 20 сентября: анонсирована опция нулевого хранения для платформы MaaS от Zhipu, подключаемая по выбору, за исключением Batch API и File API, и по-прежнему подпадающая под требуемое законодательством хранение в течение 30 дней или более.

• 21 сентября: ZCode опубликован под лицензией Apache 2.0 без истории коммитов, предшествовавших инциденту; в сводках CAICT и NSFOCUS сообщается, что хранилище пусто, а путь исходящего трафика отсутствует.

Ничто из этого не имеет обратной силы. Конкретные вопросы, поднятые Чэнмином — куда ушли данные, кто мог их расшифровать, покинули ли они страну и что охватывало «уничтожение», — были изложены письменно со сроком 10 октября, а затем отозваны вместе с компанией, которая их задала. Zhipu пообещала полный отчёт о независимой оценке без указания даты. Пока такой отчёт не появится, единственным публичным описанием того, что конвейер сделал с полученными данными, остаётся версия компании, которая его построила, а единственным независимо измеримым артефактом — файл размером 313 МБ, который 564 раза не смог покинуть ноутбук одного разработчика.