Vulnerabilidade Next.js: como priorizar os 13 alertas de maio de 2026

O cenário em uma frase — e a triagem que realmente importa

Em 6 de maio de 2026, o Next.js divulgou 13 alertas de segurança coordenados e, no dia 7, lançou as versões corrigidas 16.2.6 e 15.5.18. A imprensa correu para cobrir a CVE-2026-44578, a SSRF via WebSocket, porque a imagem chama atenção: um invasor faz o upgrade de uma conexão, leva o servidor a acessar 169.254.169.254 e recebe do endpoint de metadados as credenciais IAM. É dramático.

Mas também é um problema exclusivo de ambientes self-hosted. Em um deploy gerenciado pela Vercel, com a Cloudflare à frente, esse caminho não é alcançável. O alerta que pode chegar aos meus leitores é o de gravidade Moderada sobre cache poisoning em RSC, sobre o qual ninguém está postando: uma resposta RSC envenenada não fica restrita à requisição do invasor — ela entra no meu cache de borda compartilhado e passa a ser entregue a todos os visitantes até que eu invalide a tag.

Quem roda qualquer versão do Next.js >= 13.4.13 precisa fazer a atualização ainda esta semana. As únicas perguntas são para qual versão, em que ordem e o que precisa ser testado novamente depois. A triagem abaixo é a matriz que apliquei ao omidsaffari.com — App Router na Vercel, Cloudflare à frente, purge por Cache-Tag e um webhook de revalidação — e mostra por que deixei de priorizar a CVE das manchetes.

O que isso significa para fundadores sem perfil técnico

Se o seu produto é uma aplicação Next.js, este é um item para resolver nesta semana, não um ticket para o backlog. O custo não deve ser medido em latência ou horas de desenvolvimento: uma página envenenada no cache ou uma rota administrativa que teve a autenticação contornada vira um incidente de confiança do cliente. Basta uma captura da sua página de marketing exibindo conteúdo de um invasor ou um relato de acesso a /admin sem sessão para que a semana seguinte seja gasta dando explicações, não vendendo.

Faça uma única pergunta à equipe de engenharia: "Estamos na 16.2.6 ou na 15.5.18 e fizemos o purge do cache de borda depois do deploy?" Se a resposta for mais vaga do que isso — "estamos aplicando o patch", "está em andamento", "a SSRF não nos afeta" — o trabalho ainda não terminou. Ambientes self-hosted (ECS, EC2, Kubernetes ou qualquer servidor sob sua responsabilidade executando next start) estão na faixa de maior risco, pois ficam expostos à SSRF e a todas as outras falhas. Pergunte em qual grupo sua aplicação está. A resposta deve levar dez segundos.

Os 13 alertas, classificados pelo alcance na sua stack

O erro de todos os posts do tipo "13 CVEs, atualize agora" que estão circulando é tratar a lista como se fosse uniforme. Não é. Cada alerta depende de uma condição — self-hosted, Turbopack, Cache Components, nonces de CSP, i18n — e a sua exposição real corresponde apenas ao subconjunto compatível com o seu deploy. Abaixo, os mesmos 13 alertas estão agrupados pelas condições necessárias para serem explorados.

Grupo de bypass de middleware e proxy (5 alertas, a maioria de gravidade Alta). O principal é o GHSA-267c-6grr-h53f, que permite a uma URL de segment prefetch do App Router passar por uma rota sem cumprir as verificações de autenticação do middleware. O grupo também inclui a correção complementar publicada em 7 de maio (GHSA-26hh-7cqf-hhc6), necessária porque a primeira era incompleta no Turbopack; um bypass do caminho de locale padrão do i18n no Pages Router; e um bypass por injeção de parâmetros em rota dinâmica. Pré-condição: usar middleware do Next.js para impor autenticação ou rewrites. Quase todo mundo usa.

SSRF, CVE-2026-44578. O handler de upgrade de WebSocket do servidor self-hosted alcança endpoints HTTP internos na porta 80, inclusive os metadados da nuvem. Versões afetadas: da 13.4.13+ até versões <15.5.16 e da 16.0.0 até versões <16.2.5, apenas em self-hosted. Está confirmado que deploys gerenciados pela Vercel não são afetados.

Negação de serviço, dois alertas. Um é o DoS upstream do RSC; o outro é um DoS por esgotamento de conexões em aplicações que habilitaram Cache Components (gravidade Alta, GHSA-q4gf-8mx6-v5v3). Pré-condição do segundo: ter habilitado Cache Components explicitamente — a maioria das aplicações não fez isso.

Cache poisoning em RSC (gravidade Moderada). Colisões no mecanismo de cache busting do pipeline de payloads RSC permitem que uma requisição criada para explorar a falha envenene uma resposta em cache. Pré-condição: manter respostas RSC em cache em qualquer ponto posterior — CDN, proxy reverso, edge da Vercel ou Cloudflare. É este que importa na minha stack.

XSS, dois alertas. A CVE-2026-44581 (gravidade Moderada) afeta aplicações com App Router que geram nonces de CSP; há também um XSS em scripts beforeInteractive que consomem entrada não confiável. Pré-condições: entregar uma CSP com nonces ou passar dados de usuário para uma tag de script beforeInteractive.

Anote quais dessas pré-condições estão presentes no seu deploy. Essa é a sua lista real. No omidsaffari.com, o cenário é: grupo de bypass de middleware (sim), SSRF (não, hospedado na Vercel), DoS de RSC (sim, upstream), DoS de Cache Components (não, recurso não habilitado), cache poisoning em RSC (sim, e amplificado), XSS por nonce de CSP (sim), XSS em beforeInteractive (não). Oito alertas de gravidade Alta ou Moderada viram cinco aplicáveis ao meu caso — e a falha com o maior raio de impacto não é a famosa.

Por que a vulnerabilidade Next.js das capturas provavelmente não é o seu problema — mas o cache poisoning é

A CVE-2026-44578 depende de o servidor next start no lado do Node processar o upgrade do WebSocket e seguir o redirecionamento. A Vercel não encaminha minhas requisições por esse servidor de modo que deixe o caminho da SSRF alcançável: a plataforma encerra as conexões WebSocket, e o endpoint de metadados fica atrás do IMDSv2, com um limite de saltos que também não sobreviveria ao percurso. Colocar a Cloudflare à frente não muda essa conclusão. Em uma topologia Vercel + Cloudflare, a captura dramática não se materializa.

Com o alerta de cache poisoning em RSC, a lógica se inverte por completo. A vulnerabilidade está no caminho de processamento percorrido por todas as requisições, e o resultado é um payload RSC envenenado — isto é, a árvore React serializada que os leitores recebem. No meu site, esse payload não fica limitado à requisição do invasor. Ele chega aqui:

Cache-Control: public, s-maxage=300, stale-while-revalidate=86400
Cache-Tag: article:nextjs-may-2026-security-triage

s-maxage=300 significa que a Cloudflare mantém essa resposta por cinco minutos. stale-while-revalidate=86400 significa que ela continua servindo a resposta por um dia depois de expirar, enquanto faz a revalidação em segundo plano. A Cache-Tag é meu mecanismo de purge: quando publico uma nova revisão, o webhook de revalidação dispara a invalidação da tag e o objeto é removido.

Veja o que acontece com uma resposta envenenada. O invasor acessa uma rota que explora a colisão no cache busting. A Cloudflare identifica uma resposta que pode ser armazenada em cache, salva o objeto usando a chave de cache daquela URL e aplica a tag article:<slug>. A partir daí, todo visitante daquele slug recebe da borda o payload RSC envenenado — não da origem, sem passar por middleware e sem chegar a nenhuma regra de WAF que eu venha a criar dez minutos depois. O objeto contaminado já está depois da origem. E permanece lá até a janela de s-maxage expirar ou até meu pipeline de publicação disparar um purge. Regras de WAF na origem não fazem nada por uma resposta que já está em 300 PoPs.

Por isso, o ativo em risco é a superfície de conteúdo publicado — a saída do mecanismo de conteúdo —, não uma API interna. A lista de 13 alertas classifica a SSRF como de gravidade Alta e esta falha como Moderada. Em um site RSC com cache à frente, a ordem do impacto prático se inverte.

Como fazer a atualização — inclusive evitando a armadilha da correção complementar do Turbopack

Primeiro, descubra qual versão está efetivamente instalada. O package.json não revela a versão resolvida quando há um intervalo com circunflexo; confira o lockfile.

bun pm ls | grep next
# or
npm ls next

Depois, fixe a versão em 16.2.6 (linha Next.js 16) ou 15.5.18 (linha Next.js 15). Não use a 16.2.5. Nem a 15.5.16.

bun add next@16.2.6
# or
npm install next@16.2.6 --save-exact

Há uma armadilha pouco mencionada que justifica fixar a versão exata. Os 13 alertas originais foram corrigidos nas versões 16.2.5 / 15.5.16 em 6 de maio. No dia 7, a Vercel publicou o GHSA-26hh-7cqf-hhc6 — uma correção complementar porque o bypass de middleware por segment prefetch continuava explorável quando a requisição era servida pelo Turbopack. Quem não usava Turbopack estava protegido nas versões 16.2.5 / 15.5.16; quem usava, não. A correção completa está nas versões 16.2.6 / 15.5.18.

Para quem ainda está nas linhas 13.x ou 14.x, não haverá patch. A Vercel não fará backport. A correção exige migrar para a 15.x ou a 16.x, e o trabalho deve ser dimensionado como uma migração, não como um bun update. Reserve no mínimo uma semana se a aplicação não for trivial: a superfície de breaking changes é real, principalmente nos matchers de middleware e nos padrões de cache do App Router.

Depois que o deploy entrar no ar, faça o purge do cache de borda. Esta é a etapa ausente em todos os outros textos que li nesta semana. Sem o purge, qualquer payload RSC armazenado pela Cloudflare antes da aplicação do patch continua lá — e pode estar envenenado caso alguém tenha explorado a falha durante essa janela —, sendo servido pela borda até o fim do s-maxage. Na minha stack:

curl -X POST "https://api.cloudflare.com/client/v4/zones/$ZONE/purge_cache" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"purge_everything": true}'

Em seguida, valide o resultado. Escolha uma rota protegida por autenticação no middleware, monte o formato de URL de segment prefetch descrito no alerta e reproduza a requisição em produção. A resposta deve ser 401, 302 ou o status retornado pelo seu middleware para uma requisição sem autenticação. Se vier 200 com conteúdo, o patch do middleware não entrou em vigor: o problema está no deploy, não no Next.js.

O que quebrou na 16.2.6 — sem maquiar a realidade

A realidade é que essas versões não são apenas patches de segurança. Várias correções alteram deliberadamente o roteamento e o comportamento das chaves de cache, pois as vulnerabilidades estavam justamente nesses pontos. Portanto, espere diferenças.

Matchers de middleware mais rigorosos para URLs .rsc e de segment prefetch. A correção do bypass por segment prefetch mudou o comportamento dos matchers. Se algum padrão dependia do formato anterior — principalmente ao usar um negative lookahead para excluir caminhos _next e presumir que .rsc sempre apareceria abaixo deles —, valide tudo outra vez. Precisei ampliar um matcher para capturar explicitamente o sufixo de segment prefetch em uma rota protegida. Foi uma correção de cinco minutos, mas teria virado uma regressão silenciosa sem o teste por replay.

Tratamento de nonce de CSP. A correção de XSS (CVE-2026-44581) muda a forma como os nonces se propagam durante a renderização do App Router. Se você gera nonces no middleware e os referencia em um componente Script, mantenha a CSP no modo report-only por um dia depois do deploy. Não encontrei nenhuma violação, mas a mudança é real — e soube de uma equipe que precisou atualizar seu fluxo de geração de nonces.

Mudança de comportamento em Cache Components. Para quem usa Cache Components e, portanto, está no caminho da correção do DoS por esgotamento de conexões, o patch muda a forma como cache misses são agrupados sob carga. Teste novamente os caminhos críticos. Não uso Cache Components, então essa parte não se aplicou a mim.

O checklist de validação que executei antes de considerar a atualização concluída:

[ ] next version pinned to 16.2.6 in lockfile
[ ] middleware auth replay on /admin via segment-prefetch URL → 401
[ ] middleware auth replay via .rsc URL → 401
[ ] RSC cache key sanity: same URL, two clients, identical payload
[ ] forced edge purge after deploy
[ ] CSP report-only on for 24h with no new violations
[ ] one full revalidate cycle on a high-traffic page

Inclua uma passagem pelo ambiente de staging. Este não é um patch de baixo risco, pois as correções de segurança alteram deliberadamente o comportamento do roteamento e das chaves de cache. O que separa um deploy na tarde de terça-feira de um incidente na noite do mesmo dia é ter repetido os testes dos caminhos de autenticação antes de virar a produção.

Aplique o patch, não dependa do WAF — e entenda a lição estrutural

A Vercel não publicou regras de WAF para esta versão. O changelog afirma que aplicar o patch é a única mitigação completa — e está correto: nenhum desses alertas pode ser filtrado de forma confiável na borda, pois os formatos das requisições maliciosas se confundem demais com os legítimos. Em 6 de maio, a Cloudflare publicou regras de WAF e mitigações nos adaptadores de framework como defesa em profundidade, não como substitutas da atualização. A escolha das palavras importa: o changelog da Cloudflare diz claramente que as regras de WAF reduzem a exposição durante a janela de rollout, não depois dela.

Essa diferença é a lição estrutural da semana. Uma stack capaz de atualizar um framework, refazer o deploy e invalidar o cache de borda em uma única tarde transforma a divulgação coordenada de 13 CVEs em uma tarefa de terça-feira. Uma stack que não consegue fazer isso — porque a atualização exige uma migração, porque não existe um mecanismo de purge ou porque o pipeline de deploy tem gates manuais — permanece exposta durante todo o rollout. Dias. Às vezes, semanas.

É o mesmo padrão do argumento sobre o raio de impacto de agentes: uma estrutura preparada para recuperação rápida vence a filtragem reativa. Não é possível impedir toda requisição maliciosa nem toda chamada inadequada de um agente. O objetivo é construir o sistema para que, quando isso ocorrer, a resposta seja medida em minutos e o raio de impacto fique limitado pela topologia, não pela esperança.

Faça a atualização hoje à noite. Fixe a versão em 16.2.6 ou 15.5.18. Depois, faça o purge do cache. A CVE da captura de tela é a preocupação errada; o alerta de gravidade Moderada que alcança todas as páginas em cache é o que realmente importa.