Alessandro C. Lavorante, Prof. Me. USP · OAB/SP
Na Parte 1 deste texto, contei como a pesquisa sobre riscos de segurança da minha stack de automação com IA me apresentou o princípio do assume breach, o conceito de blast radius, e quatro incidentes que mostraram o que acontece quando código gerado por IA vai para produção sem revisão. Aqueles casos envolviam plataformas de terceiros que eu não uso. É fácil olhar de fora e pensar "eu teria feito diferente". O que vou tratar agora é mais desconfortável: problemas que afetam diretamente as ferramentas que eu opero no dia a dia, e padrões de falha que qualquer pessoa que usa IA para gerar código vai encontrar, inclusive eu. E inclusive você.
Quando a própria ferramenta tem buracos
Uma coisa que me incomodava desde o início era uma pergunta que não aparecia em nenhum tutorial de produtividade: as ferramentas de IA que eu uso para escrever código — elas próprias são seguras?
A resposta curta: não perfeitamente, e não poderia ser diferente, porque assume breach se aplica a elas também. Mas os detalhes importam.
Em fevereiro de 2026, a Check Point Research — assinada pelos pesquisadores Aviv Donenfeld e Oded Vanunu — publicou uma análise de três vulnerabilidades no Claude Code, a ferramenta que eu uso diariamente [1]. Foram dois CVEs: o CVE-2025-59536 (pontuação CVSS 8.7 de 10 segundo o NVD [1a]) cobrindo duas falhas distintas, e o CVE-2026-21852 cobrindo uma terceira. As três exploravam o mesmo princípio, aplicado a mecanismos diferentes: os arquivos de configuração dos repositórios de código.
A primeira falha usava hooks — ações automáticas que disparam em eventos do projeto (antes de um commit, depois de um build). A Check Point demonstrou que hooks maliciosos definidos no arquivo .claude/settings.json executavam código arbitrário antes que o desenvolvedor pudesse ler o diálogo de confirmação [1]. A segunda falha usava servidores MCP (Model Context Protocol, o protocolo que conecta o agente a ferramentas externas) configurados em .mcp.json: com a opção enableAllProjectMcpServers: true, os servidores executavam antes da aprovação do usuário [1]. A terceira falha, a mais direta, usava a variável ANTHROPIC_BASE_URL no mesmo .claude/settings.json para redirecionar todas as chamadas de API do Claude Code para um servidor do atacante, capturando a chave de API do usuário em texto puro [1].
O padrão comum: todo desenvolvedor trata esses arquivos como metadados passivos, como uma etiqueta na pasta. São três mecanismos diferentes demonstrando que eles funcionam, na prática, como código executável. Bastava clonar um repositório malicioso e abrir o Claude Code. A Anthropic corrigiu todas as falhas antes da publicação do relatório [1], mas o padrão não é exclusivo do Claude Code: em 2026, o Cursor IDE teve uma vulnerabilidade do mesmo tipo (CVE-2026-26268), com escape de sandbox via configuração de hooks do Git e execução remota de código sem interação do usuário [1b]. Arquivos de configuração como vetores de execução é um problema sistêmico das ferramentas de desenvolvimento com IA, não uma falha de um fornecedor só.
E então veio o vazamento.
Em 31 de março de 2026, a Anthropic publicou acidentalmente o código-fonte completo do Claude Code via npm — o repositório público de pacotes JavaScript que qualquer desenvolvedor usa para instalar bibliotecas. Um arquivo source map de 59,8 MB foi incluído na versão 2.1.88 do pacote @anthropic-ai/claude-code, contendo aproximadamente 512 mil linhas de TypeScript distribuídas em 1.906 arquivos [2]. O pesquisador de segurança Chaofan Shou identificou o arquivo e publicou a descoberta no X [3]. Em poucas horas, o código estava espelhado no GitHub, onde acumulou mais de 84 mil stars e 41 mil forks antes de ser derrubado por notificação DMCA — um dos repositórios de crescimento mais rápido da história da plataforma [4].
O impacto direto, segundo análise da Zscaler ThreatLabz, foi a exposição completa da "lógica agêntica" — o pipeline interno de gerenciamento de contexto, os prompts de sistema que controlam como o agente lê, executa e aprova código, e 44 feature flags revelando funcionalidades não lançadas [2]. Uma delas chamou especialmente minha atenção como advogado: o chamado Undercover Mode, cujo prompt de sistema instrui o Claude a operar de forma encoberta em repositórios públicos e open-source, sem deixar rastros de que o código foi gerado por IA — a instrução literal diz "do not blow your cover" [2]. O que isso significa para atribuição de autoria, transparência em projetos de código aberto e due diligence de propriedade intelectual em operações de M&A são perguntas que ainda não têm resposta consolidada — mas que agora precisam ser feitas.
Na mesma madrugada, um ataque completamente independente comprometeu a biblioteca axios no npm — versões 1.14.1 e 0.30.4, contendo um Remote Access Trojan (RAT, programa que dá controle remoto ao atacante) [4]. As versões maliciosas foram publicadas entre 00h21 e 03h29 UTC; o pacote do Claude Code com o source map vazado apareceu por volta das 04h UTC [5]. Os dois incidentes não tinham relação causal — foram eventos separados com timing catastrófico. Mas como o Claude Code usa o axios como dependência, qualquer desenvolvedor que atualizou a ferramenta via npm install naquela janela pode ter sido infectado — mesmo sem saber nada sobre o vazamento do código-fonte. O perigo veio da convergência temporal, não de uma cascata linear, e isso o torna mais perturbador: duas falhas independentes que se potencializaram por coincidência [4].
O que o modelo não faz por você (e não avisa que não está fazendo)
Os CVEs e o vazamento são problemas da ferramenta. Agora preciso falar sobre um problema mais sutil e, para o público deste artigo, mais relevante: o que acontece com o código que a ferramenta gera para você.
A equipe de segurança da Databricks conduziu um experimento que vale como caso de estudo [6]. Pediram ao Claude que construísse um jogo multiplayer de Snake (aquele jogo da cobrinha) usando vibecoding — ou seja, descrevendo o que queriam em linguagem natural e deixando o modelo tomar todas as decisões arquiteturais. O jogo ficou pronto e funcionava perfeitamente. O problema estava na camada de rede: para transmitir os dados entre jogadores, o Claude usou o módulo pickle do Python — uma biblioteca de serialização conhecida por ser vulnerável a execução remota de código. Qualquer jogador malicioso podia enviar um payload que executaria comandos arbitrários no computador dos outros jogadores [6].
A vulnerabilidade do pickle não é novidade. Está documentada há anos. Qualquer programador com experiência em segurança evita pickle para dados de rede como evita fio desencapado. Mas o Claude não é um programador com experiência em segurança. O Claude é um modelo de linguagem que otimiza para satisfazer o seu prompt. O prompt pedia um jogo multiplayer que funcionasse. O jogo funcionou. A segurança não estava no prompt, então não estava na solução.
Aqui vai o detalhe mais revelador do experimento: quando os pesquisadores voltaram e pediram explicitamente ao Claude para "implementar com segurança", o modelo identificou e corrigiu o problema sozinho — trocou pickle por JSON, adicionou limite de tamanho de mensagens, resolveu [6]. Ou seja, o modelo sabia que pickle era inseguro. Ele simplesmente não priorizou essa informação até que alguém pedisse.
Esse padrão se repete em cada caso documentado que encontrei na pesquisa, e vale a pena nomeá-lo: o modelo otimiza para fazer funcionar, não para fazer funcionar com segurança. Quando você diz "crie uma API que salva dados no banco", ele cria. Se a autenticação não estava no prompt, ela pode não estar no código. Se a separação entre ambiente de testes e produção não foi mencionada, ela não existe. Segurança é tratada como decoração opcional, não como requisito estrutural — e o modelo não vai avisar que está faltando.
Credenciais hardcoded (escritas diretamente no código) são outro caso recorrente. Quando o modelo encontra um problema de "permissão negada" e precisa de uma chave para continuar, a solução mais direta — e frequentemente sugerida — é embutir a credencial no lugar onde ela funciona. Resolve o problema imediato. Viola o princípio básico de gestão de segredos. E fica lá, no código, esperando para ser descoberta por quem não deveria.
O número que deveria estar em outdoor
Um grupo de pesquisadores da Carnegie Mellon University e da Columbia University criou o SusVibes, um benchmark (teste padronizado) projetado especificamente para medir algo que os testes tradicionais não medem: a diferença entre código que funciona e código que é seguro [6].
O benchmark consiste em 200 tarefas reais de engenharia de software, extraídas de projetos reais de código aberto. Os pesquisadores testaram os principais agentes de IA de programação, incluindo o próprio Claude, com esses cenários. Os resultados [7]:
O melhor agente funcional — SWE-Agent com Claude 4 Sonnet — resolveu corretamente 61% das tarefas, mas apenas 17,2% dessas soluções corretas eram seguras. As outras 82,8% tinham pelo menos uma vulnerabilidade [7]. A configuração otimizada para segurança — OpenHands com Claude 4 Sonnet — foi um pouco melhor, mas ainda assim 74,7% das suas soluções funcionalmente corretas continham vulnerabilidades [7].
Preciso que esse número aterrisse: dependendo de qual ferramenta e qual configuração, de cada 10 vezes que você pede para a IA resolver um problema e ela entrega algo que funciona e passa nos testes, em 7 a 8 dessas vezes o código tem pelo menos uma vulnerabilidade de segurança. O código roda. Os testes passam. E o vetor de ataque está lá, esperando.
A razão para isso é estrutural, não acidental. Os testes que o modelo escreve (ou que você escreve) verificam se o código faz o que deveria. Eles não verificam se o código resiste ao que não deveria. Ninguém escreve um teste para "o que acontece quando um visitante não autenticado tenta acessar dados privados" a menos que já tenha pensado nessa possibilidade. E a maioria dos vibecoders, por definição, não pensa nessas possibilidades — porque não é programador de formação e não tem o vocabulário de ameaças que um especialista em segurança desenvolveu ao longo de anos.
Por que o vibecoding torna o programador mais necessário, e não menos
Existe uma narrativa circulando — em threads de X, em posts de LinkedIn, nos comentários de qualquer vídeo sobre IA — que diz mais ou menos o seguinte: "com essas ferramentas, qualquer pessoa pode programar, e o programador profissional vai ficar obsoleto". Eu ouço variações disso toda semana. E depois de meses mergulhado nos dados que descrevi nestes dois artigos, estou convicto de que a narrativa está exatamente invertida.
Mais código gerado por IA significa mais superfície de ataque. Mais superfície de ataque significa mais necessidade de quem sabe identificar, mapear e mitigar vulnerabilidades. O vibecoder que gera uma API funcional em 20 minutos e publica em produção criou, estatisticamente, entre 7 e 8 vulnerabilidades que ele não sabe que existem. Quem vai encontrá-las? Quem vai corrigi-las? Quem vai projetar a arquitetura de permissões que impede que uma falha num componente comprometa o sistema inteiro?
A resposta é a mesma de sempre: o programador. Especificamente, o programador que entende de segurança, de infraestrutura, de revisão de código e de arquitetura de sistemas. O profissional que sabe o que é threat modeling (modelagem de ameaças), que testa os cenários de abuso e não só os cenários felizes, que pensa adversarialmente — "se eu fosse um atacante, onde eu entraria?".
As habilidades que o vibecoding não substitui são precisamente as habilidades de quem entende o contexto em que o código vai operar. Saber programar sempre foi mais do que digitar instruções num editor. Sempre foi sobre tomar decisões de arquitetura — o que se isola do quê, quem tem permissão para quê, o que acontece quando algo falha. Essas decisões são invisíveis no código que "funciona" e mortais na ausência. A IA eliminou a barreira de entrada para escrever código. Ela não eliminou — e talvez tenha ampliado — a necessidade de alguém que saiba pensar sobre código.
E aqui fecho com uma observação de quem lida profissionalmente com responsabilidade civil no contexto digital. A LGPD, como detalhei na Parte 1, tem dispositivos específicos que responsabilizam o controlador que deixa de adotar medidas técnicas adequadas de segurança (arts. 44, parágrafo único, e 46 da Lei nº 13.709/2018). Há também a cláusula geral do art. 927, parágrafo único, do Código Civil, que estabelece a obrigação de reparar o dano independentemente de culpa quando a atividade implica, por sua natureza, risco para os direitos de outrem — a aplicação desse dispositivo ao desenvolvimento de software com IA é tese doutrinária ainda em construção, mas o nexo da LGPD é mais direto e menos controverso. Quando um sistema vai para produção com vulnerabilidades documentáveis que um profissional de segurança teria identificado, e quando o responsável pelo sistema optou por não contratar esse profissional porque "a IA faz tudo", a discussão sobre culpa vai ser curta. O ferramental existe. A documentação sobre os riscos existe — você acabou de ler parte dela. O que não existe, em muitos casos, é a decisão de investir na pessoa que sabe usá-lo.
O vibecoding é uma ferramenta extraordinária de produtividade. Eu uso diariamente e pretendo continuar usando. Mas confundir a capacidade de gerar código com a capacidade de colocar código seguro em produção é o erro mais caro que um profissional ou empresa pode cometer neste momento. Os dados de 2025 e 2026 são inequívocos: a barreira para operar software com responsabilidade ficou mais alta, não mais baixa.
Referências
[1] DONENFELD, Aviv; VANUNU, Oded. Caught in the Hook: RCE and API Token Exfiltration Through Claude Code Project Files. Check Point Research Blog, 25 fev. 2026. Disponível em: https://research.checkpoint.com/2026/rce-and-api-token-exfiltration-through-claude-code-project-files-cve-2025-59536/. Acesso em: 10 abr. 2026.
[1a] NVD. CVE-2025-59536. National Vulnerability Database. Disponível em: https://nvd.nist.gov/vuln/detail/CVE-2025-59536. Acesso em: 10 abr. 2026.
[1b] NVD. CVE-2026-26268. National Vulnerability Database (Cursor IDE, sandbox escape via .git hooks). Disponível em: https://nvd.nist.gov/vuln/detail/CVE-2026-26268. Acesso em: 10 abr. 2026.
[2] ZSCALER THREATLABZ. Anthropic Claude Code Leak. Zscaler Blog, abr. 2026. Disponível em: https://www.zscaler.com/blogs/security-research/anthropic-claude-code-leak. Acesso em: 13 abr. 2026.
[3] CLAUDE Code source code accidentally leaked in NPM package. BleepingComputer, abr. 2026. Disponível em: https://www.bleepingcomputer.com/news/artificial-intelligence/claude-code-source-code-accidentally-leaked-in-npm-package/. Acesso em: 13 abr. 2026.
[4] CLAUDE Code source leaked via npm packaging error, Anthropic confirms. The Hacker News, 3 abr. 2026. Disponível em: https://thehackernews.com/2026/04/claude-code-tleaked-via-npm-packaging.html. Acesso em: 11 abr. 2026.
[5] VARSHITH, V. The Great Claude Code Leak of 2026. DEV Community, abr. 2026. Disponível em: https://dev.to/varshithvhegde/the-great-claude-code-leak-of-2026-accident-incompetence-or-the-best-pr-stunt-in-ai-history-3igm. Acesso em: 12 abr. 2026.
[6] DATABRICKS AI RED TEAM. Passing the Security Vibe Check: The Dangers of Vibe Coding. Databricks Blog, ago. 2025. Disponível em: https://www.databricks.com/blog/passing-security-vibe-check-dangers-vibe-coding. Acesso em: 9 abr. 2026.
[7] ZHAO, Songwen et al. SusVibes: Is Vibe Coding Safe? Benchmarking Vulnerability of Agent-Generated Code in Real-World Tasks. arXiv, CMU/Columbia, nov. 2025. Disponível em: https://arxiv.org/html/2512.03262v1. Acesso em: 10 abr. 2026.
Alessandro Casoretti Lavorante
Prof. Me. pela USP
Advogado especializado em Direito Digital, IA e Startups. Mestre em Direito Civil pela USP. Autor do livro "Responsabilidade Civil por Inteligência Artificial".