Em uma única semana de outubro, a Microsoft publicou mais de 1.400 correções em um só Patch Tuesday, uma falha crítica no PHP começou a ser explorada antes mesmo de ser divulgada e agentes de inteligência artificial quase autônomos invadiram mais de 100 sites corporativos.
O recado para CISOs e conselhos é direto: nenhuma empresa consegue corrigir tudo ao mesmo tempo. A pergunta que importa não é quantas vulnerabilidades existem no ambiente, mas quais exposições a organização não pode se dar ao luxo de ignorar.
É essa pergunta que o Exposure Management responde: conectar visibilidade, inteligência de ameaças, contexto do negócio e priorização contínua.
Neste vídeo, Felipe Lima Franco, Arquiteto de Soluções da CG One, aborda casos envolvendo PHP, GitLab, certificados digitais e inteligência artificial para mostrar por que a severidade técnica de uma vulnerabilidade nem sempre representa seu impacto real para o negócio.
Os casos que marcaram a semana
Os incidentes atingiram aplicações, infraestrutura, cadeia de confiança digital e a própria cadeia de suprimentos de IA. Cada um ensina uma lição diferente sobre priorização.
Caso | O que aconteceu | Por que importa para o negócio |
PHP2Shell (CVE-2026-109618 e CVE-2026-109619) | Duas falhas críticas (CVSS 9.2) no PHP, base de grande parte das aplicações web. Tentativas de exploração foram observadas antes da divulgação pública. | O atacante chegou antes do patch. Quem depende só do ciclo de correção fica exposto. |
GitLab (CVE-2026-110264) | Execução remota de código sem autenticação, severidade máxima (CVSS 10). Versões corrigidas em 12/10 continuam vulneráveis. | “Corrigido” não significa “protegido”. Repositórios, credenciais e pipelines de CI/CD ficam em risco. |
Recorde de mais de 1.400 vulnerabilidades corrigidas no mês. Apenas uma (CVE-2026-96951, Windows Shell) com exploração ativa confirmada. | Volume sem contexto paralisa. Saber qual delas já é explorada muda a ordem de tudo. | |
Oito chaves de autoridades certificadoras intermediárias comprometidas. Mozilla, Google e Apple bloquearam os certificados. | Risco de terceiros na cadeia de confiança digital, que raramente aparece em inventário. | |
Biblioteca usada para integrar modelos de IA foi comprometida na cadeia de suprimentos. Credenciais de nuvem roubadas foram usadas cerca de 4,5 horas depois. | A adoção de IA já é superfície de ataque. O intervalo entre roubo e uso é de horas. | |
Node.js (CVE-2026-111497) | Dez falhas corrigidas, uma delas permitindo execução de comandos via Brotli. O Node 20, fora de suporte, não será corrigido. | Software fora de suporte vira exposição permanente. |
Duas falhas de execução remota (CVSS 9.0) no servidor SMB do kernel Linux, ainda sem correção. | Sem patch disponível, a proteção depende de controles compensatórios. | |
Um atacante usou um enxame de agentes de IA quase autônomos para invadir mais de 100 sites, incluindo páginas de John Deere, Cummins e SharkNinja. | A IA reduz o esforço do ataque e encurta o tempo entre a exposição e o comprometimento. |
O ponto em comum: em quase todos os casos, a severidade técnica sozinha não dizia o que tratar primeiro. O que fazia a diferença era saber se o ativo estava exposto, se já havia exploração e o que ele sustentava no negócio.
Por que o CVSS sozinho não define a prioridade
As empresas já têm ferramentas que encontram vulnerabilidades. O problema é o que vem depois: listas extensas de correções, sem clareza sobre o que tratar primeiro.
O Common Vulnerability Scoring System (CVSS) mede a severidade técnica de uma falha. Mas uma nota crítica não significa, necessariamente, o maior risco para uma organização específica. Considere dois cenários:
- Uma vulnerabilidade crítica em um servidor isolado, sem acesso externo e protegido por controles adicionais.
- Uma vulnerabilidade alta em um serviço exposto à internet, que sustenta um processo essencial e já tem exploração ativa.
A segunda exige resposta mais urgente. A diferença está no contexto: exposição do ativo, possibilidade de exploração, privilégios envolvidos, controles existentes e impacto no negócio.
Duas referências públicas ajudam nessa leitura: o catálogo Known Exploited Vulnerabilities (KEV), da CISA, que reúne falhas com exploração confirmada, e o Exploit Prediction Scoring System (EPSS), da FIRST, que estima a probabilidade de exploração. São complementares, e nenhuma delas substitui a análise do ambiente da própria empresa.
Exposure Management: da lista de falhas à redução contínua de risco
Exposure Management deixa de perguntar “quais falhas existem” e passa a perguntar “quais exposições podem ser exploradas e o que elas atingem”. Isso exige correlacionar inventário, configurações, vulnerabilidades, identidades, conectividade e inteligência de ameaças, informações que hoje costumam estar espalhadas entre ferramentas e equipes.
A abordagem segue o modelo de Continuous Threat Exposure Management (CTEM), em ciclo contínuo:
- Identificar a superfície de ataque. Ambientes locais, nuvem, aplicações, APIs, identidades e ativos externos. O que não é conhecido não entra no processo de correção.
- Avaliar as exposições. Nem toda exposição é uma falha de software: configurações inadequadas, permissões excessivas, credenciais vazadas e serviços desnecessariamente acessíveis também contam.
- Priorizar pelo risco real. Cruzar severidade, explorabilidade, exposição e impacto no negócio.
- Validar os caminhos de ataque. Verificar se o atacante consegue, de fato, alcançar o ativo vulnerável ou combinar exposições para chegar a sistemas críticos.
- Corrigir e acompanhar. Confirmar que a correção funcionou. O caso do GitLab mostra por quê: um patch aplicado não encerrou a exposição.
A inteligência artificial mudou o relógio
O uso de IA em ataques deixou de ser hipótese. Nesta semana, pesquisadores identificaram um atacante operando um enxame de agentes de IA quase autônomos, que recebiam um objetivo e trabalhavam sozinhos até cumpri-lo. Mais de 100 sites foram invadidos, segundo a cobertura do caso.
A IA não elimina a necessidade de explorar uma falha ou obter acesso. Mas reduz o esforço e acelera etapas como reconhecimento, escolha de alvos e automação. Ao mesmo tempo, a própria adoção de IA pelas empresas cria novas exposições, como mostrou o comprometimento do LiteLLM.
Resultado: organizações que dependem de avaliações trimestrais ou anuais ficam para trás. A exposição muda em dias; o ataque, em horas.
Sua empresa está priorizando os riscos certos?
Seis perguntas que todo CISO deveria conseguir responder hoje:
- Temos visibilidade atualizada dos ativos expostos à internet e de quem é responsável por eles?
- Priorizamos vulnerabilidades por exploração ativa, criticidade do ativo e impacto operacional?
- Conseguimos identificar caminhos de ataque que envolvem vários sistemas?
- Sabemos dizer, em até 24 horas, se um caso como o PHP2Shell afeta o nosso ambiente?
- Validamos se as correções e os controles compensatórios realmente funcionaram?
- Acompanhamos a evolução da nossa exposição ao longo do tempo?
Se as respostas dependem de análises manuais ou de informações fragmentadas, há uma oportunidade clara de amadurecimento. O objetivo não é eliminar todas as vulnerabilidades, algo inviável em ambientes dinâmicos, mas reduzir continuamente as exposições com maior potencial de dano.
Como a CG One endereça cada gap
Cada caso da semana revela um gap específico. O portfólio de cybersecurity da CG One foi estruturado para fechar esses gaps de forma integrada, e não como ferramentas isoladas.
Gap revelado pela semana | Capacidade que fecha o gap |
Não sei o que está exposto nem o que corrigir primeiro (Patch Tuesday recorde) | Exposure Management contínuo (CTEM), com priorização por exploração ativa e contexto de negócio |
A falha é explorada antes do patch (PHP2Shell, GitLab, ksmbd) | Virtual patching e proteção de aplicações e APIs (WAF/WAAP), que bloqueiam a exploração enquanto a correção não chega |
Não sei se um atacante consegue chegar até o ativo vulnerável | Validação do caminho de ataque na rede, com análise de conectividade e de regras de firewall |
Um ativo comprometido abre caminho para o resto do ambiente | Microssegmentação para conter o movimento lateral |
IA ofensiva e a cadeia de suprimentos de IA (agentes autônomos, LiteLLM) | AI Security: proteção do uso de IA generativa, de aplicações de IA e de agentes |
Descubra, antes do atacante, quais exposições sua empresa não pode ignorarOs casos desta semana têm algo em comum: as empresas atingidas não sabiam onde estavam expostas até o atacante mostrar. A CG One propõe inverter essa ordem. Em uma conversa com os especialistas da CG One, sua empresa pode: ■ Entender o que está exposto hoje, incluindo ativos voltados para a internet que não aparecem no inventário. ■ Identificar as exposições que realmente importam, considerando exploração ativa e impacto nos processos críticos, e não só a nota CVSS. ■ Responder à pergunta da semana: casos como PHP2Shell, GitLab e LiteLLM afetam o seu ambiente? ■ Definir as próximas ações: o que tratar agora, o que proteger enquanto o patch não chega e o que acompanhar continuamente. São mais de 30 anos protegendo grandes empresas brasileiras, como o maior parceiro Check Point do Brasil e com parcerias com os principais fabricantes globais de segurança. Fale com um especialista da CG One. A próxima vulnerabilidade crítica já está a caminho. A diferença é se você vai descobri-la antes ou depois do atacante. |