ZCode empacotou 42.411 arquivos em um arquivo compactado que só a Zhipu conseguia abrir

Em 18 de setembro de 2026, um desenvolvedor que escreve sob o nome ferstar publicou uma análise técnica de ZCode, o agente de programação com IA para desktop criado pela desenvolvedora chinesa de modelos Zhipu AI, depois de perceber que uma pasta oculta em seu diretório home tinha ultrapassado 700 MB. Dentro dela, ele encontrou um arquivo criptografado de 313 MB contendo 42.411 arquivos extraídos de um espaço de trabalho de 345 MB, com 86,6% de seu conteúdo sendo histórico do Git, empacotado pelo cliente e preparado para envio ao armazenamento de objetos do Alibaba Cloud. O arquivo foi selado com uma chave que somente os servidores da Zhipu poderiam desbloquear, e o cliente não oferecia nenhuma opção que impedisse sua criação. A Zhipu pediu desculpas na mesma noite. O registro completo, com o grau de confiança e o status de dano do próprio arquivo, está no Orca AI Incident Archive, que registra cada incidente de IA documentado com suas fontes citadas.

O ZCode é o agente de codificação para desktop da Zhipu: ele lê um projeto, executa comandos de shell e escreve código. A empresa é negociada em Hong Kong sob o ticker 2513.HK e usa a marca Z.ai para sua operação internacional, o nome que aparece nos servidores do ZCode que ferstar inspecionou. The Paper, veículo de notícias de Xangai que o entrevistou e a vários outros desenvolvedores depois disso, relata que sua postagem tinha o título, aproximadamente, “Levantando a cortina sobre o upload silencioso de todo o histórico do Git pelo ZCode”, e que ela se espalhou por grupos de desenvolvedores chineses em poucas horas após a publicação.

O que estava dentro da pasta oculta

Os números do próprio Ferstar são a espinha dorsal do caso, e foram reproduzidos de forma consistente por The Next Web, InfoQ e pela editoria financeira da China National Radio. O arquivo no diretório de checkpoints do ZCode dele tinha 313 MB. O arquivo de status ao lado registrava um workspace de cerca de 345 MB e 42.411 arquivos. O diretório .git foi responsável por 86,6% do volume: 196,1 MB de cache de armazenamento de arquivos grandes do Git, 102,2 MB de objetos Git que carregam o histórico completo de commits e uma pequena fração de reflog. O código-fonte e a documentação de fato somavam cerca de 13,4%.

A distinção importa porque o histórico do Git é onde tende a sobreviver o material que foi removido da árvore atual. O relato do The Paper deixa o ponto claro: um arquivo desse tipo pode carregar o histórico de edições de um projeto desde o primeiro commit, conteúdo excluído, rascunhos não commitados e arquivos de configuração antigos, incluindo credenciais que foram removidas do código há muito tempo, mas permanecem em commits anteriores e no cache de arquivos grandes.

O próprio arquivo de 313 MB de Ferstar nunca saiu da máquina dele. Seu log de status mostrava 564 tentativas de upload malsucedidas, e ele havia travado em um estado pendente, acima do limite de tamanho. Para testar se o pipeline funcionava de fato, ele tentou um pequeno repositório público de 538 arquivos; esse snapshot foi comprimido e criptografado para cerca de 15 KB e foi aceito pelo servidor. Essa transferência é a única no registro confirmada como concluída de ponta a ponta, e é o que transforma a descoberta de um exercício de leitura de código em uma exfiltração com uma extremidade receptora comprovada.

A captura não estava vinculada a nenhuma ação que um usuário reconheceria como "enviar meu repositório". De acordo com a reconstrução de ferstar, um gatilho era disparado antes de cada prompt enviado ao modelo, e outro era executado como uma tarefa de atualização do Repo Wiki. Excluir o arquivo pendente não a interrompeu: um relato na comunidade de desenvolvedores do Tencent Cloud registra que o pacote foi reconstruído em até 30 minutos e o contador de falhas passou de 564 para 565. A única parada confiável que esse autor encontrou foi tornar o diretório de checkpoint não gravável, de modo que a captura falhava na gravação em disco, ao custo de perder o rollback de checkpoint e a interface de linha do tempo.

Uma chave que apenas o fornecedor poderia usar

A criptografia era criptografia de envelope clássica, e essa era a parte que os usuários não conseguiam contornar. A reconstrução da InfoQ, baseada na engenharia reversa de ferstar, descreve o cliente obtendo um ID de snapshot, uma chave pública RSA e credenciais de upload do Alibaba Cloud OSS em zcode.z.ai, empacotando e criptografando o workspace localmente e, em seguida, enviando o texto cifrado diretamente ao OSS. O conteúdo foi criptografado com AES-256-CTR; a chave simétrica foi encapsulada com RSA-OAEP-SHA256 sob a chave pública do servidor, cuja metade privada permaneceu na nuvem da Zhipu.

O roteamento é tão significativo quanto a criptografia. Como o cliente fez o upload diretamente para o Alibaba Cloud, em vez de passar pelos próprios servidores de aplicação da Zhipu, o tráfego não passou por um serviço da Zhipu que pudesse registrá-lo ou filtrá-lo, de modo que nenhum serviço da Zhipu ficou no caminho para registrar ou filtrar o que saía. E como a chave privada nunca esteve no dispositivo, ferstar não conseguiu abrir o próprio arquivo: The Next Web relata que ele tentou todas as chaves privadas em sua máquina e não conseguiu. Ele descreveu o arranjo em sua publicação como uma chave que apenas o servidor pode usar, com um único propósito.

Duas configurações no cliente pareciam que deveriam ter impedido isso, e nenhuma delas impediu. O alternador “otimizar experiência” controlava se os dados podiam ser usados para treinamento de modelo; o alternador “indexação de snapshots do repositório” controlava se o servidor criava um índice sobre snapshots que já haviam chegado. Ambos atuam a jusante da captura. Ferstar descobriu que a captura estava rodando incondicionalmente, e The Next Web relata que sua leitura da política de privacidade constatou que ela descrevia a coleta de texto de conversas e arquivos, mas não dizia nada sobre snapshots automáticos do espaço de trabalho carregando o histórico completo do Git.

A explicação que a Zhipu deu, e os quatro dias depois dela

A Zhipu respondeu no mesmo dia, pelo grupo oficial de usuários do ZCode, em vez de um comunicado à imprensa. Conforme noticiado pelo Global Times e republicado pelo Security Inside, a empresa atribuiu o comportamento a um recurso chamado indexação de base de código, que oferece suporte a indexação local, restauração de checkpoint de sessão, reversão de versão e geração do Repo Wiki, e afirmou que foi a etapa do Repo Wiki que disparou os envios de repositórios para a nuvem. O recurso estava ativado por padrão desde o lançamento. A Zhipu disse que os dados enviados eram usados apenas para gerar a página do Repo Wiki e eram destruídos imediatamente depois, que não eram armazenados nem usados para treinamento, e pediu desculpas aos usuários afetados. Prometeu abrir o código-fonte da base de código do ZCode, convidar terceiros para fazer a revisão e publicar os resultados, além de oferecer a cada usuário do ZCode uma redefinição extra da cota semanal como compensação.

A correção chegou no dia seguinte. O The Paper informa que o ZCode 3.14.0 foi lançado em 19 de setembro com uma entrada no changelog dizendo "corrige o problema de upload anormal do wiki do repositório", e que a ferstar confirmou no mesmo dia que a cadeia de upload e seu endpoint haviam desaparecido. Em 20 de setembro, a plataforma MaaS da Zhipu anunciou uma futura opção de retenção zero, segundo a qual entradas e saídas não seriam armazenadas estaticamente; O The Paper observa que ela é opcional por aplicação, exclui a Batch API e a File API e ainda permite retenção de 30 dias ou mais quando a lei ou a investigação de abuso exigir. Em 21 de setembro, o código-fonte do cliente tornou-se público no GitHub sob a licença Apache 2.0, abrangendo o aplicativo desktop, o cliente web, o backend, a CLI do agente e o runtime do agente.

Duas auditorias foram encomendadas e suas conclusões foram publicadas como resumos. A Academia Chinesa de Tecnologia da Informação e Comunicação constatou que o bucket OSS zcode-prod da Alibaba Cloud estava no que a Zhipu chama de estado de zero dados. A empresa de segurança NSFOCUS relatou que todos os objetos de dados e o próprio bucket haviam sido excluídos, e que não encontrou nenhum caminho remanescente no ZCode 3.14.0 que pudesse acionar um snapshot de repositório local ou enviar arquivos para fora. O relatório completo da avaliação não foi divulgado, e o The Next Web relata que a Zhipu não informou uma data para sua publicação.

O cliente que alegou mais e depois retirou a alegação

A alegação mais séria de perda real não veio da ferstar. Em 19 de setembro, segundo a Rádio Nacional da China, a Taiyuan Chengming Technology enviou à Zhipu uma carta jurídica numerada Chengming [2026] Carta Jurídica nº 1, reproduzida em detalhes pelo ChainCatcher. A empresa disse que seis de seus workspaces de programação haviam sido enviados sem consentimento — 34.500 arquivos e cerca de 425 MB em texto simples — e que esses dados incluíam código-fonte completo, arquitetura do sistema, histórico de versões, senhas de banco de dados, credenciais de nuvem e informações pessoais de funcionários. Disse que um sétimo workspace, com 1.947 arquivos e cerca de 144 MB, havia sido empacotado e criptografado, mas falhou em 32 tentativas de upload. Também observou que seu cliente havia sido atualizado para a versão 3.12.3 em 16 de setembro, no entanto, uploads ainda foram detectados às 00:28 de 18 de setembro, na manhã em que a Zhipu pediu desculpas.

A carta fez uma pergunta que as auditorias não respondem: se os dados saíram do país. Chengming disse que as solicitações de rede do ZCode apontavam para uma entidade de Singapura, enquanto o seu contrato de serviço foi assinado com a Beijing Zhipu Huazhang, e pediu à Zhipu que identificasse qual parte era responsável e se ocorrera qualquer transferência ou armazenamento fora da China continental. A carta apresentou doze exigências, incluindo apagar todos os dados enviados e os seus derivados, caches e backups com um certificado por escrito, explicar para onde os dados foram e se foram partilhados com terceiros ou utilizados para treino, descrever como a chave privada é guardada e produzir registos de acesso, definir o âmbito exato da alegação de "destruído" e comprometer-se por escrito a nunca mais enviar dados. Deu à Zhipu até 10 de outubro para responder por escrito e reservou o direito de exigir indemnizações e apresentar queixas às autoridades reguladoras. A Caixin Global relata que a Zhipu classificou as alegações como falsas.

Dois dias depois, a Chengming as retirou. A editoria financeira da China National Radio informa que, em 21 de setembro, a empresa emitiu uma retratação dizendo que suas declarações anteriores se baseavam em evidências errôneas, descrição imprecisa e linguagem exagerada, que elas haviam prejudicado a reputação da Zhipu, e que ela deixaria de falar com a imprensa. A Reuters também noticiou a retirada, segundo o The Next Web. O registro de arquivo deste incidente está datado de 18 de setembro, o dia da descoberta; a carta, seu prazo de 10 de outubro e a retratação vieram todos depois dessa data. Nos registros públicos até o final de outubro, nenhuma empresa identificada sustenta a alegação de que seus segredos foram expostos.

Uma versão de código aberto com seu histórico apagado

A abertura do código-fonte do cliente foi o remédio em que a Zhipu mais se apoiou, e veio com uma lacuna. Segundo o The Paper, o repositório publicado contém dois commits: um commit inicial vazio e um único commit que adiciona cerca de 6.973 arquivos e 1,03 milhão de linhas, com pull requests bloqueados e issues fechadas. Qualquer que fosse a forma do pipeline de upload quando foi lançado, e quaisquer que fossem as releases que o continham, isso não está no histórico que qualquer pessoa pode ler agora.

O próprio acompanhamento da Ferstar torna o limite explícito. Ele confirmou que o pipeline de upload já não existia e que o mecanismo de checkpoint restante executa apenas trabalho local do Git, depois apontou o que uma auditoria do bucket poderia e não poderia mostrar: esvaziar e excluir o bucket é a ação correta de stop-loss, mas uma verificação por terceiros realizada após 20 de setembro só pode estabelecer que o bucket estava vazio naquele momento. Ela não consegue reconstruir o que passou antes de 18 de setembro, se algo foi descriptografado, copiado ou guardado em backup, ou há quanto tempo o pipeline estava em execução. Uma alegação de exclusão ainda depende substancialmente da palavra da parte que excluiu.

A análise do InfoQ enumera as questões que permanecem em aberto nos mesmos termos: quantos snapshots de repositório foram carregados com êxito e por quantos usuários, por quanto tempo os objetos foram retidos, quais sistemas do lado do servidor ou membros da equipe poderiam descriptografá-los, se existe um registro de acesso completo e se a exclusão abrangeu backups e outras cópias. Também observa o que o ZCode ainda é após a correção. O próprio NOTICE do projeto adverte que o runtime de agente compartilhado não fornece, por padrão, um sandbox em nível de sistema operacional, e que o cliente mantém superfícies de shell, terminal, Git, MCP, plugins e navegador incorporado que podem ler arquivos, iniciar processos e acessar a rede dentro das permissões da conta do usuário.

O que está estabelecido e o que nenhuma fonte responde

O mecanismo não está em disputa. As próprias declarações da Zhipu admitem que dados de repositórios foram enviados, que o recurso vinha ativado por padrão e que os dados foram para um bucket na nuvem controlado pela empresa. As medições da Ferstar, o pedido de desculpas do fornecedor, duas auditorias contratadas e a publicação em código aberto descrevem todos a mesma cadeia. Nada no registro contesta que os espaços de trabalho saíram das máquinas sem uma opção de desativação viável. O dano registrado é real, não hipotético: as transferências ocorreram, e as pessoas cujo código estava nelas não puderam impedi-las nem inspecioná-las.

O que está em disputa, ou simplesmente é desconhecido, é a escala e a consequência. Nenhuma fonte declara quantos usuários executaram os padrões afetados, por quanto tempo o pipeline operou antes de 18 de setembro, ou se algum objeto enviado chegou a ser descriptografado. A garantia da Zhipu de que os dados foram destruídos após a geração da wiki e nunca usados para treinamento é uma declaração da própria empresa; as descobertas da CAICT e da NSFOCUS descrevem o estado do bucket após a correção, não o que passou por ele. O arquivo atribui nota A ao registro quanto à documentação, e a documentação é forte no mecanismo e limitada no escopo.

O que mudou e o que não mudou

O custo comercial foi imediato. A Rádio Nacional da China informa que as ações da Zhipu listadas em Hong Kong caíram 1,79% em 21 de setembro, 6,55% em 22 de setembro e 12,4% em 23 de setembro, uma queda acumulada de mais de 16% ao longo de três sessões de negociação, e que a Zhipu não esclareceu quantos usuários foram afetados nem se os dados históricos haviam sido descriptografados ou se havia backup deles.

O que um usuário do ZCode realmente recebeu nos quatro dias após a descoberta:

• 18 de setembro: um pedido de desculpas público que aponta a indexação da base de código como a causa, a promessa de tornar o cliente open-source e contratar uma revisão por terceiros, e uma redefinição extra semanal de cota por usuário.

• 19 de setembro: ZCode 3.14.0, com o Repo Wiki removido e o caminho de geração e upload de snapshots locais cortado. Ferstar confirmou que a cadeia de upload havia desaparecido no dia seguinte.

• 20 de setembro: uma opção anunciada de retenção zero para a plataforma MaaS da Zhipu, com adesão opcional, excluindo a Batch API e a File API, e ainda sujeita a retenção legal de 30 dias ou mais.

• 21 de setembro: ZCode publicado sob a licença Apache 2.0 sem seu histórico de commits anterior ao incidente; resumos da CAICT e da NSFOCUS relatando o bucket de armazenamento vazio e o caminho de saída ausente.

Nada disso retroage. As perguntas específicas que Chengming levantou — para onde foram os dados, quem podia decifrá-los, se saíram do país e o que abrangia “destruídos” — foram colocadas por escrito com um prazo de 10 de outubro e depois retiradas juntamente com a empresa que as fez. A Zhipu prometeu um relatório completo de avaliação por terceiros, sem data. Até que apareça um, o único relato público do que o pipeline fez com os dados que recebeu é o relato da empresa que o construiu, e o único artefacto mensurável de forma independente é um ficheiro de 313 MB que não conseguiu sair do portátil de um programador em 564 tentativas.