needhelp
← Back to blog

Grok Build CLI carregou silenciosamente todo o seu repositório - arquivos .env incluídos

by needhelp
Segurança
Agente de IA
Privacidade
xAI

Um pesquisador do cereblab descobriu que o Grok Build CLI do xAI, versão 0.2.93, estava copiando repositórios git inteiros – segredos, histórico completo, tudo – para um bucket do Google Cloud Storage sem avisar o usuário.

O que aconteceu

A ferramenta fez dois tipos de solicitações de saída. As voltas do modelo foram para POST /v1/responses. Mas uma chamada POST /v1/storage separada agrupou toda a árvore de trabalho mais o histórico completo de .git e a enviou para gs://grok-code-session-traces.

Esse balde é propriedade da xAI. O upload foi executado como um efeito colateral do simples uso da CLI – sem botão “exportar”, sem prompt, sem aviso.

Os números são surpreendentes. Com um repositório de teste de 12 GB e nenhum arquivo realmente lido pelo modelo, /v1/responses transmitiu aproximadamente 192 KB. /v1/storage enviou 5,10 GiB em 73 blocos. Essa é uma lacuna de 27.800×. O modelo utilizou 192 KB de contexto; Os servidores do xAI têm todo o seu repositório.

O teste canário

cereblab plantou um arquivo chamado never_read_canary.txt com uma string exclusiva. O prompt foi literalmente “Responda exatamente: OK. Não leia ou abra nenhum arquivo.” O modelo obedeceu ao texto. A string canário foi recuperada do pacote enviado.

Portanto, a exfiltração não foi impulsionada pela leitura de arquivos sob demanda pelo modelo. Era um pipeline integrado que funcionava independentemente do que você pedia.

Por que a desativação não funcionou

Existe uma configuração chamada “Melhorar o modelo”. Desligá-lo supostamente interromperá o uso de treinamento de seus dados. a captura do cereblab mostrou que o servidor ainda retornou trace_upload_enabled: true e upload_enabled: true. O upload continuou acontecendo.

A CLI possui um sinalizador --deny que restringe quais arquivos o modelo pode ler. Isso apenas bloqueia leituras. Não faz nada em relação à saída da rede – o pacote já estava saindo.

A essência coloca a conclusão sem rodeios: “A desativação não impede que seu repositório saia da máquina.”

O vazamento entre ferramentas

A captura mostrou que a ferramenta também varreu arquivos em ~/.claude/. Esse é o diretório de configuração de um produto diferente. Chaves para serviços não relacionados – cereblab cita uma chave de API do Baidu Miaoda – deixaram a máquina junto com seu repo.

Outro pesquisador que reproduziu as descobertas descobriu 339 uploads automáticos em seus registros. Um desses uploads continha seu diretório inicial inteiro – potencialmente expondo chaves SSH, dados do gerenciador de senhas, perfis de navegador, tudo.

O interruptor de interrupção remota

Em 12 de julho, quando a história se tornou viral, aconteceu algo que a xAI nunca anunciou: o mesmo binário do cliente, com o mesmo hash SHA-256, de repente começou a receber respostas diferentes do servidor.

disable_codebase_upload: true. trace_upload_enabled: false.

Os uploads foram interrompidos. Nenhuma atualização do cliente. Sem registro de alterações. Nenhuma notificação.

Isso significa que o xAI sempre teve a capacidade de ativar ou desativar remotamente a coleta de dados em qualquer instalação Grok CLI, a qualquer momento, sem o conhecimento do usuário. Eles simplesmente optaram por deixá-lo ativado por padrão e nunca mencionar isso.

Musk responde

Em 14 de julho, Elon Musk respondeu à polêmica com uma única palavra: “Verdade”. Ele continuou:

“Como medida de precaução, todos os dados do usuário que foram carregados para o SpaceXAI antes serão completa e totalmente excluídos. Zero qualquer coisa permanecerá.”

xAI anunciou simultaneamente um comando /privacy para o Grok CLI:

  • /privacy — mostra seu status atual de retenção de dados
  • /privacy opt-out — desativa a retenção e aciona a exclusão retrospectiva de dados já sincronizados

Andrew Milich, chefe da Grok Build, confirmou que a alteração das configurações de privacidade aciona a exclusão de dados da nuvem previamente sincronizados. Os clientes corporativos obtêm o modo “Zero Data Retention” (ZDR).

Mas eis o que não mudou: nenhum aviso de segurança foi emitido. Nenhuma explicação sobre por que repositórios inteiros foram coletados sem consentimento. Nenhuma auditoria independente da exclusão. O changelog v0.2.98 omitiu totalmente qualquer menção aos uploads do repositório.

Como verificar se você foi afetado

  • Execute a CLI por trás de um proxy MITM: HTTPS_PROXY=http://127.0.0.1:8080. Fique atento para POST /v1/storage atingir o balde grok-code-session-traces.
  • Pesquise no binário/strings o nome do bucket codificado grok-code-session-traces.
  • o repositório repro do cereblab envia um verify.sh que baixa e descompacta novamente os pacotes retornados para que você possa ver exatamente o que sobrou.
  • Verifique os registros de saída de tráfego para o Google Cloud Storage durante qualquer sessão da Grok CLI.
  • Execute /privacy na CLI do Grok para ver seu status atual de retenção de dados.
  • Outro pesquisador encontrou 339 uploads verificando seus próprios registros – se você já usou a ferramenta, presuma que seus repositórios saíram da máquina.

O que fazer- Execute /privacy opt-out imediatamente para desativar a retenção de dados e solicitar a exclusão de dados já carregados.

  • Desinstale totalmente a versão afetada (0.2.93).
  • Bloqueie a saída para o Google Cloud Storage na camada de rede — uma regra de firewall ou uma regra de rejeição do Clash: (PROCESS-NAME,grok.exe) && (DOMAIN-SUFFIX,storage.googleapis.com).
  • Se precisar continuar usando, adicione ~/.grok/config.toml: 
    [harness] disable_codebase_upload = true
    [features] telemetry = false
    [telemetry] trace_upload = false
  • Gire todas as credenciais que já estiveram em um repositório que você abriu com esta versão. Os arquivos .env são frequentemente rastreados ou ficam na árvore de trabalho, e .gitignore não protege você — o pacote carregava os arquivos rastreados de qualquer maneira. Trate tudo como comprometido.

Os dados podem ser excluídos. Confie, não tão facilmente.

Referências

Share this page