Em 7 de abril, a Anthropic anunciou que o Claude Mythos descobriu, sozinho, milhares de vulnerabilidades em sistemas operacionais e browsers, incluindo um bug que estava no OpenBSD desde 1999. Duas semanas depois, a Cloud Security Alliance publicou um relatório com o que isso muda para quem cuida de software.
O que aconteceu
Mythos é uma versão do Claude que a Anthropic treinou para procurar falhas de segurança em código. Nos testes internos, ele achou 181 falhas exploráveis no Firefox. A versão anterior do Claude, na mesma bancada, tinha achado duas. Em sistemas reais, repetiu o padrão: falhas em todos os principais sistemas operacionais e browsers, milhares delas, com 72% de taxa de sucesso para transformar uma falha em exploit funcional.
A Anthropic chamou de "preview" e abriu acesso antecipado a um grupo seleto de provedores de infraestrutura crítica, num esforço chamado Project Glasswing, para que esses fornecedores tivessem chance de corrigir antes do mundo saber. A janela é curta. O relatório da CSA estima que capacidades equivalentes em outros modelos aparecem em meses.
Mythos não saiu do nada. A linha do tempo da CSA mostra que vinha sendo construída há mais de um ano, com marcos quase mensais ao longo de 2025 e 2026:
Fonte: Cloud Security Alliance, abril/2026.
Por que isso muda o cálculo de risco
O gráfico que mais chama atenção no documento da CSA é o Zero Day Clock, que mede o tempo entre uma falha ser conhecida e ela ser efetivamente explorada na natureza:
Zero Day Clock, por Sergej Epp. Reproduzido no relatório da CSA, abril/2026.
- 2018 — 2,3 anos
- 2022 — 9,7 meses
- 2024 — 56 dias
- 2026 — horas
Não é projeção. É o que está acontecendo. Atacantes que antes precisavam de equipes especializadas para encontrar uma falha agora dependem só de fazer a pergunta certa para um modelo. A barreira de entrada caiu junto com o tempo de execução.
A consequência cai mais pesado num lado da balança. Quem ataca ganha mais com IA do que quem defende. O ciclo de patch das empresas (descobrir, testar, aplicar, validar) foi desenhado num mundo de meses, e hoje compete com um adversário que opera em horas. Não é igual.
Três perguntas que vale responder agora
O relatório da CSA é longo e dirigido a quem cuida de programa de segurança em escala. Mas existem três perguntas embutidas nele que qualquer empresa de software pode usar como termômetro hoje.
Você sabe o que está rodando em produção? Lista de aplicações, dependências, pacotes open-source, contas em cloud, máquinas, integrações. Não a documentação ideal, a real. Se o atacante consegue mapear sua superfície em horas com IA, o mínimo é você saber o que está em jogo.
Quanto tempo leva entre saber de uma falha e ela estar corrigida em produção? Se for "alguns dias" para sistemas expostos à internet, ótimo. Se for "uma sprint" ou "no próximo deploy mensal", está fora do compasso novo. O relatório recomenda revisar a tolerância de downtime para incluir patching mais agressivo.
Se uma falha for explorada, o estrago fica contido em quanto? Segmentação de rede, princípio do menor privilégio, MFA forte. Esses controles não impedem a invasão. Eles limitam o estrago, e quando o número de falhas explode, conter o blast radius vira mais valioso do que tentar evitar 100% das invasões.
O que isso significa na prática
Vai ter quem venda o relatório como "fim do mundo". Não é. O documento é cuidadoso: diz que o básico continua valendo, e que o trabalho de segurança não desaparece. Muda de cadência.
Precisamos ser honestos: a hipótese de que "ninguém vai mirar a minha empresa" sempre foi frágil. Com mineração de vulnerabilidade automatizada, ela virou insustentável. O atacante não escolhe você. Ele varre tudo, e ataca o que cair primeiro.
O que muda para a empresa de software média não é virar refém do hype. É decidir hoje que velocidade de resposta vira cultura técnica, e deixa de ser item de backlog. Inventário, patches, segmentação. Coisas que sempre foram chatas, e que ficaram caras de adiar.
O que fazer
Quatro ações, em ordem de impacto:
- Inventário do crítico — liste, em uma página, os sistemas expostos à internet e as 5-10 dependências mais usadas. Atualize quando algo entrar em produção.
- MFA em tudo o que aceita login externo — quando o vendor suportar, prefira o tipo resistente a phishing (FIDO2/WebAuthn).
- SLA de patch para sistemas internet-facing — meta inicial de 7 dias para falhas de alta severidade. Não precisa ser perfeito. Precisa ser medido.
- Segmentação básica — se um servidor for comprometido, ele consegue chegar em qual outro? Reduzir essa lista é o controle com melhor retorno por real investido hoje.
Se for fazer só uma, comece pelo inventário. Sem saber o que se tem, o resto acontece no escuro.
Fonte: The "AI Vulnerability Storm": Building a "Mythos-ready" Security Program, Cloud Security Alliance + SANS + OWASP Gen AI Security Project, 13 de abril de 2026.