Lançamento da versão 15.2.3 do Next.js corrige vulnerabilidade de segurança

• CVE-2025-29927

• A versão 15.2.3 do Next.js foi lançada para corrigir uma vulnerabilidade de segurança (CVE-2025-29927). É recomendável atualizar imediatamente todas as implantações autohospedadas do Next.js que usam next start e output: 'standalone'.

• Linha do tempo

  • 2025-02-27T06:03Z: Divulgado à equipe do Next.js por meio de um relatório privado de vulnerabilidade no GitHub
  • 2025-03-14T17:13Z: A equipe do Next.js iniciou a análise do relatório
  • 2025-03-14T19:08Z: Patch distribuído para o Next.js 15.x
  • 2025-03-14T19:26Z: Patch distribuído para o Next.js 14.x
  • 2025-03-17T22:44Z: Lançamento do Next.js 14.2.25
  • 2025-03-18T00:23Z: Lançamento do Next.js 15.2.3
  • 2025-03-18T18:03Z: Publicação do CVE-2025-29927 no GitHub
  • 2025-03-21T10:17Z: Divulgação do aviso de segurança
  • 2025-03-22T21:21Z: Lançamento do Next.js 13.5.9
  • 2025-03-23T06:44Z: Lançamento do Next.js 12.3.5

• Detalhes da vulnerabilidade

  • O Next.js usa o cabeçalho interno x-middleware-subrequest para evitar loops infinitos. Segundo o relatório de segurança, existe a possibilidade de ignorar a execução do middleware e contornar verificações importantes.

• Escopo do impacto

  • Casos afetados

    • Aplicações Next.js autohospedadas que usam middleware (next start e output: 'standalone')
    • Casos em que o middleware é usado para autenticação ou verificações de segurança
    • Aplicações que usam Cloudflare podem ativar regras gerenciadas de WAF

  • Casos não afetados

    • Aplicações hospedadas na Vercel
    • Aplicações hospedadas na Netlify
    • Aplicações implantadas como exportação estática (o middleware não é executado)

• Versões corrigidas

  • Next.js 15.x: problema corrigido em 15.2.3
  • Next.js 14.x: problema corrigido em 14.2.25
  • Next.js 13.x: problema corrigido em 13.5.9
  • Next.js 12.x: problema corrigido em 12.3.5
  • Se não for possível aplicar o patch para uma versão segura, é recomendável impedir que solicitações externas de usuários incluam o cabeçalho x-middleware-subrequest

• Nossa responsabilidade com a segurança

  • O Next.js publicou 16 avisos de segurança desde 2016. Avisos de segurança do GitHub e CVEs são o padrão da indústria para informar usuários, fornecedores e empresas sobre vulnerabilidades de software. Para suprir lacunas na comunicação com parceiros, foi criada uma lista de e-mails para parceiros. Você pode entrar em contato por [e-mail] para ser incluído.

[GN⁺]

Opiniões no Hacker News

• O sistema de middleware do Next tem muitos problemas e talvez fosse melhor reimplementá-lo do zero

  • Não há uma forma oficial de encadear vários middlewares
  • Funções principais são definidas como membros estáticos, o que pode causar problemas ao usar middleware de terceiros
  • Faltam formas de comunicação entre middleware e route handlers
  • Passar dados por meio de headers não é seguro
  • Também há o problema de ter que abrir mão do cache automático
  • É difícil obter o hostname real da requisição

• Encontraram outro artigo sobre problemas de segurança no sistema de middleware

  • O método de comunicação via headers está separado da validação da entrada do usuário
  • Permitir todos os headers vindos do usuário pode ser arriscado
  • É necessário suporte do framework para resolver problemas de design do servidor

• Informações sobre a vulnerabilidade de segurança no Next.js

  • Havia uma vulnerabilidade em que, ao adicionar um header específico, o servidor podia retornar uma resposta incorreta
  • Não há CVE para essa vulnerabilidade, e não está claro quais versões são afetadas
  • De acordo com a política de suporte do Next.js, apenas versões específicas receberam patch

• Preocupação com a demora para corrigir o problema de segurança no Next.js

  • A correção só começou mais de duas semanas após o reporte
  • É possível que a gravidade do problema não tenha sido comunicada adequadamente

• Críticas à complexidade do Next.js

  • React entregou muito valor, mas o Next só adiciona complexidade
  • Roteamento baseado em arquivos e server-side rendering só são úteis em situações específicas

• Simplicidade de exploração da vulnerabilidade

  • Adicionar um header específico pode permitir burlar a autenticação

• Problema com o uso de headers internos no Next.js

  • Existe um header interno para evitar requisições recursivas
  • Pode haver possibilidade de burlar validações importantes por meio desse header

• Insegurança sobre a escolha de self-hosting do Next.js

  • Quanto mais se leem os comentários no HN, maior fica a insegurança sobre essa escolha

• Preocupação com a demora na correção do problema de segurança

  • O atraso de 13 dias para resolver o problema é algo grave