Vulnerabilidade sem patch: como mitigar até a correção sair

O que fazer com uma vulnerabilidade sem patch

Vulnerabilidade sem patch é uma falha conhecida para a qual ainda não existe correção do fabricante, ou cuja correção não pode ser aplicada agora. O tratamento é mitigar: bloquear o vetor de exploração com mudança de configuração, workaround, patch virtual ou controle compensatório, validar que funcionou e rastrear o item até a correção definitiva.

Esperar o fabricante não é uma estratégia. Entre a divulgação de uma falha e a chegada do patch podem passar dias ou semanas, e há casos em que o patch nunca vem, como em produtos fora de suporte. Nesse intervalo o atacante já tem a informação de que precisa. O que separa uma empresa exposta de uma protegida é o que ela faz enquanto o pacote não existe.

Este guia mostra por que vulnerabilidades ficam sem patch, a diferença entre mitigação, workaround, patch virtual e controle compensatório, um passo a passo para tratar cada caso, dois exemplos reais de mitigação que falhou e como evitar que uma solução provisória vire permanente. Para entender o termo base, veja o que é patch.

Resumo em 5 pontos

1. Sem patch não significa sem ação. Quase toda vulnerabilidade tem alguma contramedida: desligar o componente, restringir acesso, mudar configuração.
2. A janela é curta. Em 2023, 70% das vulnerabilidades exploradas analisadas pela Mandiant foram atacadas como zero-day, antes de haver correção.
3. Mitigação precisa de validação. Contramedidas recomendadas já se mostraram insuficientes, como no Log4Shell e no Ivanti Connect Secure.
4. Workaround tem prazo e dono. O item continua aberto até a correção definitiva; senão, o provisório vira permanente.
5. O KEV define a urgência. Falha com exploração ativa vai para a fila emergencial, com ou sem patch publicado.

Leia também: Remediação automática de vulnerabilidades, com ou sem patch

Por que existem vulnerabilidades sem patch

"Sem patch" cobre situações diferentes, e cada uma pede uma resposta diferente. Identificar em qual delas o item se encaixa é o primeiro passo.

A última linha merece atenção: muita coisa classificada como "sem patch" na verdade não precisa de patch. Vulnerabilidade de configuração se corrige mudando o estado do ativo, e essa mudança é definitiva enquanto for mantida. Quando a equipe trata esses itens como "aguardando fabricante", eles ficam parados sem motivo.

O tamanho do problema

Os dados mostram por que esperar o patch é arriscado:

• 70% como zero-day: das 138 vulnerabilidades divulgadas em 2023 e exploradas, analisadas pela Mandiant, 97 (70%) foram exploradas como zero-day, antes de haver correção disponível. O tempo médio até a exploração caiu para 5 dias.
• 32,1% no dia zero: no primeiro semestre de 2025, 32,1% das vulnerabilidades exploradas rastreadas pela VulnCheck tinham evidência de exploração no dia da publicação da CVE ou antes, contra 23,6% em 2024.
• Mais de 60% fora do prazo: a Bitsight analisou 1,4 milhão de organizações e encontrou mais de 60% das vulnerabilidades do CISA KEV ainda sem mitigação depois do prazo da CISA.
• 174 dias: mediana para corrigir falhas do KEV, segundo a mesma pesquisa da Bitsight, contra 621 dias para as que não estão no catálogo.

Ou seja: mesmo quando o patch existe, o ciclo é lento; quando não existe, a exposição dura até alguém agir sem ele. A própria Bitsight passou a medir, CVE a CVE, se as organizações fecham falhas aplicando patch ou workaround, justamente porque o workaround é parte real de como as vulnerabilidades são tratadas.

Mitigação, workaround, patch virtual e controle compensatório

Os termos se misturam no dia a dia, mas indicam coisas diferentes. A diferença define o que validar e quanto tempo a medida pode durar.

Patch virtual: quando faz sentido

Patch virtual, como define a Fortinet, é a proteção que intercepta e bloqueia tentativas de exploração na camada de rede ou de aplicação, impedindo que o tráfego malicioso chegue ao ativo até que o patch definitivo possa ser aplicado. É útil para equipamentos que não podem ser reiniciados, sistemas industriais e aplicações web legadas.

O limite é claro: o ativo continua vulnerável. Se o atacante chega por outro caminho (de dentro da rede, por um vetor que a assinatura não cobre, por tráfego cifrado que o IPS não inspeciona), o patch virtual não ajuda. Use como camada temporária, nunca como fechamento.

Como tratar uma vulnerabilidade sem patch: passo a passo

Siga esta sequência para cada item sem correção disponível:

1. Confirme a exposição real. O componente vulnerável está instalado e ativo? O serviço é alcançável, de fora ou de dentro? Uma falha em recurso desligado tem prioridade diferente de uma em serviço exposto à internet.
2. Classifique a urgência. Verifique se a CVE está no CISA KEV e a probabilidade de exploração pelo EPSS. Exploração ativa manda o item para a fila emergencial.
3. Leia o aviso do fabricante e da CISA. Quase todo aviso de segurança traz uma seção de mitigação ou workaround. Comece por ela antes de inventar contramedidas.
4. Escolha a medida pela situação. Configuração insegura: corrija o estado. Patch a caminho: mitigação do aviso. Fora de suporte: isolamento e plano de substituição. Patch que não pode entrar: workaround com prazo.
5. Aplique em grupo piloto. Contramedidas também quebram coisas. Teste em ativos com o mesmo perfil da produção e tenha rollback pronto.
6. Valide que funcionou. Confirme que o vetor está bloqueado: parâmetro aplicado, serviço desligado, porta fechada, nova varredura sem o achado de configuração. Mitigação aplicada não é mitigação eficaz.
7. Registre o risco residual com dono e prazo. Documente a medida, quem aprovou o risco que sobrou e quando a correção definitiva deve entrar.
8. Monitore a chegada do patch. Acompanhe o aviso do fabricante. Quando a correção sair, ela entra na fila como qualquer outra.
9. Feche com a correção definitiva. Aplique o patch, remova a mitigação quando o fabricante orientar (como no caso Ivanti, abaixo) e confirme com re-scan que a CVE sumiu.

Dois casos em que a mitigação falhou

A validação do passo 6 parece óbvia até a primeira mitigação falhar. Dois episódios públicos mostram o risco.

Log4Shell (CVE-2021-44228), dezembro de 2021. Nos primeiros dias, uma das mitigações mais divulgadas foi configurar a propriedade log4j2.formatMsgNoLookups como verdadeira. A medida se mostrou insuficiente para cobrir todos os casos, e a orientação passou a ser remover a classe JndiLookup do pacote ou atualizar a biblioteca para versões que desligam o recurso por padrão. Quem aplicou a primeira mitigação e deu o assunto por encerrado continuou exposto.

Ivanti Connect Secure (CVE-2023-46805 e CVE-2024-21887), janeiro de 2024. Com exploração ativa e sem patch disponível, a Ivanti publicou um arquivo XML de mitigação e a CISA emitiu a Emergency Directive 24-01, exigindo que agências federais aplicassem a mitigação. Depois, a Ivanti atualizou o aviso para alertar sobre uma condição de corrida ao enviar configurações aos equipamentos, que podia anular o efeito do XML e deixar o cliente vulnerável. O mesmo aviso orientava a remover a mitigação após a atualização.

As lições são as mesmas nos dois casos: mitigação precisa ser verificada depois de aplicada, acompanhada enquanto o fabricante revisa a orientação e substituída pela correção definitiva assim que possível.

Leia também: Gestão de patches: guia completo de processo, política e SLA

CISA KEV e a fila de resposta a zero-day

O catálogo Known Exploited Vulnerabilities (KEV) da CISA lista falhas com exploração confirmada. Para cada entrada, a CISA indica uma ação obrigatória para as agências federais americanas. Na maioria dos casos é aplicar a atualização do fabricante; quando não há patch, o texto passa a ser aplicar mitigações conforme as instruções do fabricante ou descontinuar o uso do produto se as mitigações não estiverem disponíveis.

Essa formulação é um bom modelo para qualquer empresa: sem patch, a obrigação não desaparece, muda de forma. Em junho de 2026, a BOD 26-04 substituiu a BOD 22-01 e passou a cobrar das agências correção em 3 dias para as combinações mais graves, como falha no KEV que dá controle total do sistema, e em 14 dias para a maior parte das demais do catálogo.

Na prática, isso pede uma fila de resposta emergencial separada da manutenção de rotina. Uma CVE explorada, com ou sem patch, não pode esperar a janela mensal, e a resposta a ela não pode cancelar o ciclo regular dos outros ativos. Como organizar essa fila sem depender de decisão manual a cada caso está em patch autônomo.

Como evitar que o provisório vire permanente

O maior risco de uma mitigação não é ela falhar no primeiro dia. É ela ser esquecida. Workarounds acumulados por anos viram dívida de segurança invisível: o relatório mostra o item como tratado, ninguém lembra por que aquele serviço está desligado e a correção definitiva nunca entra.

Use este checklist para cada medida provisória:

• A medida está registrada no item da vulnerabilidade, não em um e-mail ou chamado solto.
• Existe um dono nomeado e uma data limite para a correção definitiva.
• O risco residual foi aceito formalmente por quem tem autoridade para isso.
• A eficácia foi validada depois da aplicação e é revalidada a cada varredura.
• O aviso do fabricante é acompanhado para saber quando o patch sai e se a orientação mudou.
• O item só fecha quando a correção definitiva é aplicada e confirmada por re-scan.

Esse registro também atende à auditoria. A ISO/IEC 27002:2022, que detalha o controle 8.8 da ISO 27001, orienta que, sem atualização disponível, a organização considere outros controles, como desligar serviços ligados à vulnerabilidade, ajustar controles de acesso e reforçar o monitoramento. O PCI DSS 4.0 aceita controles compensatórios documentados. No setor financeiro brasileiro, a Resolução CMN 4.893 exige política de segurança cibernética com controles que incluem varreduras para detecção de vulnerabilidades, e o que foi feito com cada achado precisa estar demonstrável.

Vulnerabilidade sem patch no EcoTrust AutoPatch

O AutoPatch foi desenhado para o caso em que a ferramenta de catálogo não tem resposta. Quando o achado chega do VulScan, o agente analisa a vulnerabilidade no contexto do ativo e constrói a correção cabível, que nem sempre é um pacote:

• Configuração: constrói e aplica a mudança de estado (serviço restrito, cifra fraca removida, parâmetro inseguro corrigido).
• Mitigação: quando não há patch de fabricante, aplica a contramedida disponível, como desabilitar o componente vulnerável, restringir a superfície de acesso ou aplicar a contramedida indicada no aviso de segurança.
• Workaround: quando o ativo não pode ser atualizado agora, reduz a exposição e mantém o item rastreado até a atualização definitiva.
• Fila Zero-Day: CVEs no CISA KEV, inclusive sem patch, vão para a fila emergencial, que roda em paralelo às filas Regular e Prioritária.
• Validação e registro: staging em grupo piloto com rollback automático, re-scan nos ativos tratados e registro por CVE de quando a ação foi aplicada e quando foi confirmada, que alimenta o Flow e as evidências para ISO 27001, PCI DSS e BACEN.

A aplicação é feita sem agente nos endpoints, por protocolos nativos (WMI e WinRM no Windows, SSH no Linux e no macOS), com acesso à rede pelo EcoTrust Connect. O detalhamento técnico está no white paper do AutoPatch, e a visão completa do ciclo em remediação automática de vulnerabilidades.

Perguntas Frequentes

O que é uma vulnerabilidade sem patch?

É uma falha conhecida para a qual o fabricante ainda não publicou correção, não vai publicar (produto fora de suporte) ou cuja correção não pode ser aplicada agora por dependência ou janela. Zero-days são o caso mais urgente, porque já são explorados antes da correção existir.

O que é patch virtual?

É uma regra em um equipamento de rede, como IPS ou WAF, que bloqueia o tráfego de exploração de uma vulnerabilidade antes de ele chegar ao ativo. Protege enquanto o patch não entra, mas não corrige a falha: o ativo continua vulnerável a vetores que a regra não cobre.

Qual a diferença entre mitigação e correção?

Correção elimina a vulnerabilidade, por patch ou mudança de configuração definitiva. Mitigação reduz ou bloqueia a exploração sem eliminar a falha, por isso é provisória e o item deve continuar aberto até a correção definitiva.

Quanto tempo posso manter um workaround?

O tempo que a política de risco permitir, com prazo explícito. Defina uma data limite para a correção definitiva, um dono e uma aceitação formal do risco residual. Sem prazo, o workaround tende a virar permanente e sai do radar.

Vulnerabilidade sem patch conta como não conformidade na auditoria?

Não necessariamente. ISO 27001, PCI DSS e as normas do BACEN aceitam controles alternativos quando a correção não está disponível, desde que estejam documentados, validados e com risco residual aceito. O problema na auditoria é a falha sem nenhuma ação registrada.

Conclusão: sem patch, a obrigação muda de forma

Vulnerabilidade sem patch não é um item para a fila de espera. É um item que pede outra resposta: mitigação, workaround, patch virtual ou controle compensatório, escolhidos pela situação, validados depois de aplicados e acompanhados até a correção definitiva.

Com exploração cada vez mais próxima do dia da divulgação, quem espera o fabricante fica exposto justamente na janela de maior risco. Trate a ausência de patch como um caminho de remediação, registre cada medida provisória com dono e prazo e feche o item só quando a nova varredura confirmar que a vulnerabilidade deixou de existir.

---

Referências

• CISA, "Known Exploited Vulnerabilities Catalog", CISA. cisa.gov
• CISA, "ED 24-01: Mitigate Ivanti Connect Secure and Ivanti Policy Secure Vulnerabilities", CISA, 2024. cisa.gov
• CISA, "BOD 26-04: Prioritizing Security Updates Based on Risk", CISA, 2026. cisa.gov
• Mandiant, "How Low Can You Go? An Analysis of 2023 Time-to-Exploit Trends", Google Cloud, 2024. cloud.google.com
• VulnCheck, "State of Exploitation 1H 2025", VulnCheck, 2025. vulncheck.com
• Bitsight TRACE, "Bitsight Reveals More Than 60 Percent of Known Exploited Vulnerabilities Remain Unmitigated", Bitsight, 2024. bitsight.com
• Bitsight, "Patch vs. Workaround: How CVEs Actually Get Fixed", Bitsight, 2025. bitsight.com
• Fortinet, "O que é virtual patching", Fortinet Cyberglossary. fortinet.com
• Apache Software Foundation, "Apache Log4j Security Vulnerabilities", Apache Logging Services. logging.apache.org
• ISO/IEC 27002:2022, controle 8.8: gestão de vulnerabilidades técnicas. iso.org
• PCI Security Standards Council, "PCI DSS v4.0", 2022. pcisecuritystandards.org
• Conselho Monetário Nacional, "Resolução CMN nº 4.893/2021", Banco Central do Brasil, 2021. bcb.gov.br