--- name: azion-mitigue-a-cve-2025-29927-no-next-js description: >- Remova o header x-middleware-subrequest com uma regra do Rules Engine em Azion Applications, para que uma requisição forjada não pule o middleware do Next.js. --- # Mitigue a CVE-2025-29927 no Next.js Você pode bloquear as requisições que exploram a CVE-2025-29927 pelo Azion Console, com uma regra no [Rules Engine for Applications](/pt-br/documentacao/plataforma/applications/rules-engine/) que remove o header do qual o exploit depende. A CVE-2025-29927 é uma vulnerabilidade no Next.js, com score CVSS 9.1, que permite a uma requisição pular a execução do middleware. O middleware do Next.js costuma carregar autenticação, autorização e rate limiting, então uma requisição que o pula alcança rotas protegidas sem nenhuma credencial. O registro do advisory é [GHSA-f82v-jwr5-mffw](https://github.com/advisories/GHSA-f82v-jwr5-mffw) e no [aviso de segurança do Next.js](https://nextjs.org/blog/cve-2025-29927). O Next.js usa um header interno, `x-middleware-subrequest`, para contar as chamadas recursivas de middleware e impedir um loop infinito. Um cliente externo nunca foi feito para enviá-lo. Quando uma requisição chega com esse header em um valor específico, o Next.js lê a requisição como uma subrequisição interna e não executa nenhum middleware. O Next.js 14.x e 15.x aceitam este valor: ```http x-middleware-subrequest: middleware:middleware:middleware:middleware:middleware ``` O Next.js 11.1.4 até 12.1.x aceita, em vez disso, um path de middleware: ```http x-middleware-subrequest: pages/_middleware x-middleware-subrequest: pages/dashboard/_middleware ``` A requisição não precisa de credenciais nem de privilégios especiais, e funciona a partir de qualquer rede. Um exploit bem-sucedido pode: - Alcançar rotas protegidas e painéis administrativos - Pular as verificações de autenticação e autorização - Expor dados sensíveis e APIs internas - Contornar o rate limiting e outras medidas de proteção - Envenenar o cache, o que leva a negação de serviço > **Atenção** > > Atualizar o Next.js é a correção definitiva. Trate a regra abaixo como uma medida temporária enquanto você planeja e executa a atualização. --- ## Pré-requisitos - Uma conta Azion. Consulte [Como criar uma conta na Azion](/pt-br/documentacao/fundamentos/criar-uma-conta/). - Uma application em [Applications](/pt-br/documentacao/plataforma/applications/) cuja origem é o seu deployment do Next.js. - Acesso ao Azion Console. Para entrar, consulte [Como acessar o Azion Console](/pt-br/documentacao/guias/plataforma/conta-e-billing/como-acessar-o-azion-console/). --- ## Detecte uma aplicação vulnerável Um deployment é vulnerável quando a versão do Next.js que ele executa cai dentro de um destes intervalos: | Versão do Next.js | Intervalo vulnerável | Versão com patch | | ----------------- | ---------------------- | ----------------------- | | 15.x | `>= 15.0.0, < 15.2.3` | `15.2.3` | | 14.x | `>= 14.0.0, < 14.2.25` | `14.2.25` | | 13.x | `>= 13.0.0, < 13.5.9` | `13.5.9` | | 12.x | `>= 12.0.0, < 12.3.5` | `12.3.5` | | 11.x | Todas as versões | Nenhum patch disponível | Nem sempre é possível ler a versão de fora do deployment. Quatro sinais em uma resposta HTTP apontam para uma aplicação Next.js que executa middleware: - O header de resposta `x-powered-by: Next.js`, que um deployment pode desligar, então a ausência dele não prova nada - Um header de resposta `x-middleware-rewrite` ou `x-nextjs-cache` - Uma referência a `/_next/static/` no corpo de uma resposta - Uma resposta ao header do exploit diferente da resposta a uma requisição comum Para sondar um alvo, ou uma lista deles, com o [template Nuclei para a CVE-2025-29927](https://github.com/6mile/nextjs-CVE-2025-29927): ```bash # Scan a single target nuclei -u https:/// -t ./CVE-2025-29927-6mile.yaml -fr # Scan a list of targets nuclei -l websites.list -t ./CVE-2025-29927-6mile.yaml -fr -silent ``` Uma correspondência positiva significa que a aplicação executa Next.js com headers de middleware. Ela não nomeia a versão, então leia a versão do Next.js no seu ambiente de deployment antes de decidir. --- ## Crie a regra de mitigação O advisory do Next.js recomenda bloquear qualquer requisição externa que carregue o header `x-middleware-subrequest` antes que ela alcance a aplicação. Uma regra com o behavior **Filter Request Header** remove esse header de toda requisição recebida, de modo que o Next.js nunca o lê e o middleware executa como foi escrito. Uma regra cobre todas as rotas da application, não exige nenhuma alteração no código da aplicação, e é criada e removida independentemente do seu ciclo de releases. Para criar a regra: 1. **Abra a application** Acesse o [Azion Console](https://console.azion.com/) > **Applications** e selecione a application que serve o seu deployment do Next.js. 2. **Selecione a aba Rules Engine** 3. **Selecione + Rule** 4. **Nomeie a regra** Digite um nome para a regra. Por exemplo: `Strip x-middleware-subrequest - CVE-2025-29927`. 5. **(Opcional) Descreva a regra** Digite uma descrição. Por exemplo: `Strips the x-middleware-subrequest header from all incoming requests to mitigate CVE-2025-29927 in Next.js.` 6. **Confirme que Request Phase está selecionado** 7. **Defina o critério** Na seção **Criteria**, selecione a variável `${uri}`, o operador de comparação *starts with* e `/` como argumento. Isso corresponde a toda requisição à application. 8. **Adicione o behavior Filter Request Header** Na seção **Behaviors**, selecione **Filter Request Header**. 9. **Digite o nome do header** No campo do nome do header, digite `x-middleware-subrequest`. 10. **Salve a regra** A regra aparece na aba **Rules Engine** da application. Ela leva alguns minutos para alcançar a infraestrutura distribuída da Azion, então uma requisição enviada logo em seguida ainda pode levar o header até a origem. --- ## Valide a mitigação Envie a mesma requisição duas vezes, uma com o header do exploit e outra sem ele: ```bash # With the exploit header curl -i -H 'x-middleware-subrequest: middleware:middleware:middleware:middleware:middleware' \ https:///protected-route # Without the exploit header curl -i https:///protected-route ``` As duas chamadas retornam a mesma resposta, porque o header foi removido antes de qualquer uma das requisições alcançar a origem. Uma rota protegida que o header do exploit abria antes da regra continua fechada depois dela. Para revisar as requisições que alcançaram a application, consulte [Real-Time Events](/pt-br/documentacao/plataforma/real-time-events/). --- ## Atualize o Next.js para uma versão com patch A regra remove o header, e o código vulnerável continua no deployment até você substituí-lo. Atualize para a release com patch da sua versão major: | Versão atual | Alvo da atualização | | ------------ | ------------------------------- | | 15.x | `>= 15.2.3` | | 14.x | `>= 14.2.25` | | 13.x | `>= 13.5.9` | | 12.x | `>= 12.3.5` | | 11.x | Atualize para 12.x ou posterior | Assim que a release com patch estiver em produção e a aplicação se comportar como esperado, desligue ou exclua a regra. --- ## Próximos passos - [Rules Engine for Applications](/pt-br/documentacao/plataforma/applications/rules-engine.md): Todos os criteria e behaviors que você pode definir em uma regra de application. - [Applications](/pt-br/documentacao/plataforma/applications.md): Como uma application roteia uma requisição até a sua origem. - [Real-Time Events](/pt-br/documentacao/plataforma/real-time-events.md): Leia o que cada requisição carregava quando alcançou a application. - [WAF guides and tutorials](/pt-br/documentacao/plataforma/firewall/guias.md): As outras tarefas de segurança de aplicações neste hub.