O que é a correção de vulnerabilidades CVE em 2026?

A correção de Vulnerabilidades e Exposições Comuns (CVE) é o processo de corrigir ou reduzir o risco de falhas de segurança no software. Antigamente, a parte difícil era identificar as falhas, mas as coisas mudaram. A IA tornou a deteção de vulnerabilidades mais económica, agora que qualquer modelo de ponta consegue identificá-las mais rapidamente do que os seres humanos conseguem validá-las. O NVD, a base de dados de vulnerabilidades do governo dos EUA, deixou discretamente de atribuir pontuações à maioria das CVEs, arquivando tudo o que foi registado antes de março de 2026 como «Não Agendado», pelo que os dados de gravidade em que as equipas se baseiam para a triagem muitas vezes já não estão disponíveis. O gargalo é agora a correção.

No entanto, a correção de problemas no código aberto implica, normalmente, uma de três opções imperfeitas: 

• Atualizar e correr o risco de danificar a sua aplicação
• Migrar para uma pilha de substituição reforçada
• Ou ficar preso a uma versão vulnerável e esperar por uma correção que talvez nunca chegue 

Nenhuma destas soluções é perfeita, razão pela qual a decisão sobre como resolver o problema depende de saber quais as versões dos pacotes que estão a ser executadas em produção e porquê. Este artigo irá abordar a forma como a IA acelerou a deteção e a identificação de CVE, a «armadilha da atualização», o que a correção de CVE implica efetivamente em 2026 e como resolver o problema da correção de CVE.

TL;DR

A IA identifica vulnerabilidades (CVEs) mais rapidamente do que as equipas conseguem validá-las, e o NVD deixou de atribuir pontuação à maioria das vulnerabilidades detetadas. A correção é o ponto de estrangulamento. A recomendação habitual é atualizar a dependência, mas uma nova versão pode comprometer a compilação, e a migração para uma pilha alternativa apenas troca um problema por outro. Existe outra opção, que consiste em aplicar a correção à versão que já está a utilizar, sem ter de atualizar nem migrar.

Como a IA acelerou a descoberta e a divulgação de CVE

O custo de detetar uma vulnerabilidade desceu drasticamente. Prevê-se que as divulgações anuais de CVE ultrapassem as 60 000 em 2026, e a IA está a impulsionar este processo em ambos os sentidos. Ela escreve mais código e analisa esse código à procura de falhas mais rapidamente do que qualquer equipa humana.

Atualmente, todos os modelos de detecção precoce conseguem identificar vulnerabilidades mais rapidamente do que os revisores conseguem validá-las. O Claude Mythos Preview revelou milhares de falhas de elevada gravidade, incluindo uma falha no OpenBSD com 27 anos que resistiu a décadas de revisão e a milhões de testes automatizados. E não se limita a encontrar falhas isoladas. Os modelos conseguem encadear CVEs de menor gravidade numa cadeia de exploração que, em conjunto, se torna crítica, mesmo quando nenhum elo individual parece urgente.

O processo de divulgação não consegue acompanhar o ritmo. Atualmente, as vulnerabilidades são submetidas mais rapidamente do que é possível enriquecê-las, e o atraso acumulado reflete isso. A maioria dos novos CVEs chega ao NVD como entradas simples, sem as pontuações de gravidade e os dados de referência de que as ferramentas de vulnerabilidades dependem para estabelecer prioridades e aplicar correções. 

A armadilha da atualização

As aplicações web funcionam principalmente em software de código aberto, e a prática habitual sempre foi manter as dependências atualizadas. Quando uma ferramenta deteta um CVE, a solução que propõe é, quase sempre, atualizar para a versão corrigida e encerrar o ticket.

E os responsáveis pela manutenção quase sempre incluem a correção apenas na versão mais recente. Raramente voltam atrás para corrigir versões mais antigas. Por isso, se estiver a utilizar uma versão mais antiga — quer a tenha fixado deliberadamente, quer um pacote pai o tenha limitado a essa versão —, a correção do upstream não chega até si. A «atualização» torna-se a única opção de que dispõe, e falha em três casos comuns. 

• Não existe uma versão específica para a qual se possa migrar e nunca haverá, porque o pacote está obsoleto ou foi abandonado. 
• A correção simplesmente ainda não foi lançada e todas as versões publicadas continuam vulneráveis. 
• A correção é, de facto, lançada, mas vem acompanhada de alterações que provocam incompatibilidades e que levam à falha da sua aplicação. 

Mesmo quando existe uma atualização, esta tem normalmente um custo. As atualizações de versão secundárias podem alterar o comportamento de um pacote e obrigar-te a repetir os testes. As versões principais implicam um verdadeiro trabalho de migração. E o pacote vulnerável está frequentemente enterrado no fundo da tua árvore de dependências, retido ali por uma restrição de versão de um pacote pai, e não por uma escolha tua, pelo que não podes atualizá-lo sem atualizar tudo o que se encontra acima dele.

Node's CVE-2026-48937 é um exemplo do terceiro caso. A correção foi fornecida juntamente com um SEMVER-MAJOR atualização para a nghttp2 dependência que eliminou por completo a sinalização de prioridade do HTTP/2. O comportamento vulnerável e a funcionalidade removida provinham do mesmo código subjacente, pelo que não havia forma de aplicar a correção de segurança sem, ao mesmo tempo, introduzir a alteração que causava incompatibilidade. Qualquer pessoa que dependesse desse comportamento teve de procurar com o grep por setPriority e .priority() e removê-las antes mesmo de a atualização ser efetuada.

As equipas habituaram-se a atualizar assim que podiam, e os atacantes perceberam isso. Se todos descarregam reflexivamente a versão mais recente, então é precisamente aí que se instala o malware. A falha de segurança relacionada com o «chalk» e a depuração permitiu que versões maliciosas fossem distribuídas através do canal oficial do npm, e todos os pipelines configurados para atualização automática descarregaram-nas diretamente para o ambiente de produção. Manter-se atualizado acarreta agora um risco próprio, razão pela qual as equipas começaram a incorporar um período de espera antes de adotarem qualquer nova versão de pacote.

Assim, ficas numa situação complicada. Se fizeres a atualização, arriscas-te a ter compilações com erros ou um pacote comprometido. Se mantiveres a versão atual, ficas com uma vulnerabilidade conhecida enquanto a dívida de segurança vai aumentando. 

Leia uma análise detalhada sobre a «armadilha da atualização», com exemplos dos três tipos de falhas na atualização.

O que implica a correção de vulnerabilidades CVE em 2026 

Antes de qualquer CVE ser divulgado, é importante que saiba o que está a executar e porquê. A maioria das equipas consegue indicar o número de CVE pendentes, mas se perguntar por que razão um determinado pacote ou imagem está nessa versão específica, terá dificuldade em obter uma resposta satisfatória. Muitos seguem a ideia 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 que já testou e na qual confia, e mantê-la deliberadamente — também é uma escolha legítima, desde que seja uma decisão consciente e não um acaso.

Para aplicar as medidas corretivas de forma adequada, é necessário conhecer previamente a sua árvore de dependências, e isso só é possível através de uma monitorização contínua. Considere o relatório « SBOM » como uma referência dinâmica, que deve comparar com novas divulgações à medida que estas vão surgindo.

Com isso em conta, pode decidir qual a correção adequada, consoante o percurso de código vulnerável seja acessível e, em caso afirmativo, se é explorável no seu ambiente. Corrigir um CVE através de uma atualização implica aceitar tudo o resto dessa versão, incluindo dependências transitivas e alterações nos valores predefinidos; por isso, certifique-se de que sabe como esse novo código irá afetar o seu sistema.

Caso exista uma atualização «limpa» e tenha decidido que o impacto é aceitável, após ponderar as alterações que implicam incompatibilidades e os conflitos transitivos, opte por essa via. Caso contrário, terá de escolher entre três abordagens. Pode:

• Faça uma verificação durante a instalação para detetar pacotes com erros antes de estes chegarem à sua compilação, embora isso não tenha qualquer efeito sobre o que já se encontra em produção. 
• Mude para uma pilha de substituição reforçada, o que transforma a correção num processo de migração para um ecossistema que não controla. 
• Aplicar a correção à versão já em uso, a única opção que permite resolver a vulnerabilidade CVE sem ter de lançar uma nova versão nem realizar uma migração.

Como o « Aikido Libraries» resolve o problema da atualização

Aikido O Libraries permite-lhe « escape » a armadilha da atualização, através da retroaplicação de correções de CVE à versão exata do pacote fixada no seu ficheiro de bloqueio. Quando uma vulnerabilidade CVE é corrigida no código-fonte original, o Libraries produz uma variante segura da versão exata que já está a utilizar e disponibiliza-a como um PR diário do AutoFix. Recebe o patch sem as alterações que causam incompatibilidade, nem a migração.

{{cta}}

Nos bastidores, é alimentado pelo sistema da Root, semelhante ao de uma fábrica, no qual os agentes geram correções CVE precisas para as versões dos pacotes que as equipas realmente utilizam e, em seguida, testam e validam essas correções em relação à versão em uso. Funciona no npm, no PyPI, no Maven e noutros, pelo que a mesma abordagem se aplica independentemente dos ecossistemas de onde a sua pilha de tecnologias obtém os pacotes.

Aikido A equipa de segurança também adapta correções para CVEs de código aberto que estão a ser ativamente explorados — aqueles que constam da lista de «Vulnerabilidades Exploradas Conhecidas» da CISA — e disponibiliza-as gratuitamente à comunidade.

As bibliotecas funcionam na plataforma da Aikido Security, a par de SCA, que analisa as suas dependências em busca de CVEs, malware, problemas de licença e fim de vida útil, e depois prioriza o que é efetivamente acessível. O SCA é alimentado pelo Aikido Intel, um feed em tempo real que monitoriza tanto o malware como as vulnerabilidades nos ecossistemas de código aberto. 

FAQ