O Next.js publicou nesta terça-feira, 25 de agosto, as versões 16.3.3 e 15.5.24 para corrigir duas vulnerabilidades críticas capazes de permitir execução remota de código sem autenticação. A recomendação oficial é atualizar imediatamente as aplicações nas linhas suportadas.
A divulgação estava planejada para o dia 26, mas foi antecipada depois que uma segunda falha crítica apareceu em uma dependência usada pelo framework. Os dois patches chegaram juntos: o Next.js 16.3.3 atende a linha Active LTS e o 15.5.24 atende a Maintenance LTS.
São duas falhas com condições diferentes
As duas vulnerabilidades terminam no mesmo impacto possível, execução de código no servidor por um atacante sem credenciais, mas os caminhos de exploração não são iguais. Isso importa para entender a exposição imediata de cada projeto, embora não reduza a necessidade de instalar a correção.
Otimização de imagens AVIF
A primeira falha, identificada como GHSA-2xp9-vwfh-vxw4, está na biblioteca libheif usada pelo sharp, que por sua vez participa da otimização de imagens do Next.js. Um arquivo AVIF malicioso processado pela API de Image Optimization pode levar à execução remota de código.
O advisory atribui nota 9,5 de 10 à falha. Ele marca como vulneráveis versões a partir do Next.js 10 anteriores ao 15.5.24 e versões da linha 16 anteriores ao 16.3.3. Como medida temporária, os patches desativam a otimização de AVIF até que a correção da biblioteca subjacente seja incorporada.
Esse detalhe pode produzir uma mudança visível no pipeline de imagens. Aplicações que dependem de AVIF devem verificar formato entregue, tamanho dos arquivos e métricas de carregamento depois do deploy. Ainda assim, manter a otimização ativa em uma versão vulnerável não é uma troca razoável por alguns bytes a menos.
Execução remota em servidores Windows
A segunda falha é a CVE-2026-75604, também registrada como GHSA-p293-qw3h-jr36. Ela afeta aplicações hospedadas em máquinas com filesystem do Windows, tanto com Pages Router quanto com App Router sem Cache Components.
As faixas afetadas são Next.js 13.4 ou superior e inferior ao 15.5.24, além da linha 16 antes da 16.3.3. O advisory dá nota 9,0 e informa que não existe solução alternativa conhecida para aplicações afetadas em Windows. Nesse cenário, atualizar não é apenas uma camada extra de proteção: é a correção disponível.
Como saber se o projeto precisa de ação
Comece pela versão realmente instalada, não apenas pela faixa declarada no package.json. O lockfile pode manter uma versão anterior até que a instalação seja atualizada:
npm ls nextQuem está no Next.js 16 deve chegar à versão 16.3.3 ou posterior. Quem permanece na linha 15 suportada deve instalar a 15.5.24 ou posterior. Mesmo que o servidor não seja Windows ou que o projeto não aceite AVIF no otimizador, manter uma versão corrigida evita depender para sempre de condições de infraestrutura que podem mudar no próximo deploy.
Projetos no Next.js 14 ou em versões anteriores exigem atenção adicional. A política atual do projeto lista apenas as linhas 16 e 15 como suportadas. Não há patch anunciado para as linhas antigas neste release; a saída é planejar a migração para uma das versões LTS corrigidas.
Atualizando sem transformar o patch em migração
Para continuar na mesma linha principal, instale explicitamente a versão corrigida correspondente:
# Next.js 16, Active LTS
npm install [email protected]
# Next.js 15, Maintenance LTS
npm install [email protected]Usar a versão explícita evita que um projeto no Next.js 15 faça uma migração de major no meio da correção de segurança. Depois da instalação, revise a alteração do lockfile, execute o build e os testes habituais e faça um smoke test das rotas mais importantes.
npm ls next
npm run buildRode também o script de testes do projeto, quando houver. O último passo é redeployar e substituir os processos ou contêineres que ainda carregam a versão anterior. Atualizar apenas o repositório não protege uma instância que continua rodando o bundle antigo. Em aplicações que usam AVIF, inclua a entrega de imagens no smoke test para identificar o efeito da desativação temporária da otimização.
Prioridade alta, sem tratar todo deployment como igual
Os advisories descrevem condições concretas: processamento de AVIF pela API de imagens em um caso e hospedagem Windows no outro. Essa distinção ajuda a organizar a resposta, mas não deveria virar motivo para adiar o patch em aplicações que usam versões afetadas.
Para equipes com vários projetos, a ordem prática é localizar as versões instaladas, priorizar serviços expostos à internet e deployments Windows, instalar 16.3.3 ou 15.5.24, validar imagens e rotas e confirmar o redeploy. É uma atualização pequena no número da versão, mas com impacto de segurança grande demais para ficar esperando a próxima janela de manutenção.