Guias de Segurança

Next.js e React têm muitas vulnerabilidades? O que os dados de CVE realmente mostram

Consultamos o NVD: o Next.js tem 56 CVEs (28 em 2026), o React tem 6, e todos os CVEs recentes do React estão nos Server Components. O risco não está no código de front-end, mas nos recursos de servidor que o framework agora oferece.

Publicado 2026-08-22 Atualizado 2026-10-04 Última verificação 2026-08-22 9 min de leitura

Para quem é: equipes que rodam Next.js em produção e quem está decidindo se vai adotá-lo. O objetivo é trocar uma sensação vaga de que "frameworks têm muitos CVEs" pelos números reais e pelo que há dentro deles.

Os dados (NVD, em 22 de agosto de 2026)

CVEs associados ao Next.js (total)

publicados em 2026 — o dobro do ano anterior

CVEs associados ao React (total)

5/5

CVEs recentes do React que estão nos RSC — o lado do servidor

	Next.js	React
Total	56	6
Por ano	2020:1 / 2021:3 / 2022:3 / 2023:1 / 2024:6 / 2025:14 / 2026:28	2018:1 / 2025:4 / 2026:1
Gravidade	CRITICAL 2, HIGH 21, MEDIUM 29, LOW 4	CRITICAL 1, HIGH 3, MEDIUM 2
O pior item	CVE-2025-29927 — contorno de autorização quando a autenticação é feita no middleware (CVSS 9.1)	CVE-2025-55182 — RCE sem autenticação nos React Server Components (CVSS 10.0)

Como ler a contagem de CVEs

Uma contagem alta não significa tecnologia perigosa. Mais adoção traz mais pesquisa, e mais pesquisa produz mais relatos. Uma contagem baixa pode significar "seguro" — ou pode significar "ninguém está olhando". O número é só um ponto de partida; a decisão vem de onde os problemas ficam e de que tipo são. Os números aqui vêm de consultas ao NVD por CPE (vercel:next.js, facebook:react), então o que não tem CPE atribuído não é contado.

Onde eles ficam

Classificando os CVEs do Next.js publicados em 2025–2026 pelo recurso citado nas descrições:

Onde	Como aparece
Cache	Confusão e envenenamento de cache — a resposta de um usuário entregue a outro
Middleware / roteamento	Contorno de autorização: uma rota que você acredita estar protegida pelo middleware deixa passar
Otimização de imagens	SSRF e esgotamento de recursos ao buscar URLs remotas
Server Actions / RSC	Desserialização de corpos de requisição não confiáveis; sobrecarga provocada por requisições
rewrites / redirects	Interpretação divergente do destino do encaminhamento

A distribuição de CWEs diz o mesmo: CWE-770 (alocação descontrolada de recursos), CWE-918 (SSRF), CWE-502 (desserialização), CWE-400 (esgotamento de recursos), CWE-444 (interpretação inconsistente de requisições), CWE-288/285 (contorno e falha de autorização). É uma lista de fraquezas de servidor e de proxy.

Lado do navegador — React renderizando componentes

um CVE do NVD para o próprio React, de 2018

Lado do servidor 1: React Server Components

os cinco CVEs recentes do React estão aqui (o pior: RCE sem autenticação)

Lado do servidor 2: middleware / cache / otimizador de imagens / rewrites do Next.js

contorno de autorização, SSRF, envenenamento de cache, esgotamento de recursos

O que se chama de 'vulnerabilidade do React/Next.js' acontece quase inteiramente na metade de baixo deste diagrama, no lado do servidor.

O problema que sempre volta: autorização no middleware

Um padrão repetido importa mais do que qualquer CVE isolado.

Março de 2025 — CVE-2025-29927 (CVSS 9.1)
Uma requisição com um cabeçalho específico podia contornar as verificações de autorização feitas no middleware. Corrigido nas versões 12.3.5 / 13.5.9 / 14.2.25 / 15.2.3.
Maio de 2026 — CVE-2026-44574 (CVSS 8.1)
Parâmetros de consulta manipulados podiam alterar o valor da rota dinâmica que a página via sem mudar o caminho visível, renderizando conteúdo protegido sem passar pela verificação do middleware. Corrigido nas versões 15.5.16 / 16.2.5.
Julho de 2026 — CVE-2026-64642 (CVSS 8.2)
No App Router com Turbopack e uma única entrada em config.i18n.locales, requisições manipuladas podiam contornar a autenticação feita no middleware/proxy. Corrigido na versão 16.2.11.

A conclusão de design que isso impõe

Três contornos de autorização de alta gravidade no middleware em dezoito meses. Não é uma sequência de bugs de implementação isolados; é o que acontece quando a decisão é tomada antes da rota, e a interpretação dessa rota pode mudar. A nossa posição: mantenha o middleware como uma primeira verificação grosseira, e tome a decisão real de autorização de novo logo antes de acessar os dados (na página, no route handler ou na camada de dados). Escrever a verificação duas vezes custa menos do que o dano de um único contorno.

Parte disso depende de como você hospeda

Fácil de deixar passar: o mesmo CVE pode afetar você de forma diferente dependendo de você hospedar por conta própria ou não. A CVE-2026-44578 (CVSS 8.6) permite SSRF por meio de requisições de upgrade de WebSocket manipuladas em implantações auto-hospedadas que usam o servidor Node.js embutido, podendo alcançar serviços internos ou endpoints de metadados da nuvem — e o comunicado afirma que implantações hospedadas na Vercel não são afetadas.

Ou seja, "uma vulnerabilidade do Next.js" não é uma coisa só. Se ela se aplica depende de como você o roda e de quais recursos você usa.

O que fazer

Autorize duas vezes (o que mais vale a pena)

Mantenha a verificação do middleware como uma primeira verificação grosseira e decida de novo imediatamente antes de acessar os dados. Os três contornos acima teriam sido contidos com isso. Sobre separar os dois conceitos, veja autenticação vs. autorização.

Use allow-list para o que o seu servidor pode buscar

Restrinja as URLs remotas que o otimizador de imagens vai carregar, os destinos do fetch no servidor e os destinos dos rewrites. Problemas de SSRF causam mais dano onde os destinos de saída não têm restrição. Verifique também se o endpoint de metadados da sua nuvem é alcançável a partir do app.

Coloque os endpoints de Server Actions e RSC atrás de autenticação

São caminhos que desserializam corpos de requisição — e CVEs de CWE-502 já apareceram ali de fato. Não os deixe fora da autenticação, aplique limites de taxa e garanta que cargas inesperadas não consigam derrubar o processo. Trate-os exatamente como você trataria /api.

Transforme a atualização num sistema

O Next.js publica correções rapidamente, o que só ajuda se você atualizar. Os detalhes (julgar pela versão de fato em execução e monitorar dependências automaticamente) estão em rodando Next.js com segurança e primeiros passos com o osv-scanner. Com 28 CVEs por ano, a atenção manual não dá conta.

A visão deste site: a questão do framework não é a contagem

"Devemos evitar o Next.js porque ele tem muitos CVEs?" é a pergunta errada. O que os dados mostram é que o Next.js assumiu cada vez mais responsabilidades de servidor — ele autoriza no middleware, busca imagens remotas, mantém um cache, desserializa requisições. Na prática, uma única dependência entrega a você um proxy reverso e um servidor de aplicação. Então o que avaliar não é a contagem, mas quais desses recursos de servidor você de fato usa, e quem os defende. Desligue o que você não precisa; dobre os seus próprios controles em volta do que você usa. Vista assim, a escolha deixa de ser questão de gosto e vira uma pergunta sobre a sua capacidade operacional.

Fontes

NVD (NIST) — números obtidos consultando cpe:2.3:a:vercel:next.js e cpe:2.3:a:facebook:react em 22 de agosto de 2026
CVE-2025-29927 (contorno de autorização no middleware) / CVE-2026-44574 (alteração do valor da rota dinâmica) / CVE-2026-64642 (contorno de autenticação no App Router + Turbopack)
CVE-2026-44578 (SSRF via WebSocket em implantações auto-hospedadas; hospedagem na Vercel não afetada)
CVE-2025-55182 (RCE sem autenticação nos React Server Components, CVSS 10.0) / CVE-2026-23864 (negação de serviço nos RSC)

Leia a seguir

Implementação: prototype pollution no Node.js (a área que o runtime declarou fora do escopo)
Operação: rodando Next.js com segurança sem ficar para trás nos CVEs / monitoramento automático de dependências com o osv-scanner
Design: autenticação vs. autorização / falsificação do X-Forwarded-For e proxies confiáveis
Termos: o que é SSRF / o que é um CVE

FAQ

QO Next.js tem muitas vulnerabilidades?

Em número, sim, e o número está aumentando. Uma consulta ao NVD em 22 de agosto de 2026 retorna 56 CVEs associados ao Next.js: 6 publicados em 2024, 14 em 2025 e 28 em 2026. Mas não leia um número alto como 'tecnologia perigosa' — mais adoção traz mais pesquisa e, com ela, mais relatos. O que importa é onde os problemas ficam, não quantos são.

QO React tem poucas vulnerabilidades?

O React como biblioteca de interface no navegador tem muito poucas: seis no NVD. E, tirando uma de 2018, todas as recentes dizem respeito aos React Server Components (react-server-dom-parcel / turbopack / webpack), que rodam no servidor. Uma delas, a CVE-2025-55182, é uma execução remota de código sem autenticação com CVSS 10.0.

QEntão onde está o risco de verdade?

Nos recursos de servidor. Os CVEs recentes do Next.js se concentram em middleware, cache, otimização de imagens, Server Actions e rewrites, e os CWEs principais são SSRF (CWE-918), desserialização de dados não confiáveis (CWE-502), consumo descontrolado de recursos (CWE-770/400) e falhas de autorização (CWE-285/288). Nada disso tem a ver com a forma como você escreve componentes.

QO que vale mais a pena mudar?

Quatro coisas: (1) parar de depender só do middleware para autorização — contornos já foram publicados repetidas vezes; (2) usar allow-list para os destinos de saída da otimização de imagens, do fetch no servidor e dos rewrites; (3) manter os endpoints de Server Actions e RSC atrás de autenticação e de limites de taxa; (4) transformar a atualização num sistema, não numa intenção. O item 1 é o mais importante, porque o mesmo tipo de contorno apareceu tanto em 2025 quanto em 2026.