A remediação de Vulnerabilidades e Exposições Comuns (CVE) é o processo de correção ou redução do risco de falhas de segurança em software. Antigamente, encontrar as falhas era a parte mais difícil, mas as coisas mudaram. A IA tornou a descoberta de vulnerabilidades barata, agora que cada modelo de última geração as consegue detetar mais rapidamente do que os humanos conseguem validá-las. A NVD, a base de dados de vulnerabilidades do governo dos EUA, deixou discretamente de pontuar a maioria das CVEs, classificando tudo o que foi submetido antes de março de 2026 como "Não Agendado" (Not Scheduled), pelo que os dados de severidade em que as equipas confiam para fazer a triagem muitas vezes já lá não estão. O obstáculo atual é a remediação.
Mas a remediação de código aberto significa habitualmente uma de três opções imperfeitas:
- Atualizar e arriscar-se a quebrar a sua aplicação
- Migrar para uma stack de substituição blindada
- Ou manter a versão vulnerável fixada e aguardar por um patch que poderá nunca chegar
Nenhuma destas opções constitui uma correção limpa, razão pela qual a decisão sobre como remediar depende de saber exatamente quais as versões de pacotes em execução em produção e o porquê. Esta publicação aborda a forma como a IA acelerou a deteção e descoberta de CVEs, a armadilha da atualização, o que a remediação de CVEs envolve atualmente em 2026 e como resolver o problema da remediação de CVEs.
TL;DR
A IA deteta CVEs mais depressa do que as equipas conseguem validá-los, e a NVD deixou de pontuar a maioria das descobertas. A remediação é o gargalo. Atualizar a dependência é o conselho habitual, mas uma nova versão pode quebrar a compilação e migrar para uma stack de substituição apenas troca um problema por outro. Existe outra opção: aplicar o backport da correção à versão que já está a executar, sem necessidade de atualizar ou migrar.
Como a IA acelerou a descoberta e divulgação de CVEs
O custo de encontrar uma vulnerabilidade caiu a pique. Prevê-se que as divulgações anuais de CVE ultrapassem as 60.000 em 2026, e a IA está a impulsionar isto em ambas as frentes. Escreve mais código e lê esse código em busca de falhas mais depressa do que qualquer equipa humana.
Todos os modelos de ponta conseguem agora encontrar vulnerabilidades mais depressa do que os revisores conseguem validá-las. O Claude Mythos Preview detetou milhares de erros de alta gravidade, incluindo uma falha com 27 anos no OpenBSD que sobreviveu a décadas de revisão e a milhões de testes automatizados. E não se fica por encontrar bugs individuais. Os modelos conseguem encadear CVEs de menor gravidade num caminho de exploração que se torna crítico em conjunto, mesmo que nenhuma ligação individual pareça urgente.
O pipeline de divulgação não consegue acompanhar o ritmo. As vulnerabilidades são agora submetidas mais depressa do que qualquer pessoa consegue enriquecê-las, e o backlog é prova disso. A maioria dos novos CVEs chegará à NVD como registos simples, sem as pontuações de gravidade e os dados de referência de que as ferramentas de vulnerabilidade dependem para priorizar e remediar.
A armadilha da atualização
As aplicações web funcionam maioritariamente com open source, e a sabedoria convencional sempre ditou que se devem manter as dependências atualizadas. Quando uma ferramenta sinaliza um CVE, a correção sugerida é quase sempre atualizar para a versão com patch e fechar o ticket.
E os maintainers quase sempre lançam a correção apenas na versão mais recente. Raramente voltam atrás para aplicar patches em versões anteriores. Assim, se estiver numa versão mais antiga — quer a tenha fixado deliberadamente quer um pacote ascendente a tenha bloqueado —, a correção upstream não chega até si. "Atualizar" torna-se a sua única alternativa e falha em três casos comuns.
- Não existe nenhuma versão fixa para a qual transitar e nunca existirá, porque o pacote foi descontinuado ou abandonado.
- O patch simplesmente ainda não foi lançado e todas as versões publicadas continuam vulneráveis.
- A correção é lançada, mas chega acompanhada de alterações que quebram a compatibilidade e derrubam a sua aplicação.
Mesmo quando existe uma atualização, esta normalmente tem um custo. Atualizações de versões menores (minor) podem alterar o comportamento de um pacote e obrigá-lo a testar tudo novamente. Versões principais (major) implicam um verdadeiro trabalho de migração. Além disso, o pacote vulnerável está frequentemente profundamente enterrado na árvore de dependências, retido por uma restrição de versão de um pacote ascendente e não por escolha própria, impedindo qualquer atualização sem atualizar tudo o que está acima.
O pacote CVE-2026-48937 do Node é um exemplo do terceiro caso. A correção foi lançada em conjunto com uma dependência SEMVER-MAJOR atualização para a nghttp2 que removeu totalmente a sinalização de prioridade HTTP/2. O comportamento vulnerável e a funcionalidade removida vinham do mesmo código subjacente, pelo que não havia forma de aplicar a correção de segurança sem aceitar a alteração disruptiva. Qualquer pessoa dependente desse comportamento teve de pesquisar por setPriority e .priority() e removê-los antes de a atualização poder avançar.
As equipas foram condicionadas a atualizar assim que possível, e os atacantes repararam nisso. Se todos recorrem reflexivamente à versão mais recente, essa mesma versão passa a ser o local ideal para plantar malware. O comprometimento do chalk e do debug introduziu versões maliciosas através do canal oficial do npm, e todos os pipelines configurados para atualização automática puxaram-nas diretamente para produção. Permanecer atualizado acarreta agora o seu próprio risco, razão pela qual as equipas começaram a introduzir um período de arrefecimento antes de adotarem qualquer nova versão de um pacote.
Fica assim com um mau compromisso. Se atualiza, arrisca-se a ter builds corrompidas ou um pacote comprometido. Se congela as versões, fica agarrado a uma vulnerabilidade conhecida enquanto a dívida técnica de segurança se acumula.
Leia uma análise detalhada sobre a armadilha da atualização, com exemplos dos três tipos de falha de atualização.
O que a remediação de CVEs em 2026 envolve
Antes de qualquer CVE surgir, é importante saber exatamente o que está a executar e porquê. A maioria das equipas sabe indicar a respetiva contagem de CVEs abertos, mas se perguntar porque é que um determinado pacote ou imagem está na versão em que se encontra, dificilmente obterá uma boa resposta. Muitos mantêm a crença comum de que uma versão mais antiga é mais arriscada do que uma mais recente, pelo que optam por atualizar automaticamente. O instinto oposto — fixar uma versão testada e em que confia, mantendo-a deliberadamente — também é uma escolha legítima, desde que seja uma decisão fundamentada e não um mero acaso.
Acertar na remediação depende de conhecer antecipadamente a sua árvore de dependências, e isso só se consegue monitorizando-a continuamente. Considere a SBOM como uma linha base dinâmica que cruza com novas divulgações à medida que vão surgindo.
Com isso implementado, pode decidir qual a correção adequada com base no facto de o caminho de código vulnerável ser acessível e, em caso afirmativo, se é explorável no seu ambiente. Corrigir uma CVE através de uma atualização significa aceitar tudo o resto incluído nessa versão, incluindo dependências transitivas e predefinições alteradas, por isso certifique-se de que sabe como esse novo código afetará o seu sistema.
Quando existe uma atualização limpa e decidiu que o raio de ação é aceitável após ponderar alterações que quebram a compatibilidade e conflitos transitivos, avance com ela. Quando não existe, terá de escolher entre três abordagens. Pode:
- Fazer uma triagem na instalação para detetar pacotes problemáticos antes de chegarem à compilação, embora isto não tenha efeito sobre o que já está em produção.
- Mudar para um ecossistema de substituição reforçado, o que transforma a remediação numa migração para um ecossistema que não controla.
- Fazer o backport da correção para a versão já em utilização, a única opção que fecha a CVE sem introduzir uma nova versão ou exigir uma migração.
Como o Aikido Libraries resolve a armadilha das atualizações
O Aikido Libraries permite-lhe escapar à armadilha das atualizações ao aplicar o backport de correções de CVE para a versão exata do pacote fixada no seu lockfile. Quando uma CVE é corrigida a montante, o Libraries produz uma variante segura da versão exata que já está a executar e envia-a como um PR AutoFix diário. Obtém o patch sem alterações que quebram a compatibilidade ou necessidade de migração.
{{cta}}
Internamente, é alimentado pelo sistema tipo fábrica da Root's, onde os agentes gerem patches de CVE precisos para as versões de pacotes que as equipas realmente utilizam, testando-os e validando-os de seguida face à versão em uso. Funciona em npm, PyPI, Maven e muito mais, pelo que a mesma abordagem se aplica independentemente dos ecossistemas utilizados pela sua stack.
A Aikido Security também faz backports de correções para CVEs de open source ativamente exploradas, aquelas que constam na lista de Known Exploited Vulnerabilities da CISA, e disponibiliza-as gratuitamente à comunidade.
As Libraries executam-se na plataforma da Aikido Security juntamente com o SCA, que analisa as suas dependências em busca de CVEs, malware, problemas de licença e de fim de vida (end-of-life), priorizando depois o que é efetivamente acessível. O SCA é alimentado pelo Aikido Intel, um feed em tempo real que monitoriza tanto malware como vulnerabilidades em ecossistemas open source.
FAQ
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "https://www.aikido.dev/#organization",
"name": "Aikido Security",
"url": "https://www.aikido.dev",
"logo": {
"@type": "ImageObject",
"@id": "https://www.aikido.dev/#logo",
"url": "https://www.aikido.dev/logo.png",
"contentUrl": "https://www.aikido.dev/logo.png",
"caption": "Aikido Security"
},
"sameAs": [
"https://www.linkedin.com/company/aikido-security",
"https://x.com/AikidoSecurity"
]
},
{
"@type": "WebSite",
"@id": "https://www.aikido.dev/#website",
"url": "https://www.aikido.dev",
"name": "Aikido Security",
"publisher": { "@id": "https://www.aikido.dev/#organization" },
"inLanguage": "en-US"
},
{
"@type": "Person",
"@id": "https://www.aikido.dev/authors/nicholas-thomson#person",
"name": "Nicholas Thomson",
"url": "https://www.aikido.dev/authors/nicholas-thomson",
"jobTitle": "Senior SEO & Growth Lead",
"worksFor": { "@id": "https://www.aikido.dev/#organization" },
"sameAs": [
"https://www.linkedin.com/in/nicholas-gray-thomson/"
]
},
{
"@type": "ImageObject",
"@id": "https://www.aikido.dev/blog/cve-remediation#primaryimage",
"url": "https://www.aikido.dev/blog/cve-remediation/og-image.png",
"contentUrl": "https://www.aikido.dev/blog/cve-remediation/og-image.png",
"caption": "What is CVE remediation in 2026?"
},
{
"@type": "BreadcrumbList",
"@id": "https://www.aikido.dev/blog/cve-remediation#breadcrumb",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "Home",
"item": "https://www.aikido.dev"
},
{
"@type": "ListItem",
"position": 2,
"name": "Blog",
"item": "https://www.aikido.dev/blog"
},
{
"@type": "ListItem",
"position": 3,
"name": "What is CVE remediation in 2026?",
"item": "https://www.aikido.dev/blog/cve-remediation"
}
]
},
{
"@type": "WebPage",
"@id": "https://www.aikido.dev/blog/cve-remediation#webpage",
"url": "https://www.aikido.dev/blog/cve-remediation",
"name": "What is CVE remediation in 2026?",
"description": "Finding CVEs got cheap; fixing them didn't. How open source CVE remediation actually works in 2026, and how backporting closes the gap without an upgrade.",
"isPartOf": { "@id": "https://www.aikido.dev/#website" },
"primaryImageOfPage": { "@id": "https://www.aikido.dev/blog/cve-remediation#primaryimage" },
"breadcrumb": { "@id": "https://www.aikido.dev/blog/cve-remediation#breadcrumb" },
"inLanguage": "en-US",
"datePublished": "2026-08-21T09:00:00+00:00",
"dateModified": "2026-08-21T09:00:00+00:00",
"speakable": {
"@type": "SpeakableSpecification",
"cssSelector": ["h1", ".tldr"]
}
},
{
"@type": ["TechArticle", "BlogPosting"],
"@id": "https://www.aikido.dev/blog/cve-remediation#article",
"isPartOf": { "@id": "https://www.aikido.dev/blog/cve-remediation#webpage" },
"mainEntityOfPage": { "@id": "https://www.aikido.dev/blog/cve-remediation#webpage" },
"headline": "What is CVE remediation in 2026?",
"description": "CVE remediation is the process of fixing or reducing the risk of security flaws in software. Why upgrading often fails, what remediation actually involves in 2026, and how backporting fixes the version you already run.",
"abstract": "AI surfaces CVEs faster than teams can validate them and the NVD has stopped scoring most of what is found, making remediation the bottleneck. Backporting applies the fix to the version you already run, without an upgrade or migration.",
"articleSection": "Open Source Security",
"url": "https://www.aikido.dev/blog/cve-remediation",
"author": { "@id": "https://www.aikido.dev/authors/nicholas-thomson#person" },
"publisher": { "@id": "https://www.aikido.dev/#organization" },
"image": { "@id": "https://www.aikido.dev/blog/cve-remediation#primaryimage" },
"datePublished": "2026-08-21T09:00:00+00:00",
"dateModified": "2026-08-21T09:00:00+00:00",
"inLanguage": "en-US",
"wordCount": 1400,
"timeRequired": "PT6M",
"proficiencyLevel": "Intermediate",
"dependencies": "Familiarity with open source dependencies, package managers, and CVEs",
"keywords": [
"CVE remediation",
"backporting",
"open source security",
"vulnerability management",
"software composition analysis",
"supply chain security",
"dependency management",
"transitive dependencies",
"upgrade trap",
"NVD"
],
"about": [
{
"@type": "DefinedTerm",
"name": "CVE remediation",
"description": "The process of fixing or reducing the risk of known security flaws in the software you run, by confirming exposure and applying a fix such as an upgrade, a mitigation, or a backported patch."
},
{
"@type": "DefinedTerm",
"name": "Backporting",
"description": "Taking the specific fix for a vulnerability and applying it to the older version already in use, instead of upgrading to the release that contains the upstream fix."
},
{
"@type": "Thing",
"name": "Vulnerability management"
}
],
"mentions": [
{
"@type": "SoftwareApplication",
"name": "Aikido Libraries",
"url": "https://www.aikido.dev/code/aikido-libraries",
"applicationCategory": "SecurityApplication"
},
{
"@type": "Thing",
"name": "CVE-2026-48937"
},
{
"@type": "Thing",
"name": "OpenBSD"
},
{
"@type": "Thing",
"name": "Node.js"
},
{
"@type": "Thing",
"name": "npm"
},
{
"@type": "Thing",
"name": "PyPI"
},
{
"@type": "Thing",
"name": "Maven"
},
{
"@type": "Thing",
"name": "National Vulnerability Database"
},
{
"@type": "Thing",
"name": "CISA Known Exploited Vulnerabilities Catalog"
},
{
"@type": "Thing",
"name": "Software Bill of Materials"
},
{
"@type": "Thing",
"name": "Claude Mythos Preview"
}
]
},
{
"@type": "FAQPage",
"@id": "https://www.aikido.dev/blog/cve-remediation#faq",
"isPartOf": { "@id": "https://www.aikido.dev/blog/cve-remediation#webpage" },
"mainEntity": [
{
"@type": "Question",
"name": "What is CVE remediation?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Fixing or reducing the risk of a known security flaw in software you run. In practice that means deciding whether the vulnerability is reachable and exploitable in your environment, and applying a fix."
}
},
{
"@type": "Question",
"name": "Is patching the same as upgrading?",
"acceptedAnswer": {
"@type": "Answer",
"text": "No, and conflating them is the core of the upgrade trap. Upgrading moves you to a newer release and everything else that shipped in it. Patching means applying only the fix for the specific vulnerability. Backporting lets you patch without upgrading."
}
},
{
"@type": "Question",
"name": "How do I fix a CVE in a transitive dependency?",
"acceptedAnswer": {
"@type": "Answer",
"text": "The vulnerable package is often pulled in by another package you don't directly control, so you can't bump it without bumping its parent. Options are pressuring the parent to update, overriding the resolved version if your package manager allows it and it's compatible, or backporting the fix to the version already resolved in your tree."
}
},
{
"@type": "Question",
"name": "Is it safe to auto-update dependencies?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Not on its own. Auto-update keeps you current but pulls new releases straight into production, which is exactly how the chalk and debug malware reached teams within minutes. Many teams now add a cooldown before adopting new versions and screen packages at install."
}
},
{
"@type": "Question",
"name": "What is backporting?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Taking the specific fix for a vulnerability and applying it to the older version you're already running, instead of jumping to the release that contains the fix upstream. It closes the CVE without breaking changes or a migration. Linux distributions have done this for OS packages for years."
}
},
{
"@type": "Question",
"name": "What happens to CVEs the NVD no longer enriches?",
"acceptedAnswer": {
"@type": "Answer",
"text": "They still get a CVE ID, but without the severity scores and reference data that many tools depend on to prioritize them. Tools that rely solely on NVD enrichment may not surface them at all, so teams increasingly pull from multiple vulnerability sources rather than treating the NVD as complete."
}
}
]
}
]
}
</script>
