O cache de imagens e a pré-renderização parcial apresentam falhas que podem deixar a aplicação indisponível por consumo de disco ou memória. Os outros avisos envolvem requisições encaminhadas por rewrites e a validação de origem no desenvolvimento e nas Server Actions. Confira os recursos usados no seu ambiente para identificar quais fichas se aplicam à sua instalação.
AplicativoNext.js
Data do compilado
Vulnerabilidades5
As faixas afetadas e as versões corrigidas reproduzem os valores da API, inclusive os intervalos sem limite superior. A situação corrigida indica que o projeto disponibilizou a correção, mas você precisa conferir a versão efetivamente instalada. Todas as gravidades seguem a classificação dos avisos, e as pontuações são do CVSS 4.0.
Gravidade moderadaCVSS: 6,9/10Correção disponível
Cache de imagens pode ocupar todo o disco
O otimizador de imagens acessado por /_next/image gravava as variantes em disco sem um limite máximo configurável. Um atacante poderia provocar a criação de muitas variantes diferentes até esgotar o espaço disponível e deixar a aplicação indisponível. A correção acrescenta images.maximumDiskCacheSize e remove do cache as entradas usadas há mais tempo quando o limite é ultrapassado.
Casos de uso afetados
Você hospeda o Next.js com o otimizador padrão e armazena o cache no disco do servidor. Requisições que geram variantes distintas de imagens podem aumentar continuamente a pasta .next/cache/images.
Confira na sua instância
Confira a versão do pacote next no ambiente que executa a aplicação e confirme se /_next/image usa o otimizador padrão. Meça o tamanho de .next/cache/images e o espaço livre no volume correspondente. Depois da atualização, configure images.maximumDiskCacheSize e, em homologação, gere variantes permitidas para observar a remoção de entradas antigas ao atingir o limite. O valor 0 desativa o cache em disco. Até atualizar, limpe periodicamente essa pasta e restrinja as imagens aceitas por images.localPatterns e images.remotePatterns, além das qualidades definidas em images.qualities.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
next (npm)
>=10.0.0
15.5.14, 16.1.7
CVE-2026-27980. O aviso exclui plataformas que usam otimização própria de imagens, como a Vercel. A limpeza periódica reduz a ocupação acumulada, mas não acrescenta o limite implementado pela correção.
Gravidade moderadaCVSS: 6,9/10Correção disponível
Retomada da pré-renderização pode consumir memória sem limite
O processamento de requisições POST com next-resume: 1 podia acumular o corpo recebido na memória sem aplicar maxPostponedStateSize de maneira consistente. A mitigação anterior cobria o modo mínimo de execução, mas deixava outros ambientes equivalentes expostos. Com a pré-renderização parcial habilitada no App Router, um atacante poderia enviar corpos excessivos e provocar indisponibilidade por consumo de memória. A correção aplica os limites em todos os caminhos de leitura desse corpo.
Casos de uso afetados
Você usa o App Router com a pré-renderização parcial habilitada por experimental.ppr ou cacheComponents e executa a aplicação fora do modo mínimo. Requisições externas com next-resume podem alcançar o processamento de retomada.
Confira na sua instância
Abra a configuração do Next.js e confira experimental.ppr e cacheComponents, além do modo de execução usado no deploy. Confirme que o pacote next instalado recebeu a correção. Até atualizar, faça o proxy rejeitar requisições externas que contenham o cabeçalho next-resume. Teste essa recusa em homologação com um POST de corpo pequeno e next-resume: 1, acompanhando os logs para confirmar que a requisição não chega ao processamento de retomada. Não use o esgotamento de memória como teste de produção.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
next (npm)
>=16.1.0
16.1.7
CVE-2026-27979. Segundo o comunicado, o cabeçalho next-resume não é válido quando enviado por um cliente não confiável. A mitigação anterior para o modo mínimo não confirma a cobertura dos demais modos.
Gravidade moderadaCVSS: 6,3/10Correção disponível
Rewrites podem encaminhar uma requisição adicional ao backend
Uma requisição DELETE ou OPTIONS com Transfer-Encoding: chunked podia ser interpretada de formas diferentes pelo proxy do Next.js e pelo backend externo. Essa diferença na delimitação permitia inserir uma segunda requisição no tráfego encaminhado pelo rewrite, com acesso potencial a rotas internas ou administrativas fora do destino previsto. A correção preserva transfer-encoding nesse processamento e só acrescenta content-length: 0 quando ambos os cabeçalhos estão ausentes.
Casos de uso afetados
Sua aplicação usa rewrites para encaminhar tráfego a outro servidor. O backend possui rotas internas e presume que o acesso pelo Next.js fica restrito ao caminho configurado no rewrite.
Confira na sua instância
Revise os destinos externos dos rewrites e confirme se o encaminhamento é executado pelo Next.js. Confira a versão do pacote next no servidor e verifique se cada rota sensível do backend exige autenticação e autorização próprias. Como mitigação temporária, configure o proxy de entrada para rejeitar DELETE e OPTIONS com Transfer-Encoding: chunked nos caminhos reescritos. Em homologação, envie requisições desses dois métodos com esse cabeçalho e confira nos logs do proxy e do backend se a recusa ocorre antes do encaminhamento.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
next (npm)
>=9.5.0
16.1.7, 15.5.13
CVE-2026-29057. O aviso exclui aplicações hospedadas em provedores que executam os rewrites na CDN, como a Vercel. As restrições no proxy e a autorização no backend são medidas temporárias e complementares à atualização.
Gravidade moderadaCVSS: 5,3/10Correção disponível
Server Actions aceitam origem null sem a verificação esperada
A validação das Server Actions interpretava Origin: null como ausência de origem e podia dispensar a comparação que deveria verificar uma requisição vinda de outro site. Um atacante poderia induzir o navegador de uma vítima a executar ações que alteram registros usando suas credenciais, por meio de um iframe sandboxed. A correção reconhece null como um valor explícito e exige a validação entre host e origem, salvo quando null foi incluído expressamente em experimental.serverActions.allowedOrigins.
Casos de uso afetados
Sua aplicação usa Server Actions autenticadas para alterar registros. Uma vítima com sessão ativa acessa conteúdo malicioso que tenta enviar essas ações a partir de um iframe sandboxed, aproveitando as credenciais disponíveis no navegador.
Confira na sua instância
Revise experimental.serverActions.allowedOrigins e confira se null foi incluído na lista. Em homologação, use uma sessão de teste e uma Server Action com alteração reversível para verificar que uma requisição com Origin: null não executa a ação quando essa origem não está autorizada. Confira o registro afetado, além da resposta HTTP. Até atualizar, acrescente tokens contra falsificação de requisições entre sites nas ações sensíveis e prefira SameSite=Strict nos cookies de autenticação sensíveis. Mantenha null fora das origens permitidas, salvo necessidade explícita acompanhada de proteção adicional.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
next (npm)
>=16.0.1
16.1.7
CVE-2026-27978. O ataque depende da interação da vítima e da disponibilidade de suas credenciais na requisição. Autorizar null explicitamente mantém essa origem permitida mesmo após a correção.
Gravidade moderadaCVSS: 2,3/10Correção disponível
Origin: null permite contornar restrições do servidor de desenvolvimento
O servidor iniciado com next dev podia aceitar Origin: null sem aplicar a verificação de origens permitidas aos endpoints internos, mesmo com allowedDevOrigins configurado. Ao visitar conteúdo controlado por um atacante durante o desenvolvimento, você poderia permitir que código executado pelo navegador acessasse funcionalidades sensíveis desse servidor a partir de um documento sandboxed. A correção submete a origem null às mesmas verificações aplicadas às outras origens.
Casos de uso afetados
Você mantém next dev em execução com allowedDevOrigins configurado e visita uma página maliciosa no navegador. Um documento com origem opaca, como um iframe sandboxed, tenta acessar os endpoints internos de desenvolvimento.
Confira na sua instância
Confira o comando que inicia seu servidor e a configuração de allowedDevOrigins. No ambiente de desenvolvimento atualizado, verifique se requisições aos endpoints internos e tentativas de conexão WebSocket com Origin: null recebem a recusa esperada para uma origem não autorizada. Caso exista um proxy, confira separadamente o tratamento das requisições HTTP e dos upgrades WebSocket. Até atualizar, rejeite ambos com essa origem no proxy e mantenha next dev fora de redes não confiáveis.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
next (npm)
>=16.0.1
16.1.7
CVE-2026-27977. A falha afeta somente next dev, não next start, e não expõe funcionalidades internas de depuração à rede por padrão. A gravidade moderada reproduz a classificação do comunicado, apesar da pontuação CVSS 4.0 de 2,3.
Programador há mais de 20 anos, fundador da Powertic e da Promovaweb. Embaixador do n8n no Brasil e da Baserow, Chatwoot, Miro e Kestra. Membro do Product Team do Mautic.
Canais oficiais
Nossos Links
Encontre a Promovaweb no canal que combina com o seu próximo passo.
