CVE-2025-29927 no Next.js: por que o middleware não deve ser sua única barreira de acesso

Publicado em 2026-10-27 por frfrand

O bypass de middleware no Next.js explicado com cenários reais, escopo por hosting, patches e recomendações de autorização.

O cenário: ocultar uma página não significa proteger seus dados

Suponha que você criou um painel privado com Next.js. O middleware verifica se há sessão e, se não encontrar, redireciona para o login. Parece suficiente, mas CVE-2025-29927 deixou uma lição importante: uma falha no tratamento de certo sinal interno do framework poderia fazer com que a execução do middleware fosse ignorada. Se toda a segurança dependesse desse único passo, algumas rotas poderiam ficar indevidamente acessíveis.

O que é middleware no Next.js?

É código que pode intervir antes do roteamento para modificar, redirecionar ou bloquear requisições. Serve para muitas tarefas, incluindo uma verificação inicial de sessão. Mas uma validação de acesso sensível também deve ser executada onde os dados são entregues ou a operação é realizada, não apenas antes de chegar à página.

Quem descobriu a vulnerabilidade e como foi reportado?

O Next.js credita aos pesquisadores Rachid Allam (zhero) e Yassir Alam (inzo_). O relatório privado inicial chegou em 27 de fevereiro de 2025. Em sua análise posterior, o projeto detalhou atrasos e melhorias de coordenação antes de publicar os patches e a CVE em março. É um caso útil para entender a divulgação responsável e por que o processo de resposta também faz parte da segurança.

Como poderia ser explorado?

O Next.js usava um cabeçalho interno para identificar solicitações que não deveriam passar novamente por certas partes do middleware. Em implementações vulneráveis, uma requisição externa manipulada poderia aproveitar esse mecanismo e influenciar na execução do controle. Não significa que todos os aplicativos Next.js expusessem dados: o efeito prático dependia de se o middleware era a única barreira de autorização.

Quais instalações estavam expostas?

A análise oficial confirmou risco em determinados aplicativos autohospedados com next start e output: 'standalone'. Descartou exportações estáticas sem middleware. Também indicou que a arquitetura de implantação do Vercel, Netlify e Cloudflare Workers avaliada naquela época não sofria esse bypass. Por isso, ao estudar uma CVE do Next.js, o modo de implantação é tão importante quanto a versão.

Quais versões receberam o patch?

O projeto publicou correções para 14.2.25, 15.2.3, e depois versões retroportadas 13.5.9 e 12.3.5 em março de 2025. Estas são as primeiras correções históricas: para um projeto novo ou uma atualização em 2026, procure uma versão de manutenção vigente.

O que faço para proteger um app?

Atualize o Next.js e verifique o artefato implantado; revise quais endpoints confiam exclusivamente no middleware; comprove a autorização também em handlers, server actions e acesso a dados; bloqueie cabeçalhos internos não confiáveis na borda quando o aviso recomendar e a atualização não for imediata. Os controles devem decidir sobre a identidade e as permissões de cada operação sensível.

Como saber se alguém aproveitou o problema?

Contraste acessos a rotas protegidas, padrões incomuns em logs de proxy, operações realizadas por usuários e ausência de verificações de autorização. Um acesso a um recurso não equivale necessariamente a vazamento, mas pode justificar revisão de incidentes. Se houve exposição, rotacione credenciais e notifique conforme as obrigações aplicáveis.

Perguntas frequentes

O aplicativo se salva se usa JWT? Um token não corrige um fluxo que deixa pular o único controle de autorização.

O provedor de VPS pode arrumar isso por mim? O patch do framework e as decisões de autorização continuam sendo responsabilidade do código e de sua implantação, de acordo com o serviço contratado.

Devo parar de usar middleware? Não: use-o como uma camada a mais, não como fronteira única.

Fontes: Postmortem oficial do Next.js · Registro CVE.

Onde seguir alertas CVE e receber orientação?

Em ArduMaker CVE e suporte publicamos atualizações e centralizamos consultas sobre vulnerabilidades, começando pelo WordPress e suas tecnologias relacionadas. Se o seu caso envolver outro runtime ou um banco de dados, especifique componente, versão, sistema operacional e exposição do serviço para contextualizá-lo. O aviso de uma CVE não prova que seu servidor esteja comprometido: a avaliação requer inventário, configuração e evidência.

Nota editorial — outubro de 2026: estas versões corrigidas são os marcos do aviso original. Ao atualizar hoje, escolha um ramo com suporte vigente e verifique o comunicado atual do fabricante.

Exemplo prático: duas barreiras para uma rota de administração

Situação: um app Next.js oculta /admin por meio de middleware, mas o handler que devolve faturas não verifica as permissões do usuário. CVE-2025-29927 mostrou por que depender de uma única barreira é um risco.

Em um Route Handler, implemente outra validação independente:

// Ejemplo ilustrativo: getCurrentUser debe implementarse
// con tu sistema real de sesiones.
export async function GET(request) {
  const user = await getCurrentUser(request);
  if (!user || !user.isAdmin) {
    return new Response("Acceso denegado", { status: 403 });
  }
  return Response.json(await cargarFacturasAutorizadas(user));
}

Antes: «se passou pelo middleware, então pode ver tudo». Depois: middleware para redirecionamento ou primeira verificação, mais autorização na rota, server action e camada de dados conforme necessário.

Teste funcional seguro: faça login com uma conta sem permissões de administrador e solicite o endpoint normalmente. O servidor deve retornar 403 e não entregar os dados. Além disso, atualize o Next.js para o patch correspondente e verifique o modo de implantação.