Vulnerabilidades do Next.js em 06/05/2026

Os 12 avisos publicados em 6 de maio de 2026 afetam recursos diferentes do Next.js. Você precisa comparar a versão de next realmente instalada no deploy com as faixas de cada ficha e conferir se sua aplicação usa o recurso descrito. A atualização de uma dependência no repositório precisa chegar ao servidor para que a aplicação utilize a correção.

AplicativoNext.js
Data do compilado
Vulnerabilidades12

A classificação de correção informa a disponibilidade no projeto, sem afirmar que seu deploy foi atualizado. As conferências abaixo orientam a revisão da configuração e do comportamento normal da aplicação, sem reproduzir ataques.

Gravidade altaCVSS: 8,6/10Correção disponível

Requisições a destinos arbitrários por upgrade de WebSocket

No servidor Node.js integrado do Next.js em hospedagem própria, requisições de upgrade de WebSocket preparadas por um atacante podem ser encaminhadas para destinos internos ou externos arbitrários. Esse comportamento permite usar o servidor para alcançar serviços internos ou endpoints de metadados da nuvem que não deveriam ficar acessíveis pelo site.

Casos de uso afetados

  • Você mantém uma instalação própria com o servidor Node.js integrado e permite que requisições de upgrade de WebSocket cheguem à origem.

Confira na sua instância

Confirme qual servidor atende a aplicação e revise como o proxy reverso encaminha upgrades de WebSocket. Confira se a origem aceita conexões diretamente de redes não confiáveis e quais destinos internos ou de metadados ela consegue acessar. Os upgrades encaminhados precisam corresponder aos rewrites externos autorizados pela configuração.

Versões afetadas e correções

Faixas declaradas no comunicado oficial, por linha de manutenção
LinhaAfetadasCorrigidas
next (npm), correção em 15.5.16>= 13.4.13 < 15.5.1615.5.16
next (npm), correção em 16.2.5>= 16.0.0 < 16.2.516.2.5

Instalações hospedadas na Vercel não são afetadas por este aviso. Até atualizar, restrinja o acesso direto à origem, recuse upgrades desnecessários no proxy ou balanceador e limite as conexões de saída para redes internas e serviços de metadados.

Gravidade altaCVSS: 8,1/10Correção disponível

Parâmetro de consulta altera a rota dinâmica após a autorização

Parâmetros de consulta preparados por um atacante podem mudar o valor da rota dinâmica recebido pela página sem alterar o caminho visível da requisição. O middleware confere um caminho, mas a página renderiza conteúdo associado a outro valor, permitindo contornar a autorização baseada somente na URL.

Casos de uso afetados

  • Você restringe rotas dinâmicas pelo matcher do middleware e a página usa o parâmetro resolvido para selecionar conteúdo privado.

Confira na sua instância

Acompanhe no código o identificador recebido pela página dinâmica até a consulta que seleciona o conteúdo. Confira se a permissão é validada para esse identificador efetivo, além da conferência do caminho pelo middleware. Revise também a origem dos parâmetros normalizados para identificar valores externos aceitos como informação interna de roteamento.

Versões afetadas e correções

Faixas declaradas no comunicado oficial, por linha de manutenção
LinhaAfetadasCorrigidas
next (npm), correção em 15.5.16>= 15.4.0 < 15.5.1615.5.16
next (npm), correção em 16.2.5>= 16.0.0 < 16.2.516.2.5

A correção limita a normalização interna a encaminhamentos confiáveis. A orientação temporária é validar a autorização na rota ou página para o conteúdo efetivamente consultado.

Gravidade altaCVSS: 7,5/10Correção disponível

Acesso a páginas protegidas pelas rotas de prefetch do App Router

As variantes .rsc e de prefetch de segmentos podem alcançar a mesma página do App Router por um caminho que o matcher do middleware ou Proxy não reconhece. Quando a autorização existe somente nessa camada, um atacante pode consultar conteúdo protegido sem passar pela conferência de acesso prevista.

Casos de uso afetados

  • Você usa o App Router e concentra a autorização de páginas privadas no middleware ou Proxy, incluindo páginas acessadas pelo prefetch de segmentos.

Confira na sua instância

Revise o matcher e localize a conferência de permissão na página ou rota protegida. Em homologação, acompanhe as requisições de prefetch geradas pela navegação normal e confira se elas recebem a mesma autorização da URL da página. Uma resposta negada na URL principal não comprova que as variantes também foram conferidas.

Versões afetadas e correções

Faixas declaradas no comunicado oficial, por linha de manutenção
LinhaAfetadasCorrigidas
next (npm), correção em 15.5.16>= 15.2.0 < 15.5.1615.5.16
next (npm), correção em 16.2.5>= 16.0.0 < 16.2.516.2.5

A atualização inclui as variantes de transporte nos matchers. Como medida temporária, confira a autorização também na lógica da página ou rota.

Gravidade altaCVSS: 7,5/10Correção disponível

Exposição do JSON de páginas privadas no Pages Router com i18n

O Pages Router pode responder a /_next/data/<buildId>/<page>.json sem executar o middleware quando a aplicação usa i18n e a requisição omite o prefixo de idioma. Assim, o JSON produzido pela renderização no servidor pode revelar o conteúdo de uma página privada mesmo que sua URL habitual exija autorização.

Casos de uso afetados

  • Sua aplicação combina o Pages Router, a configuração i18n e a autorização pelo middleware ou Proxy para páginas renderizadas no servidor.

Confira na sua instância

Confira a configuração i18n e abra a função que fornece o conteúdo no servidor para uma página privada. Você precisa encontrar ali a validação de sessão e de permissão, inclusive para a resposta JSON. Compare essa validação com o matcher das rotas /_next/data e confirme que a ausência do prefixo de idioma não dispensa a autorização.

Versões afetadas e correções

Faixas declaradas no comunicado oficial, por linha de manutenção
LinhaAfetadasCorrigidas
next (npm), correção em 15.5.16>= v12.2.0 < 15.5.1615.5.16
next (npm), correção em 16.2.5>= 16.0.0 < 16.2.516.2.5

A correção ajusta a correspondência das rotas de conteúdo. Até atualizar, aplique a autorização no caminho que produz o JSON da página no servidor.

Gravidade altaCVSS: 7,5/10Correção disponível

Consumo excessivo de CPU na desserialização de Server Functions

Uma requisição HTTP especialmente preparada para um endpoint de Server Function do App Router pode provocar consumo excessivo de CPU durante a desserialização. A falha vem de pacotes de React Server Components da série 19.x usados por frameworks como o Next.js e pode deixar a aplicação indisponível enquanto o servidor processa a entrada.

Casos de uso afetados

  • Sua aplicação usa o App Router com os pacotes afetados de React Server Components e possui endpoints de Server Functions acessíveis por HTTP.

Confira na sua instância

Confira a versão de next no artefato implantado e identifique os endpoints de Server Functions do App Router. Nos registros de requisições, procure aumentos de CPU associados ao processamento desses endpoints e compare com a duração das respostas. A ausência desse sintoma não comprova que a versão instalada recebeu a correção.

Versões afetadas e correções

Faixas declaradas no comunicado oficial, por linha de manutenção
LinhaAfetadasCorrigidas
next (npm), correção em 15.5.16>=13.0.0 < 15.5.1615.5.16
next (npm), correção em 16.2.5>= 16.0.0 < 16.2.516.2.5

O aviso relaciona a falha à CVE-2026-23870 do React. O texto fornecido não apresenta uma mitigação temporária específica.

Gravidade altaCVSS: 7,5/10Correção disponível

Conexões presas em Server Actions com Cache Components

Aplicações com pré-renderização parcial pelo recurso Cache Components podem manter conexões abertas por tempo prolongado ao receber uma requisição POST preparada para uma Server Action. O processamento do corpo entra em deadlock, ocupando descritores de arquivo e capacidade do servidor até esgotar a capacidade de atender novas conexões legítimas.

Casos de uso afetados

  • Você habilita a pré-renderização parcial com Cache Components e expõe Server Actions que podem receber o cabeçalho Next-Resume de clientes externos.

Confira na sua instância

Confira se o deploy usa Cache Components com pré-renderização parcial e examine o encaminhamento do cabeçalho Next-Resume no proxy. Você deve verificar se requisições externas com esse cabeçalho são recusadas na borda ou se a versão corrigida o remove. Nos registros do servidor, confira a duração das conexões e o uso de descritores associados às Server Actions.

Versões afetadas e correções

Faixas declaradas no comunicado oficial, por linha de manutenção
LinhaAfetadasCorrigidas
next (npm), correção em 15.5.16>=15.0.0 < 15.5.1615.5.16
next (npm), correção em 16.2.5>=16.0.0 < 16.2.516.2.5

A correção reserva Next-Resume para uso interno e o remove de requisições não confiáveis. Até atualizar, recuse na borda as requisições destinadas ao Next.js que tragam esse cabeçalho.

Gravidade moderadaCVSS: 6,1/10Correção disponível

JavaScript injetado no conteúdo de scripts beforeInteractive

O conteúdo serializado de scripts beforeInteractive pode entrar no documento sem o escape de HTML necessário. Quando esse conteúdo contém uma entrada controlada por um atacante, ela pode encerrar a delimitação prevista do script e introduzir JavaScript executado no navegador do visitante.

Casos de uso afetados

  • Você incorpora conteúdo não confiável em scripts com a estratégia beforeInteractive, por exemplo ao montar seu conteúdo a partir de campos que visitantes podem alterar.

Confira na sua instância

Localize os scripts configurados com beforeInteractive e siga a origem de cada trecho interpolado. Confira no HTML gerado se o conteúdo externo recebe escape adequado à sua inserção no documento. Você precisa revisar a serialização efetiva, pois a conferência do texto original do campo não mostra como ele foi incorporado à página.

Versões afetadas e correções

Faixas declaradas no comunicado oficial, por linha de manutenção
LinhaAfetadasCorrigidas
next (npm), correção em 15.5.16>=13.0.0 < 15.5.1615.5.16
next (npm), correção em 16.2.5>= 16.0.0 < 16.2.516.2.5

A atualização aplica escape de HTML ao conteúdo serializado. Até atualizar, retire entradas não confiáveis desses scripts ou aplique sanitização e escape apropriados à inserção.

Gravidade moderadaCVSS: 5,9/10Correção disponível

Esgotamento de memória ao otimizar arquivos locais grandes

Em hospedagem própria com o loader padrão, a otimização de imagens carrega arquivos locais inteiros na memória sem impor um limite máximo ao tamanho da resposta. Requisições a /_next/image para arquivos grandes aceitos por images.localPatterns podem esgotar a memória do processo e interromper o atendimento da aplicação.

Casos de uso afetados

  • Você usa o loader padrão em uma instalação própria e permite otimizar arquivos locais grandes por /_next/image. Sem restringir images.localPatterns, todos os padrões locais são aceitos por padrão.

Confira na sua instância

Abra a configuração images e confira o loader, images.unoptimized e os caminhos aceitos por images.localPatterns. Relacione esses caminhos aos tamanhos dos arquivos locais que você disponibiliza. Na versão corrigida, confira também images.maximumResponseBody e confirme que seu limite corresponde ao tamanho máximo que a aplicação deve aceitar.

Versões afetadas e correções

Faixas declaradas no comunicado oficial, por linha de manutenção
LinhaAfetadasCorrigidas
next (npm), correção em 15.5.16>=10.0.0 < 15.5.1615.5.16
next (npm), correção em 16.2.5>= 16.0.0 < 16.2.516.2.5

A Vercel, images.unoptimized: true e images.loader: 'custom' ficam fora do cenário afetado. Até atualizar, retire arquivos grandes ou não confiáveis da otimização local ou recuse seu acesso pelo proxy. A configuração images.localPatterns: [] desativa a otimização de arquivos locais e mantém a busca de imagens remotas.

Gravidade moderadaCVSS: 5,4/10Correção disponível

Cache serve conteúdo de Server Components no lugar do HTML

Uma interpretação inconsistente do cabeçalho RSC pode fazer o Next.js servir o conteúdo de React Server Components pela URL original da página. Quando o cache compartilhado reúne essa resposta e o HTML na mesma entrada, um atacante pode contaminar o cache e fazer visitantes posteriores receberem o payload dos componentes no lugar da página renderizada.

Casos de uso afetados

  • Você usa o App Router com React Server Components atrás de um cache que não distingue as respostas dos componentes das respostas HTML para a mesma página.

Confira na sua instância

Compare os cabeçalhos e o corpo da resposta de uma abertura normal da página com os de uma navegação interna pelo App Router. Confira se o proxy ou a rede de distribuição de conteúdo respeita Vary e inclui os cabeçalhos relevantes de RSC na chave de cache. Depois de uma navegação interna, uma nova abertura da página precisa continuar recebendo o HTML esperado.

Versões afetadas e correções

Faixas declaradas no comunicado oficial, por linha de manutenção
LinhaAfetadasCorrigidas
next (npm), correção em 15.5.16>= 14.2.0 < 15.5.1615.5.16
next (npm), correção em 16.2.5>= 16.0.0 < 16.2.516.2.5

A correção uniformiza a interpretação do cabeçalho RSC e aplica a separação prevista pelo mecanismo de cache. Como medida temporária, ajuste a chave do cache e o uso de Vary ou desative o cache compartilhado das respostas afetadas do App Router.

Gravidade moderadaCVSS: 4,7/10Correção disponível

Execução de scripts por nonce malformado em páginas com cache

Páginas do App Router que usam nonces na política de segurança de conteúdo podem inserir no HTML um nonce malformado extraído dos cabeçalhos da requisição. Em uma instalação com cache compartilhado, um atacante pode contaminar a resposta armazenada e provocar a execução de JavaScript no navegador de visitantes posteriores.

Casos de uso afetados

  • Você usa nonces da política de segurança de conteúdo no App Router e armazena o HTML dessas páginas em um cache compartilhado.

Confira na sua instância

Revise a origem do nonce e confira como ele chega aos atributos do HTML. Você deve distinguir o cabeçalho Content-Security-Policy definido pela infraestrutura confiável daquele enviado pelo visitante. Confira no proxy se cabeçalhos externos com esse nome são removidos e examine quais páginas com nonce podem ter o HTML reutilizado pelo cache.

Versões afetadas e correções

Faixas declaradas no comunicado oficial, por linha de manutenção
LinhaAfetadasCorrigidas
next (npm), correção em 15.5.16>= 13.4.0 < 15.5.1615.5.16
next (npm), correção em 16.2.5>= 16.0.0 < 16.2.516.2.5

A correção rejeita ou ignora nonces malformados e reforça sua sanitização. Remover o Content-Security-Policy das requisições externas não confiáveis é a medida temporária indicada, preservando a política legítima gerada pela aplicação.

Gravidade baixaCVSS: 3,7/10Correção disponível

Redirecionamento inutilizável armazenado no cache compartilhado

Uma requisição externa com x-nextjs-data pode fazer o middleware ou Proxy substituir o cabeçalho Location por x-nextjs-redirect em um redirecionamento comum. O navegador não segue esse cabeçalho interno. Se o cache intermediário armazena a resposta 3xx sem distinguir esse cabeçalho de entrada, outras visitas podem receber o redirecionamento sem destino até a entrada expirar ou ser removida.

Casos de uso afetados

  • Você publica redirecionamentos pelo middleware ou Proxy atrás de uma rede de distribuição de conteúdo ou proxy reverso que armazena respostas 3xx sem variar por x-nextjs-data.

Confira na sua instância

Inspecione a configuração de cache de uma rota que redireciona e confira se x-nextjs-data participa da chave para respostas 3xx. Na navegação normal, compare os cabeçalhos de uma resposta recém-gerada com os de uma resposta servida pelo cache. Ambas precisam preservar o Location esperado para o navegador.

Versões afetadas e correções

Faixas declaradas no comunicado oficial, por linha de manutenção
LinhaAfetadasCorrigidas
next (npm), correção em 15.5.16>= 12.2.0 < 15.5.1615.5.16
next (npm), correção em 16.2.5>= 16.0.0 < 16.2.516.2.5

A versão corrigida valida o encaminhamento interno em vez de confiar somente no cabeçalho. Separar as entradas de cache por x-nextjs-data é a mitigação temporária indicada no aviso.

Gravidade baixaCVSS: 3,7/10Correção disponível

Colisões de _rsc misturam variantes no cache compartilhado

O valor _rsc usado para separar respostas de React Server Components pode apresentar colisões exploráveis quando o cache compartilhado distingue insuficientemente as variantes. Um atacante pode contaminar uma entrada e fazer outras visitas receberem uma variante incorreta para a mesma URL.

Casos de uso afetados

  • Sua instalação armazena respostas de React Server Components em cache compartilhado e a separação das variantes depende de _rsc sem respeitar adequadamente os cabeçalhos indicados por Vary.

Confira na sua instância

Examine a chave de cache e confira como o intermediário usa _rsc e os cabeçalhos indicados por Vary nas respostas de React Server Components. Você pode comparar duas navegações normais que produzam variantes diferentes da mesma URL e verificar se o cache mantém entradas distintas. Esse teste confere a separação das respostas, sem comprovar a ausência de colisões na versão instalada.

Versões afetadas e correções

Faixas declaradas no comunicado oficial, por linha de manutenção
LinhaAfetadasCorrigidas
next (npm), correção em 15.5.16>= 13.4.6 < 15.5.1615.5.16
next (npm), correção em 16.2.5>= 16.0.0 < 16.2.516.2.5

A atualização reforça a geração de _rsc para dificultar colisões e separar variantes. Até atualizar, faça o cache respeitar Vary nos cabeçalhos relacionados aos componentes ou desative o cache compartilhado das respostas afetadas.

Voltar aos compilados de vulnerabilidades
Luiz Eduardo Oliveira Fonseca

Luiz Eduardo Oliveira Fonseca

Fundador e Mentor

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.

Área pública disponível

Participe da comunidade no Discord

Entre pelo convite oficial, apresente-se à comunidade e acompanhe os avisos e projetos compartilhados entre os encontros.