Next.js: atualizar a versão declarada não garante dependências corrigidas

Uma atualização extraordinária do Next.js, publicada em 14 de outubro, corrige duas falhas críticas de execução remota de código sem autenticação e uma de negação de serviço; as versões recomendadas são 16.4.1 e 15.5.28.[3] A exposição não é uniforme: depende dos recursos e caminhos de execução usados pela aplicação.[3] O trabalho de engenharia começa ao trocar uma pergunta genérica sobre versão por uma matriz de condições vulneráveis.

O que muda para quem desenvolve

A primeira falha envolve React Server Components em aplicações Next.js 16 com App Router e Cache Components habilitados, quando uma função use cache retorna mais de um array tipado.[3] O aviso do React descreve uma combinação extremamente rara com valor controlado pelo atacante, mas recomenda atualizar mesmo sem identificar esse padrão no código.[3]

A segunda, CVE-2026-96889, está em librsvg, alcançada por sharp em Linux com glibc, quando SVGs controlados por terceiros chegam ao processamento vulnerável.[3] A otimização de SVG não é habilitada por padrão no Next.js, mas pode ser ativada com dangerouslyAllowSVG; a reportagem também aponta o caminho de geração de imagens com next/og no runtime Node.js.[3]

A negação de serviço, por sua vez, requer App Router com pelo menos uma Server Action.[3] Minha análise é que a prioridade deve considerar tanto a dependência quanto a capacidade de entrada: receber imagens externas e executar ações de servidor são superfícies diferentes.

Como aplicar

Há uma armadilha na linha 15: atualizar para 15.5.28 pode manter sharp 0.34.x, ainda vulnerável, enquanto a correção exige confirmar sharp 0.35.5 ou superior.[3] Na linha 16, Next.js 16.4.1 já exige esse mínimo.[3]

Monte uma revisão reproduzível:

1. Registre versão resolvida de Next.js e sharp no lockfile e no ambiente de build.
2. Identifique App Router, Cache Components, Server Actions e entradas SVG efetivamente habilitados.
3. Atualize as dependências, gere um novo artefato e faça o deploy.
4. Execute regressões de cache, ações e imagens usando dados de teste.
5. Confirme que a instância servindo tráfego corresponde ao artefato corrigido.

Como experimento, compare o inventário de dependências antes e depois da atualização em uma cópia do projeto. O resultado útil é provar a mudança de sharp e o funcionamento dos caminhos usados, não apenas observar que a instalação terminou.

Cuidados e limites

Em 15 de outubro, os avisos de cache e Server Actions ainda não apareciam no feed usado pelo npm audit, e não havia relatos públicos de exploração das três falhas corrigidas.[3] Bloquear o carregamento de SVG ou atualizar sharp é uma mitigação temporária apenas para o problema de imagem, não para os demais.[3]

Um scanner limpo não deve substituir a leitura do aviso e a conferência do artefato. Ao mesmo tempo, presença da biblioteca não prova que todas as condições de exploração estejam ativas. Documente essa distinção sem usá-la como desculpa para manter a versão vulnerável.

Fonte

[3] Fonte: The Hacker News. Publicação: 15/10/2026 às 09:28:13.