Aumento da CVE em 2026 contrasta com explorações reais limitadas

Nos primeiros seis meses de 2026 a superfície de risco foi mais rápida do que nunca: 35.853 CVE, um aumento declarado de 49% em relação ao mesmo período do ano anterior; contudo, de todas essas entradas só 495 foram catalogadas como exploradas na natureza e 116 estiveram sob ataque no mesmo dia de sua publicação. Esses números —tomados dos dados agregados de divulgações de vulnerabilidades — mostram uma tensão-chave que muitas organizações ainda não gerem bem: o volume de achados cresce a uma velocidade que as práticas tradicionais de resposta não podem seguir, mas a maioria das vulnerabilidades nunca chega a ser exploradas no mundo real. A questão operacional já não é quantas vulnerabilidades há, mas quais delas são exploradas e valem o custo de intervenção imediata em seu ambiente.

Além da avalanche de CVE, modelos de IA orientados para detecção e análise de código aceleraram a identificação de possíveis falhas. Segundo divulgações da própria Anthropic, modelos da família Mythos geraram 26.153 candidatos a vulnerabilidade em projetos de código aberto, dos quais apenas 421 terminaram adesivos nos repositórios upstream. Essa relação entre "hallazgos" e "parches aplicados" sublinha outra realidade técnica: os detectores automáticos produzem muito ruído que necessita de filtragem por evidência contextual para decidir ação. Estes números confirmam dois factos: a descoberta escala e as correcções reais permanecem relativamente escassas.

É importante separar o confirmado do estimado. Confirmado: o aumento do volume de CVE e a relação observada entre achados e exploits publicados. Estimado: que o fosso entre divulgação e exploração continuará a diminuir à medida que mais ferramentas automatizadas e modelos gerativos facilitem o desenvolvimento de testes de conceito e exploits. Incerteza: em que medida essa aceleração afetará setores específicos ou vetores específicos nos próximos 12 meses; isso dependerá do ritmo de adoção desses modelos e da disponibilidade pública de exploits.

Do ponto de vista técnico, o problema reside na distinção entre severidade e explorabilidade. O escore CVSS dá uma referência sobre gravidade, mas não incorpora contexto operacional: não considera se o serviço vulnerável está exposto, se a rede o segmentar, se existem controles que rompam a cadeia de exploração ou se o ativo em questão é essencial para o negócio. Uma mesma CVE pode afetar centenas de instâncias dentro de uma empresa e seu impacto real variará de acordo com a configuração, privilégios e controles em torno de cada instância.

Por isso, a abordagem que ganha tração entre as equipes de segurança maduras combina três tipos de validação complementares. Primeiro, a validação da exploração, que responde se a vulnerabilidade pode realmente ser abusada em seu ambiente: inclui análise estática/dinâmica, testes em ambientes seguros e veredictos quando ainda não existe um exploit público. Segundo, a validação dos controlos de segurança, que prova se as defesas atuais (WAFs, EDR, IPS, segmentação, políticas de acesso) bloqueiam, detectam ou falham diante de uma tentativa de exploração. Terceiro, o pentesting agenteado ou automatizado, que encadeia vulnerabilidades, credenciais e más configurações para demonstrar rotas de ataque reais e até onde pode avançar um atacante.

Cada uma traz provas distintas: a pentest automatizada é a mais conclusiva quando pode executar exploits reais, porque mostra impacto prático; a validação de controles demonstra se os investimentos defensivas funcionam; e a exploração cobre vazios onde não é seguro executar código ofensivo em produção ou ainda não existe exploit público. Nenhuma por si só fecha o problema: por exemplo, a pentest não pode testar sistemas air-gapped nem aplicações críticas em produção que não admitem provas destrutivas; a validação de controles requer cenários bem modelados; e a explorabilidade sem verificação em rede pode ficar em conjeturas.

O que isso significa para as equipes e para você como responsável técnico? Primeiro: adotar uma priorização baseada em impacto real, não apenas na severidade do CVE. Isso exige um inventário preciso de ativos, mapeamento de exposição (que serviços são public-facing), e conhecimento da criticidade do serviço para o negócio. Segundo: enriquecer os fluxos de trabalho de vulnerabilidade com evidência interna. Não basta marcar um ticket como "High" e esperar; há que adicionar um rótulo que recoja se a vulnerabilidade foi validada como explorável, se os controles a detectam e quais rotas de ataque permitem. Terceiro: integrar revalidação sistemática: depois de aplicar adesivos ou mitigações, voltar a validar para evitar tickets fechados sem verificação real.

Na prática, isso implica mudanças operacionais concretas. Reforça o inventário de ativos e a visibilidade de rede; habilita credenciais seguras para digitalização autenticadas; cria ambientes de testes isolados para executar exploits quando necessário; aplica técnicas de microsegmentação para limitar a lateralidade e reduz a "superficie explogável" embora uma falha exista. Assegura que as suas ferramentas de detecção (EDR/IDS/ SIEM) estejam configuradas para gerar sinais acionáveis e que exista um playbook que traduza evidência de exploração em ordens de remediação priorizadas. Se um CVE não puder ser testado em produção, exige relatórios de exploração baseados em análises de código e em testes replicados em ambientes seguros antes de decidir não adesivo.

Há também uma dimensão de governação: nem todos os achados merecem a mesma cadeia de comando. Define limiares que activam uma resposta urgente (por exemplo, activos expostos em produção sem mitigações, evidência de exploit na wild) e delega remediações de baixa prioridade a ciclos regulares de adesivo. Automatiza a reafectação de prioridades quando nova evidência aparece: se uma vulnerabilidade de baixa prioridade se demonstra explorável contra sistemas críticos, que suba automaticamente a emergência e dispare comunicações apropriadas.

Limitações práticas e riscos residuais devem ser aceites: nem sempre haverá um exploit disponível para testar e, em muitos casos, provar exploits em produção é ilegal ou perigoso. Além disso, a incorporação de agentes de pentesting automatizados e modelos agentivos representa riscos de falso positivo e necessidade de supervisão humana. Por conseguinte, a implementação destas práticas requer competências em análise de segurança, infra-estruturas de testes e processos claros para coordenar equipamentos de desenvolvimento, operações e segurança.

Finalmente, algumas referências úteis para quem quiser aprofundar: o repositório de CVE e as bases de dados de vulnerabilidades mantêm o registro formal de divulgações ( MITRE CVE e NVD – NIST), e os fornecedores especializados em validação e simulação oferecem plataformas para combinar as três capacidades mencionadas (por exemplo, fornecedores como Picus descrevem modelos de "security validation" que integram validação de controles e pentesting; ver Picus Security).

Em resumo: a emergência não está no número de CVE, mas na capacidade de cada organização para filtrar e validar quais vulnerabilidades são realmente exploradas e perigosas para seus ativos críticos. Priorizar segundo evidências de explorabilidade e efetividade de controles, automatizar a repriorização quando muda a evidência e revalidar após correção, É a rota prática para não se perder na maré de achados e concentrar recursos onde importam de verdade.