Priorizar Vulnerabilidades: o Patch Tuesday de 1.400 CVEs

Priorizar vulnerabilidades virou o trabalho principal de quem cuida de servidor em 2026. No dia 13 de outubro, a Microsoft publicou cerca de 1.400 correções de uma vez, o maior Patch Tuesday da história. Ninguém aplica 1.400 patches com o mesmo cuidado na mesma semana. Neste guia eu mostro o método que usamos para decidir o que entra primeiro, o que espera e o que nem precisava estar na fila.

TL;DR

• O Patch Tuesday de outubro de 2026 trouxe 1.407 CVEs pela contagem da Tenable, com 1 falha já explorada e outra divulgada antes do patch.
• O volume cresce porque Microsoft e Google passaram a usar IA para caçar falhas. As divulgações mensais de CVE quase dobraram entre janeiro e agosto de 2026.
• Só 0,23% das CVEs de 2026 foram vistas sendo exploradas. A nota CVSS não diz quais são.
• Para priorizar vulnerabilidades com método, cruze quatro sinais: inventário, KEV da CISA, EPSS e exposição na internet.
• Falha no KEV em ativo exposto se resolve em horas ou poucos dias. O resto entra na janela normal de manutenção.

O Patch Tuesday recorde de outubro de 2026 em números

O Patch Tuesday é a segunda terça de cada mês, quando a Microsoft solta o pacote de correções de segurança. Em 13 de outubro de 2026 a análise da Tenable contou 1.407 CVEs em 301 produtos e componentes (outros veículos chegaram a 1.411 ou 1.413). Foi o segundo mês seguido de recorde.

• 69 críticas, 1.337 importantes e 1 baixa;
• 47,9% de elevação de privilégio, quando quem já entrou vira administrador;
• 22,3% de execução remota de código (RCE), quando o atacante roda comandos na máquina à distância.

A Infosecurity Magazine lembrou que a Microsoft corrigiu pouco mais de 1.100 falhas em todo o ano de 2025. Um único mês de 2026 passou do ano inteiro.

As duas falhas que mereciam atenção no mesmo dia

A CVE-2026-96951 já estava sendo usada em ataques. Ela burla o Mark of the Web do Windows, o aviso de "este arquivo veio da internet": a vítima abre o anexo e o alerta não aparece. A CISA a colocou no catálogo de exploradas no mesmo dia, com prazo de três dias para os órgãos federais americanos e exigência de triagem forense.

A CVE-2026-108398, no .NET Framework, foi divulgada antes do patch e burla o Windows Defender Application Control. Não tem paliativo.

Duas em 1.407. É esse o desafio de quem precisa priorizar vulnerabilidades no mundo real: achar as poucas que importam no meio do volume.

Por que a IA multiplicou o volume de falhas

Em maio de 2026 a Microsoft apresentou o MDASH, um sistema com mais de 100 agentes de IA que auditam código, discutem se a falha é explorável e tentam provar o defeito. Na estreia ele achou 16 falhas novas no Windows, segundo o The Hacker News. Em julho a empresa já avisava os clientes que viria uma enxurrada de patches.

O relatório do Google Threat Intelligence Group (GTIG), de 30 de setembro de 2026, mediu o efeito no mercado inteiro:

• as divulgações mensais de CVE foram de 5.045 em janeiro para 10.740 em agosto de 2026;
• 50% das falhas atribuídas à descoberta por IA levam a RCE, contra 26% das demais;
• foram 141 falhas exploradas de janeiro a agosto de 2026, contra 127 em todo o ano de 2025;
• os ataques de dia zero subiram de 8 por mês em 2025 para 11 por mês em 2026.

A IA não só aumenta a pilha: ela acha falhas mais graves, e o atacante também usa IA. A recomendação do próprio Google é abandonar o "aplica tudo sem ordem" e adotar triagem guiada por inteligência de ameaças. Ou seja, priorizar vulnerabilidades deixou de ser opcional.

Por que a nota CVSS sozinha não serve para priorizar vulnerabilidades

O CVSS é a nota de 0 a 10 que acompanha cada CVE. Ele mede a gravidade teórica, o estrago se a falha for explorada. Não mede a probabilidade de alguém explorar, nem se o software existe na sua empresa. Usar CVSS como fila leva a dois erros caros.

Erro 1: tudo vira urgente

Em outubro foram 69 críticas e centenas de falhas com nota acima de 7. Se a regra é "corrigir tudo acima de 7 em 48 horas", ela já nasce descumprida. O time desiste do prazo e passa a corrigir na ordem de quem grita mais alto.

Erro 2: a falha explorada fica para depois

A CVE-2026-96951, a explorada, tinha CVSS 8,8 e classificação "Importante". Já a CVE-2026-70242, do painel de leitura do Outlook, tem CVSS 9,8. Pela nota, o Outlook viria antes. No mundo real, a do Windows Shell já estava sendo usada por atacantes.

Segundo o GTIG, só 0,23% das CVEs de 2026, cerca de 1 em 431, foram vistas sendo exploradas. Para priorizar vulnerabilidades com critério, a pergunta certa é: qual destas está ou vai estar sendo explorada, e eu tenho isso exposto?

Os quatro sinais para priorizar vulnerabilidades

Não existe ferramenta mágica. Existem quatro perguntas, respondidas nesta ordem.

1. Inventário de ativos: eu tenho isso?

Sem inventário não dá para priorizar vulnerabilidades, só palpitar. Inventário é a lista viva do que roda na empresa: servidores, sistema operacional, PHP, banco, painéis, plugins, SaaS e equipamentos de borda como firewall e VPN.

A maior parte das 1.407 CVEs de outubro não se aplica a uma empresa média. Quem não usa Exchange local nem SharePoint risca dezenas de itens em minutos. Quem não sabe se usa passa dias procurando.

Na nossa operação de hospedagem gerenciada e servidores Moodle, o inventário é a primeira coisa que montamos num cliente novo. E em quase todo diagnóstico aparece um servidor esquecido: a homologação que ninguém atualiza, o painel antigo aberto ao público.

2. KEV da CISA: alguém já está explorando?

O KEV (Known Exploited Vulnerabilities) é o catálogo público e gratuito da agência de cibersegurança dos EUA com falhas de exploração confirmada. Na versão de 6 de novembro de 2026, o catálogo KEV tinha 1.769 falhas, 285 incluídas em 2026 e 361 ligadas a campanhas de ransomware.

São centenas por ano contra dezenas de milhares de CVEs publicadas. O KEV é o filtro mais forte que existe para priorizar vulnerabilidades sem gastar nada. Falha do seu inventário que entrou no KEV vai para o topo da fila.

3. EPSS: qual a chance de ser explorada logo?

O EPSS (Exploit Prediction Scoring System), mantido pelo FIRST, calcula todo dia a probabilidade de cada CVE ser explorada nos próximos 30 dias. Ele cobre o que o KEV ainda não pegou.

Consultei a API pública do EPSS em 7 de novembro de 2026: eram 401.675 CVEs pontuadas e só 17.524, cerca de 4,4%, acima de 10% de probabilidade. Um corte que reduz a pilha de forma brutal.

Um cuidado: o EPSS é sinal de mercado, não do seu ambiente. A CVE-2026-96951, já no KEV, aparecia com EPSS de 9,8%: acima de 95% das CVEs, mas abaixo de um corte ingênuo de 10%. Por isso o KEV vem antes do EPSS.

4. Exposição: dá para chegar no ativo pela internet?

A mesma falha pesa diferente num servidor web público e numa estação sem acesso externo. A pergunta é: alguém sem login, de fora da rede, alcança isso? Painel de administração, VPN, firewall, e-mail e API pública contam como expostos. Ao priorizar vulnerabilidades, um ativo exposto sobe uma faixa na fila.

Quem cuida de hardening de servidor Linux sabe que reduzir exposição é a forma mais barata de ganhar prazo.

Um modelo de triagem em quatro faixas

Em junho de 2026 a CISA publicou a diretiva BOD 26-04, que substituiu a regra antiga do KEV e define prazos por quatro critérios: exposição pública, presença no KEV, se o ataque pode ser automatizado e se dá controle parcial ou total do ativo. O prazo mais curto é de três dias, com triagem forense. A diretiva só obriga órgãos federais americanos, mas a lógica serve para qualquer empresa.

Adaptamos essa lógica para priorizar vulnerabilidades na realidade de PME brasileira:

Faixa	Condição	Prazo sugerido	O que fazer
Emergência	No KEV e ativo exposto à internet	24 a 72 horas	Corrigir ou isolar já; procurar sinais de invasão
Alta	No KEV em ativo interno, ou EPSS alto em ativo exposto	Até 7 dias	Primeiro ciclo de manutenção
Normal	Crítica ou importante, sem exploração conhecida	Até 30 dias	Testar em homologação e aplicar no lote
Planejada	Baixa probabilidade, ativo sem exposição	Próxima atualização maior	Registrar e acompanhar

O detalhe que faz a tabela funcionar: a faixa muda. Uma falha "Normal" vira "Emergência" no dia em que entra no KEV. Por isso a triagem é rotina diária automatizada, não reunião mensal.

E corrigir nem sempre é aplicar o patch. Tirar o painel da internet ou bloquear a porta no firewall é mitigação: compra tempo, mas não fecha o chamado.

Exemplo prático: a triagem do Patch Tuesday de outubro

Veja como priorizar vulnerabilidades em quatro falhas reais do pacote, num cenário típico de empresa com estações Windows, Active Directory e Exchange local:

CVE	O que é	CVSS	KEV	EPSS (07/11)	Faixa
CVE-2026-96951	Windows Shell, burla do aviso de arquivo da internet	8,8	Sim	9,8%	Emergência
CVE-2026-70242	Outlook, RCE pelo painel de leitura	9,8	Não	1,6%	Alta (e-mail é porta de entrada)
CVE-2026-70229	Active Directory, RCE	8,1	Não	1,0%	Normal, ou Alta se exposto
CVE-2026-108398	.NET Framework, burla do WDAC	8,8	Não	0,8%	Normal, sem paliativo

Fontes: Tenable, Infosecurity Magazine, catálogo KEV e API do EPSS. O EPSS muda todo dia.

Pela nota CVSS, o Outlook viria primeiro. Pelo risco real, o Windows Shell vem primeiro, porque o ataque já estava em andamento. E o inventário muda tudo: quem usa só Microsoft 365 na nuvem não tem Exchange local para corrigir.

O resto das 1.400 entra no ciclo mensal, testado em lote. É isso que torna o recorde administrável: priorizar vulnerabilidades é decidir o que não precisa ser urgente.

Quando não correr para aplicar o patch

Velocidade sem critério também derruba sistema. Fora da faixa Emergência, segurar alguns dias é a decisão certa quando:

• o servidor é crítico e não tem homologação. Atualizar o AVA na véspera de prova sem testar troca um risco por uma queda certa;
• o sistema é legado. Se o patch exige versão que o sistema não roda, isole e planeje a migração;
• a correção tem problema conhecido. Patch que quebrou VPN ou login aparece em fóruns nas primeiras 48 horas.

As armadilhas que mais vemos

1. Confiar no painel da ferramenta. O scanner mostra "zero críticas" porque não enxerga o servidor que ninguém cadastrou.
2. Atualizar sem reiniciar o serviço. O processo antigo segue na memória, e a falha segue explorável.
3. Esquecer a borda. Firewall, VPN e roteador não entram no Windows Update.
4. Não procurar invasão. Corrigir uma falha já explorada fecha a porta com o invasor dentro.

Vimos isso em outubro com o PHP2Shell: quem tinha inventário e rotina de gestão de patches no servidor resolveu em horas; quem não tinha passou a semana descobrindo onde o PHP rodava.

Quanto custa e quem deve fazer a priorização

Há três caminhos, e o mais caro costuma ser o que parece de graça.

• Equipe interna: funciona com um analista que tenha tempo dedicado para priorizar vulnerabilidades toda semana. Em PME, o mesmo analista resolve impressora e senha, e a triagem fica para "quando der".
• Só ferramenta: scanners já trazem KEV e EPSS embutidos, mas não sabem que o servidor "de teste" guarda dados de clientes nem se dá para reiniciar o financeiro às 15h. Ferramenta sem processo vira relatório que ninguém lê.
• Consultoria externa: faz sentido quando falta repertório ou tempo, ou quando é preciso provar diligência para cliente, auditor ou seguradora. Uma consultoria de segurança da infraestrutura monta processo, inventário e prazos, e o time interno passa a operar com método.

Não decidir também custa. No DBIR 2026 da Verizon, a exploração de vulnerabilidade não corrigida virou a principal porta de entrada das violações (31%), e só 26% das falhas do KEV foram corrigidas no prazo. E a LGPD exige, no artigo 46, medidas de segurança técnicas e administrativas aptas a proteger dados pessoais. Patch conhecido e não aplicado é difícil de explicar depois de um incidente.

Como a Agathas Web resolve isso

A Agathas Web atua como consultora de segurança da infraestrutura de empresas. Operamos ambientes Moodle, hospedagem gerenciada, sistemas próprios e integrações com a API oficial do WhatsApp em produção, então aplicar patch sem derrubar cliente faz parte da nossa rotina.

Na consultoria de segurança, o trabalho segue estas etapas:

1. Conversa inicial gratuita (30 a 60 minutos) sobre a stack, o time e o que já deu problema. Sai daqui um escopo.
2. Inventário e auditoria com acesso somente leitura: servidores, cloud, aplicações e tudo o que está exposto na internet, com as aplicações avaliadas pelo OWASP Top 10 e pelo ASVS.
3. Matriz para priorizar vulnerabilidades com as quatro faixas deste guia, ajustada às suas janelas de manutenção.
4. Rotina de gestão de patches: alerta diário cruzando seu inventário com KEV e EPSS, teste em homologação e verificação pós-patch.
5. Hardening e monitoramento dos ativos expostos.
6. Plano de resposta a incidente para as primeiras horas de uma falha da faixa Emergência.

O diagnóstico leva de 4 a 6 semanas e termina com relatório executivo, plano de 3, 6 e 12 meses e quick wins para os primeiros 30 dias, com NDA assinado antes. Depois, a empresa pode seguir com acompanhamento mensal. A recomendação é independente: não vivemos de revender licença de ferramenta.

Conclusão: o volume vai continuar subindo

Com Microsoft, Google e atacantes usando IA para achar falhas, os próximos Patch Tuesdays tendem a ser grandes também. Tentar aplicar tudo com a mesma urgência é a receita para não aplicar nada direito.

O método para priorizar vulnerabilidades cabe em quatro perguntas: eu tenho isso, já está sendo explorado, qual a chance de ser explorado e está exposto. Quem responde isso todo dia transforma 1.400 CVEs numa lista curta de urgências e num lote mensal tranquilo.

Se a sua empresa ainda não responde essas perguntas, comece pelo inventário. E se quiser ajuda para montar o processo, fale com a consultoria da Agathas Web: a primeira conversa é gratuita.