Riscos, causas e soluções para vulnerabilidades não corrigidas

Principais conclusões

• Uma vulnerabilidade sem correção já tem uma correção disponível, mas que ainda não foi aplicada.
• M-Trends 2026 da Mandiant apresenta o tempo médio de exploração em menos sete dias; portanto, em média, os invasores conseguem contornar o patch antes que ele seja aplicado.
• O Relatório DBIR 2026 da Verizon constatou que apenas 26% das vulnerabilidades KEV detectadas foram totalmente corrigidas, com um tempo médio de 43 dias para que isso ocorresse.

A maioria das equipes de segurança têm a mesma lista de pendências. Ela contém os CVEs que foram triados, registrados, agendados e, em seguida, discretamente adiados porque a janela de manutenção coincidiu com o fechamento do trimestre. Essas são vulnerabilidades sem correção, e explorá-las tornou-se a principal forma conhecida pela qual os invasores obtêm acesso inicial.

A lacuna que realmente importa está entre a existência de um patch e o fato de esse patch estar efetivamente em execução na produção. O restante deste post analisa por que essa lacuna permanece aberta e como fechá-la.

O que se considera uma vulnerabilidade sem correção

Uma vulnerabilidade não corrigida é uma falha conhecida para a qual existe uma correção disponível, mas que está presente em um sistema no qual essa correção ainda não foi aplicada. São três elementos, todos necessários: uma falha conhecida, uma correção disponível e um sistema que ainda não a possui.

Essa parte do meio, a correção disponível, é o que a diferencia das duas ao lado.

Uma vulnerabilidade de dia zero é explorada antes que os defensores tenham tido uma chance razoável de reagir, geralmente antes da divulgação ou antes que exista uma correção. Até que uma correção seja lançada, as medidas de mitigação são tudo o que você tem. Nossa análise de como explorações de dia zero cobre esse caso.

Software em fim de vida útil é o outro vizinho. É possível aplicar correções, mas o fornecedor original parou de disponibilizá-las. CentOS 7, PostgreSQL 13, um ramo do PHP em fim de vida (EOL) – CVEs reais, exposição real, sem suporte do desenvolvedor original.

No papel, a vulnerabilidade sem correção é a mais evitável das três, já que a correção já existe e geralmente é gratuita. Na prática, um patch gratuito ainda custa tempo de teste e uma janela de manutenção, o que constitui metade do tema deste post.

O intervalo de tempo entre a divulgação e a exploração da vulnerabilidade é mais curto do que a maioria dos ciclos de atualização pressupõe, e nem sempre ocorre em ordem.

Palco	Quando isso acontecer	O que está acontecendo
CVE divulgado, correção lançada	No mesmo dia ou com semanas de diferença	Frequentemente combinados para RCE crítica
PoC público ou código de exploração	Em qualquer momento, desde antes da divulgação até semanas depois	GitHub, frameworks de exploração, relatórios de pesquisa
Varredura em massa na internet	Algumas horas após um PoC funcional	Os invasores identificam instâncias expostas em grande escala
Exploração ativa, listagem na KEV	Pode começar antes da divulgação, e a listagem na KEV ocorre após a CISA confirmar isso	Agora, um vetor de ataque confirmado e em uso

A gravidade e a probabilidade de exploração são indicadores diferentes. Um CVSS 9,8 em um serviço que você não expõe pode ser menos perigoso do que um CVSS 6,5 presente na sua infraestrutura de borda. Confira nosso guia passo a passo sobre o que mudou no CVSS v4.0.

O custo real das vulnerabilidades não corrigidas

Comece com um número que você deveria parar de repetir: “vulnerabilidades não corrigidas causam 60% das violações.” Essa informação remonta a uma pesquisa realizada em 2019 pelo Ponemon Institute para a ServiceNow e não deve mais ser citada como um dado atual e válido para todo o setor.

Os dados atuais revelam um quadro mais nítido. No Relatório Anual de Investigação sobre Violações de Dados (DBIR) da Verizon de 2026, 31% das violações começaram com a exploração de vulnerabilidades, um aumento em relação aos 20% do ano anterior. Isso a tornou o principal vetor de acesso inicial conhecido no conjunto de dados da Verizon pela primeira vez na história do relatório. As violações também ficaram mais caras. O Relatório de 2026 da IBM sobre o Custo de uma Violação de Dados estima o custo médio global de uma violação em US$ 4,99 milhões, um recorde.

O ransomware é a exceção. Na pesquisa “State of Ransomware 2026” da Sophos, apenas 18% das vítimas de ransomware identificaram a origem do ataque em uma vulnerabilidade explorada, uma queda em relação aos 32% registrados no ano anterior, já que e-mails maliciosos e phishing passaram a ser as principais causas. A aplicação de patches ainda é importante nesse caso. Só que não é mais a única porta de entrada.

Os prejuízos se traduzem em riscos regulatórios, extorsão por ransomware, tempo de inatividade, constatações de não conformidade e um impacto reputacional que perdura muito além de tudo isso. Nossa análise dos custos reais de não aplicar patches a um CVE crítico aborda cada um desses aspectos com mais profundidade.

Três casos de violação mostram como isso ocorre, cada um de maneira um pouco diferente.

Incidente	CVE	Patch disponível	Exploração	Consequências
Equifax	CVE-2017-5638 (Apache Struts 2)	7 de março de 2017	O portal foi analisado e apresentou vulnerabilidades em 10 de março de 2017; dados pessoais foram acessados a partir de 13 de maio e a vulnerabilidade foi detectada em 29 de julho	147 milhões de pessoas, além de um acordo entre a FTC, a CFPB e os estados no valor de pelo menos US$ 575 milhões
MOVEit Transfer	CVE-2023-34362	31 de maio de 2023	A exploração em massa da vulnerabilidade Cl0p, como um ataque “zero day”, ocorreu entre 27 e 28 de maio de 2023, e servidores sem patch continuaram sendo atacados por semanas a fio	2.773 organizações, cerca de 95,8 milhões de pessoas (Emsisoft)
Log4Shell	CVE-2021-44228	Log4j 2.15.0, 10 de dezembro de 2021, com correções adicionais dias depois	Análise a partir de 1º de dezembro de 2021: exploração em massa poucas horas após a divulgação	Quase 40 milhões de downloads vulneráveis do Log4j somente em 2025, o que representa cerca de 13% do total daquele ano (Sonatype)

O caso da Equifax é um exemplo clássico de vulnerabilidade não corrigida. A correção foi lançada em 7 de março; os invasores começaram a sondar o portal três dias depois; e o roubo em massa de dados teve início 67 dias após a disponibilização do patch. Os casos do MOVEit e do Log4Shell começaram como vulnerabilidades “zero-day”, mas se transformaram em casos de vulnerabilidades não corrigidas quase imediatamente, assim que as correções foram disponibilizadas e muitas instalações continuaram executando a versão vulnerável mesmo assim.

Por que as vulnerabilidades não são corrigidas (os motivos que as equipes raramente admitem)

Cada uma dessas decisões é racional e local, mas, no conjunto, levam a um resultado irracional em toda a organização.

Motivo	Como é	O que o remove
Medo de paralisação	O CVE do kernel requer uma reinicialização, e o host é stateful, sem failover	Aplicação de patches no kernel sem reinicialização
Software em fim de vida útil, sem patch do upstream	Servidor CentOS 7 executando um aplicativo que não compila em versões mais recentes	Suporte estendido oferecido pelo fornecedor ou uma data de migração financiada
Atualizações que nunca são lançadas	A automação apresenta uma taxa de sucesso de 98%. Os outros 2% estão na corda bamba	Reconciliação entre os dados das ferramentas de correção e as varreduras independentes
Ativos desconhecidos	Uma VM de teste de 2021, um contêiner de um prestador de serviços, um subdomínio esquecido	Descoberta contínua e permanente
Custos indiretos de testes	Cada patch passa por testes de regressão em um monólito que ninguém entende completamente	Testes por níveis de risco, com correções críticas de segurança priorizadas por meio de implementações em etapas
Mais CVEs do que tempo disponível para triagem	48.185 CVEs publicados em 2025. Três pessoas não conseguem ler isso	Filtragem baseada na vulnerabilidade

 O volume, por si só, já é um motivo. O pesquisador de segurança Jerry Gamblin sobre os dados do CVE de 2025 registrou 48.185 registros publicados, cerca de 132 por dia, enquanto a própria página EPSS da FIRST sugere que apenas uma porcentagem baixa, de um único dígito, dos CVEs publicados é explorada em qualquer janela de 30 dias. A maior parte da fila não será alvo de um invasor neste mês. O difícil é saber qual parcela será.

Depois, há o acúmulo. Correções adiadas se transformam em dívida de segurança da mesma forma que refatorações adiadas se transformam em dívida técnica, e os juros se manifestam na forma de um incidente. O ruído dos scanners agrava a situação, pois equipes que desperdiçam semanas investigando um falso positivo perdem a credibilidade de que precisam quando surge um incidente real. O fim da vida útil do SO faz parte desse mesmo ciclo contínuo de descoberta.

Um padrão comum em empresas de médio porte não é uma equipe que opta por não aplicar patches. Trata-se de uma ferramenta de orquestração que relata sucesso em um servidor que, sem que ninguém percebesse, havia deixado de estar conectado ao agente de gerenciamento de configuração meses antes. Ninguém mentiu. A camada de relatórios mediu o parâmetro errado.

Como os invasores exploram vulnerabilidades sem correção

Veja isso do ponto de vista do invasor. Um zero-day custa tempo de pesquisa ou valores na casa das seis cifras ou mais no mercado de corretagem. Um n-day — ou seja, uma falha com correção pública — pode custar pouco mais do que uma consulta no Shodan, desde que haja uma prova de conceito funcional e alvos expostos suficientes para atacá-la. Os invasores recorrem aos zero-days quando precisam e aos n-days sempre que podem, e o processo de divulgação reabastece o estoque de n-days todos os dias.

O relatório M-Trends 2026 da Mandiant apresenta um número concreto sobre o quanto essa lacuna se reduziu. O tempo médio até a exploração é agora estimado em menos sete dias, o que significa que, em média, a exploração começa antes mesmo do lançamento do patch. As explorações ocupam o primeiro lugar como o vetor de infecção inicial mais comum há seis anos consecutivos, representando agora 32% das invasões nas quais a Mandiant conseguiu identificar o ponto de entrada.

O catálogo de vulnerabilidades exploradas conhecidas da CISA é o quadro de resultados público para falhas que passaram do estágio teórico para o de uso ativo, e cresce a cada semana. Os prazos que ele estabelece para as agências civis federais dos EUA foram alterados em 2026. A BOD 22-01, que desde 2021 concedia às agências duas semanas para corrigir entradas do KEV (seis meses para CVEs mais antigas), foi substituída, juntamente com a antiga BOD 19-02, pela BOD 26-04, “Priorização de Atualizações de Segurança com Base no Risco”, emitida em 10 de junho de 2026.

Em vez de um prazo único e fixo, a nova diretiva avalia cada vulnerabilidade com base em quatro fatores. O ativo está exposto publicamente? A falha está no KEV? A exploração pode ser automatizada? Ela concede ao invasor controle total do sistema ou apenas parcial? As respostas determinam o prazo. As combinações de maior risco têm três dias, e os casos de KEV de risco mais elevado que envolvem controle total também exigem uma triagem forense para verificar se o sistema já foi comprometido. Todos os demais casos recebem 14 ou 60 dias, e as falhas que não se enquadram em nenhum dos quatro fatores podem aguardar a próxima atualização programada do ativo.

Muitas falhas amplamente exploradas são vulnerabilidades que permitem a execução remota de código em serviços conectados à Internet e dispositivos de borda; e, às vezes, o sistema vulnerável nem sequer é de sua responsabilidade corrigir. O MOVEit é o exemplo mais recente e claro disso. Uma falha em um produto de transferência de arquivos amplamente utilizado resultou em milhares de vítimas em cadeia.

Para as agências civis federais, três dias é agora o limite máximo para o nível mais grave, e um conselho consultivo de mudanças semanais não pode ultrapassá-lo. Se a sua resposta mais rápida possível a um RCE voltado para a internet e que esteja sendo explorado ativamente RCE que está sendo ativamente explorada e exposta à internet demorar mais de três dias, essa é uma lacuna no processo que vale a pena corrigir antes que a próxima vulnerabilidade seja descoberta.

Como evitar que as vulnerabilidades sem correção se acumulem

Trata-se de um problema de processo com cinco componentes, e pular direto para a definição de prioridades antes de ter feito um levantamento significa apenas priorizar um subconjunto que você não consegue identificar completamente.

Identifique primeiro todas as vulnerabilidades que ainda não receberam correção

Nesse caso, a abrangência supera a sofisticação. Um modelo de priorização perfeito que abranja 70% do seu patrimônio é menos útil do que uma triagem rudimentar que abranja a totalidade dele.

Crie seu inventário a partir de mais de um ângulo, já que cada fonte deixa passar algo diferente. O gerenciamento de configuração e o inventário de agentes não detectam nada que tenha se desligado do agente. As APIs dos provedores de nuvem não detectam sistemas locais nem contas ocultas. A varredura de rede autenticada não detecta hosts que estavam desligados durante o período da varredura. A descoberta de DNS e da superfície de ataque externa é o que identifica o subdomínio que ninguém se lembra de possuir.

Em seguida, faça a reconciliação. A parte útil está justamente onde essas listas divergem. Um host que aparece no seu inventário na nuvem, mas não nos resultados do seu scanner, é exatamente o tipo de lacuna que leva a uma violação de segurança. Assim que a lista de ativos estiver confirmada, compare os pacotes e versões instalados em cada host com os alertas de segurança aplicáveis a eles, para que você saiba quais desses hosts estão realmente vulneráveis.

Verifique também se as correções relatadas foram realmente implementadas. O fato de haver um pacote de kernel mais recente no disco não significa que o kernel em execução esteja protegido. A menos que o host tenha sido reiniciado com esse pacote ou tenha recebido uma correção dinâmica para essa CVE, trata-se de uma vulnerabilidade que apenas ostenta o rótulo de “corrigida”.

Priorizar com base na explorabilidade real

O número bruto de CVEs mede a carga de trabalho. Para avaliar o risco real, são necessários mais três fatores.

Comece pelo KEV. Uma listagem significa que a exploração em ambiente real foi confirmada; portanto, se isso afetar seus ativos, aplique a correção imediatamente, independentemente da pontuação CVSS. Em seguida, verifique a pontuação EPSS, uma probabilidade atualizada diariamente, de 0 a 1, de que um CVE publicado seja explorado em ambiente real nos próximos 30 dias. É gratuito, legível por máquina e desenvolvido exatamente para essa decisão. Por fim, avalie separadamente a exposição e a importância comercial. O ativo está exposto à Internet ou é acessível a partir de sistemas nos quais um invasor já possa estar? Ele contém dados confidenciais ou sujeitos a regulamentação?

As próprias comparações da FIRST demonstram bem a questão da eficiência. Uma regra genérica de CVSS 7 ou superior encaminha uma parcela enorme da fila para correção, enquanto um limite do EPSS detecta uma grande parte do que realmente é explorado, com apenas uma pequena fração do trabalho. No entanto, não existe um limite universal que possa ser copiado. O limite correto depende da sua própria fila.

Se sua equipe não dispõe de recursos suficientes, comece com o KEV e a exposição e, posteriormente, incorpore o EPSS. Se você já aplica os patches do KEV de forma confiável, o EPSS é o que proporciona o próximo nível de redução de riscos.

Aplique as correções rapidamente e elimine os motivos que impedem que você faça isso

A agilidade vem da eliminação do atrito no processo. Automatize a implantação para que a aplicação de patches ocorra como um fluxo contínuo, em vez de um projeto pontual, já que um patch que depende de uma pessoa para ser agendado tende a ser adiado.

Então, lide diretamente com a dependência da reinicialização. As reinicializações são um dos motivos mais comuns pelos quais os patches do kernel ficam sem serem aplicados. Elas exigem uma janela de manutenção, um ticket de alteração e alguém acordado às 2 da manhã para confirmar que o servidor voltou a funcionar. A aplicação de patches sem reinicialização, às vezes chamada de correção em tempo real, aplica a correção ao kernel em execução na memória; assim, para vulnerabilidades suportadas, a falha é corrigida sem interrupção do serviço.

KernelCare faz isso nas principais distribuições Linux corporativas, de modo que um ambiente misto não precisa de uma ferramenta separada para cada sistema operacional, e as cargas de trabalho 24 horas por dia, 7 dias por semana deixam de sacrificar o tempo de atividade em troca da exposição a vulnerabilidades CVE.

Abranger softwares em fim de vida útil (EOL) que não tenham patch do fornecedor

Tudo o que foi dito acima pressupõe que o fornecedor ainda disponibilize uma correção. No caso de componentes em fim de vida útil (EOL), o fornecedor original não o faz, e a recomendação padrão de simplesmente atualizar ignora a razão pela qual o sistema ainda está em funcionamento.

Geralmente, o problema se resume a um hardware que não é compatível com um kernel mais recente, um aplicativo cujo fornecedor certificou apenas uma versão do sistema operacional, uma validação regulatória que precisaria ser refeita do zero ou uma capacidade de engenharia já comprometida para os próximos três trimestres. Um e-mail severo sobre as datas de fim de vida útil (EOL) não resolve nenhum desses problemas.

Isso deixa três opções viáveis.

Opção	Ideal para quando	Fique atento a
Migre agora	O aplicativo é portátil e você tem capacidade neste trimestre	Os deslizamentos são normais, e a exposição continua durante o deslizamento
Apenas controles de compensação	Totalmente isolado, sem caminho de entrada não confiável	O isolamento se deteriora silenciosamente. Uma alteração no firewall o reabre
Suporte estendido oferecido pelo fornecedor	É necessário que as vulnerabilidades (CVEs) sejam corrigidas durante a migração, de acordo com o seu próprio cronograma	Confirme exatamente quais pacotes do sistema operacional, ambientes de execução e bibliotecas estão incluídos

Esse terceiro caminho é o que o Suporte de Ciclo de Vida Ilimitado da TuxCare da TuxCare. Ele fornece patches de segurança para os ambientes de execução, bibliotecas, frameworks e aplicativos que já não recebem mais suporte do desenvolvedor original, juntamente com as distribuições Linux em fim de vida útil (EOL) nas quais eles se baseiam, por meio do gerenciamento padrão de pacotes. Os sistemas cobertos continuam recebendo correções de segurança, com documentação comprovativa, enquanto a migração ocorre em um cronograma que a empresa pode realmente financiar.

Verifique a correção e comprove-a

A aplicação de patches sem verificação é uma crença. Há dois fatores que tornam difícil confiar no status dos patches.

A primeira é uma falha silenciosa. O pacote foi instalado, mas o serviço nunca reiniciou, ou o host reverteu as alterações, ou a atualização foi aplicada à imagem base e não ao contêiner em execução. A segunda é um falso positivo. Um scanner lê uma string de versão, não detecta uma correção retroativa e sinaliza um CVE encerrado como ainda aberto.

Uma boa verificação gera alguns resultados concretos. Você obtém a confirmação, diretamente do sistema em execução, de que o código corrigido foi realmente carregado, além de uma reconciliação entre o relatório da sua ferramenta de correção e uma verificação independente. Cada host e CVE recebe um registro datado e exportável, pronto para ser apresentado a um auditor. E seus tickets tratam “corrigido” como confirmado, enquanto “tentado” é rastreado como um status separado.

A verificação que leva em conta o backport é o ponto fraco do Linux, já que os scanners genéricos costumam interpretar incorretamente os pacotes nos quais a distribuição fez um backport de uma correção, mantendo o número da versão do desenvolvedor original. Seja qual for o scanner que você utilizar, compare os resultados com os alertas de segurança da própria distribuição antes de desperdiçar tempo com um CVE que já foi resolvido.

Como a TuxCare preenche essa lacuna

É na lacuna entre “patch disponível” e “patch em execução” que ocorrem muitas violações de segurança. A Equifax já contava com a correção há 67 dias antes do início do roubo de dados. No caso do Log4Shell, os invasores já estavam em ação antes mesmo de o primeiro patch existir. As equipes que conseguem eliminar essa lacuna tendem a ser aquelas que removeram as causas estruturais do atraso, a saber: impasses relacionados ao fim da vida útil (EOL), pacotes vulneráveis que continuam se infiltrando nas compilações e reinicializações.

A abordagem da TuxCare se alinha diretamente a esses três pontos. Suporte ao ciclo de vida ilimitado abrange os ambientes de execução, frameworks, aplicativos e sistemas operacionais dos quais seus fornecedores originais já se afastaram. O SecureChain substitui os registros públicos por um gerenciado pela TuxCare, com pacotes selecionados e continuamente atualizados para JavaScript, Python, Java, Go e PHP, o que ajuda a manter versões com vulnerabilidades conhecidas fora das novas compilações. O KernelCare cuida da aplicação de patches no kernel sem reinicialização em ambientes Linux mistos. Escolha a opção que melhor se adequa ao seu perfil de risco.

Comece com um inventário em que você confie. Depois, decida o que corrigir primeiro.

Perguntas frequentes