Como auditar e mitigar Claude Code 2.1.91–2.1.196 com foco em egress

O alerta mais importante aqui não é “mais um bug no Claude Code”. Na minha experiência, quando um órgão público aponta um mecanismo capaz de exfiltrar dados sensíveis em versões específicas, isso vira um problema operacional: você precisa saber o que está instalado, o que foi modificado, e como mitigar sem parar o fluxo de desenvolvimento. Segundo o OlharDigital.com.br, a China afirmou ter identificado um possível problema de segurança no Claude Code, e a faixa de versões citada (2.1.91 a 2.1.196) é exatamente o tipo de detalhe que deve entrar no seu checklist de governança.

O que o alerta na China realmente significa (e por que devs devem ligar)

Segundo o OlharDigital.com.br, o Banco de Dados Nacional de Vulnerabilidades da China (NVDB) e um órgão ligado ao Ministério da Indústria indicaram que haveria um mecanismo de monitoramento no Claude Code que poderia transmitir dados considerados sensíveis para servidores remotos. O que torna isso sério, do ponto de vista de engenharia, é a combinação de três fatores:

• Versões específicas afetadas: dá para auditar e mitigar com precisão (não é “algo hipotético”.)
• Tipo de dado mencionado: localização geográfica e identificadores ligados à identidade do usuário — mesmo que “aparentemente” não seja uma senha, é dado altamente vinculável.
• Possível ausência de consentimento: para ambientes corporativos e regulados, isso muda a categoria do risco (conformidade entra no jogo).

Em disputa tecnológica EUA–China, esse tipo de acusação vira combustível político. Mas do meu lado, como dev, o que pesa é: exfiltração não precisa roubar tudo para ser “ameaça grave”. Às vezes, metadata e identificadores já bastam para reidentificação, auditoria reversa ou criação de perfis.

Claude Code: por que “monitoramento” costuma ser o ponto cego de segurança

Ferramentas de IA para programação tipicamente precisam coletar sinais para melhorar a experiência: telemetria, métricas de uso, diagnósticos e contexto do ambiente. Isso pode ser legítimo. O problema é quando o mecanismo:

• Coleta mais do que o necessário (data minimization falha);
• Empacota dados sem transparência (hard to verify);
• Envia para endpoints não óbvios (difícil de auditar);
• Fica ativo mesmo sem consentimento (governança falha).

Quando um órgão público marca isso como “ameaça”, o que normalmente está por trás é uma avaliação de que o fluxo de dados viola expectativas de privacidade. Em engenharia de segurança, o termo-chave costuma ser exfiltration via telemetry: não é malware clássico, mas uma coleta aparentemente “benigna” que vira vetorzinho de vazamento.

Faixa de versões (2.1.91 a 2.1.196): como isso muda seu plano de ação

O alerta também trouxe um ponto prático: a vulnerabilidade/mecanismo estaria entre Claude Code 2.1.91 e 2.1.196. Na prática, isso reduz o custo de mitigação, porque você consegue:

• identificar rapidamente quem está rodando essas versões;
• decidir se você vai atualizar, remover ou isolar;
• rodar testes de conectividade e auditoria de rede só nos ambientes relevantes.

Em projetos reais, a maior armadilha é assumir que “todo mundo atualiza automático”. Muitas equipes esquecem um ciclo de atualização em laptops, VMs e ambientes de build. Se você ignora inventário, você só descobre o problema quando alguém reclama.

Comparando com alternativas reais: IDEs/assistentes e o que costuma diferenciar

Você não está preso a um único produto. Mas, quando a preocupação é “o que vai para fora do meu computador”, quase todo assistente tem trade-offs. O que diferencia soluções e reduz risco é:

• Controle de rede: suporte a proxies, domínios allowlist e políticas corporativas;
• Transparência: configuração clara de telemetria e logs;
• Arquitetura: se o envio inclui metadados (IP/geo/IDs) ou somente conteúdo mínimo do pedido;
• Self-host / modo offline / modelos locais (quando aplicável).

Por exemplo, algumas abordagens mais “controláveis” no mundo real costumam ser: usar assistentes com opções de telemetria desativável, ou um fluxo onde o modelo roda localmente (ou em infraestrutura sua). Nem sempre isso é viável, mas para times regulados vira uma estratégia de mitigação.

Na Prática: como auditar e mitigar hoje (sem achismo)

Vou te passar um passo a passo que eu usaria num time que precisa manter produtividade e reduzir risco ao máximo. A ideia é confirmar o que está enviando, para onde, e se a versão está dentro da janela citada.

1) Descubra quais máquinas estão com as versões afetadas

1. Crie um inventário das máquinas (MDM/endpoint management, ou ao menos via script local).
2. Liste versão do Claude Code instalada.
3. Marque quem está entre 2.1.91 e 2.1.196.

2) Faça um teste de conectividade com logs de rede

Sem “hack”, só observação. Em uma máquina afetada, monitore conexões quando você usa a ferramenta. Se houver endpoints desconhecidos ou tráfego recorrente sem ação clara, isso é pista.

3) Use firewall/proxy com allowlist provisória

Em ambientes corporativos, eu prefiro bloquear “por padrão” e liberar destinos necessários. Mesmo que você não saiba os domínios corretos ainda, dá para começar com regras temporárias e observar. A meta não é quebrar tudo; é forçar visibilidade.

4) Atualize ou desative temporariamente até haver correção/clareza

• Se houver versão corrigida: atualize imediatamente.
• Se não houver: desative** ou isole em redes controladas.

const fs = require("fs");

function findVersion(paths) {
  for (const p of paths) {
    if (fs.existsSync(p)) {
      const raw = fs.readFileSync(p, "utf8");
      try {
        const pkg = JSON.parse(raw);
        if (pkg.version) return pkg.version;
      } catch (e) {}
    }
  }
  return null;
}

// Exemplo de locais comuns (AJUSTE conforme seu SO/instalação)
const version = findVersion([
  "./resources/app/package.json",
  "./package.json",
  "/opt/claude-code/package.json"
]);

if (!version) {
  console.log("Não consegui detectar a versão automaticamente. Verifique o caminho de instalação.");
} else {
  console.log("Claude Code versão:", version);
}