Radar Tech: Um RCE crítico no Next.js, um runtime que escapa e o dia em que a arquitetura virou o controle

O resumo do dia em uma linha

Em 22 de setembro de 2026 o time do Next.js publicou uma correção fora de banda para um problema de execução remota de código de severidade crítica na implementação do ImageResponse (next/og) em runtime Node.js — e, no mesmo dia, ficou claro por que a resposta correta a um CVE crítico é metade segurança, metade arquitetura.

O que aconteceu, em fatos

O aviso é curto e vale ler com atenção cirúrgica, porque quase todo o valor da triagem está nas exclusões de escopo:

• Impacto: execução remota de código na implementação do ImageResponse em runtime Node.js (next/og). Severidade declarada: crítica.
• Versões afetadas: >=16.2.0 <16.3.6.
• Correções: 16.3.6 (LTS ativo) corrige; 15.5.26 (LTS de manutenção) recebe endurecimento relacionado, mas o próprio advisory afirma que a linha 15.x não é afetada pelo problema de RCE.
• Mecânica declarada: escape impróprio na saída SVG gerada pela biblioteca Satori, sob condições específicas, combinado com vulnerabilidades em outras dependências upstream. A correção eleva essas dependências.
• Exclusão declarada: aplicações que usam a implementação de ImageResponse no runtime edge não são afetadas.
• Referências: GHSA‑vcvr‑r3jv‑pc5j (local) e GHSA‑wx4j‑mvx‑mqwp (upstream, Satori).

Os comandos oficiais são um bump de versão: npm install next@16.3.6 na linha 16.3, e npm install next@15.5.26 na linha 15.5 — este último por endurecimento, não por exposição ao RCE.

Por que isso é um problema de arquitetura, não só de patch

Três detalhes transformam esse aviso em uma aula de arquitetura:

1. A dependência afetada é transitiva. O componente que falha é uma biblioteca de normalização abaixo do topo do manifesto. Um time que faz a triagem lendo só o package.json pode concluir — errado — que não está exposto. A primeira consulta de qualquer triagem séria é no grafo resolvido, não no manifesto declarado.

2. O runtime divide o blast radius. O advisory exclui explicitamente o runtime de borda. Isso não é um detalhe de implementação: é a diferença entre um incidente e um e-mail. Quem não lê a exclusão trata "todos os deployments estão em risco" e dispara um pânico que custa credibilidade — e a credibilidade é o recurso mais escasso de um time de segurança.

3. "Atualize a versão" não é uma resposta completa. É a resposta correta, mas incompleta. Ela não diz quem faz, em quanto tempo, como se prova que funcionou, nem o que impede a classe do defeito de voltar. Uma falha de escape na geração de saída é uma classe — ela vai reaparecer em outro renderizador, em outra linguagem, em outro framework.

A resposta em quatro fases que eu defendo

Depois de errar o suficiente nesse tipo de incidente, o formato que sobrevive ao plantão é este:

• H0 (0–4h) — conter. Não é "corrigir". É reduzir exposição ativa com uma decisão reversível: desabilitar a rota afetada para entrada não verificada via feature flag, com degradação para um caminho seguro. Verificação objetiva: o uso da rota vulnerável vai a zero no painel.
• H1 (24h) — corrigir. Bump para a versão exata, varredura do grafo completo antes e depois, deploy canário obrigatório quando o rollback é lento. Três provas: prova de grafo, prova de runtime (a versão implantada, não a do repositório) e prova de sinal (24h sem erro de escape).
• H2 (7d) — corrigir a classe. Teste adversarial de escape no CI, SBOM no pipeline, revisão de todo outro renderizador servidor que aceite texto de terceiro. A pergunta é uma só: se esse aviso nunca tivesse existido, qual controle permanente teria impedido a classe inteira?
• H3 (30d) — institucionalizar. Política: nenhum renderizador servidor compila template de terceiro sem camada de escape própria. Lint arquitetural para fazer a política valer.

E, atravessando as quatro fases, um ADR — porque a decisão precisa sobreviver à rotação de plantão e ao comitê de risco.

O que um agente de IA erra aqui (e por que isso importa para quem compra prompts)

Pedir a um LLM que responda a esse aviso produz, tipicamente, um relatório plausível e inútil: ele inventa o intervalo de versões afetadas, ignora a exclusão do runtime de borda, recomenda desabilitar um controle de segurança "temporariamente" e — no pior cenário — escreve um esboço de PoC. Nada disso é um problema do modelo; é um problema de empacotamento de contexto. Sem guardrails explícitos, sem few-shot de caso difícil e sem critério de aceite, a saída é confiante em vez de correta.

Foi exatamente por isso que o pacote publicado hoje na ArchPrompts — Pacote Next.js RCE (CVE‑2026‑94545): Triagem, ADR de Mitigação e Resposta a Incidente em 6 Arquivos — separa persona, guardrails, domínio, harness de verificação e operação em arquivos distintos. Seis arquivos fazem o que um parágrafo não faz: tornam a resposta auditável. Cada afirmação precisa de lastro, cada mitigação precisa de dono/prazo/verificação, e existe um formato de erro obrigatório para quando o modelo simplesmente não sabe.

O outro lado do radar: quando a atualização é o incidente

Vale guardar o contraste do mesmo dia. Enquanto um aviso de segurança pedia pressa, uma fabricante de eletrodomésticos pausou a distribuição de uma atualização de software porque refrigeradores conectados pararam de funcionar — com relatos de perda de alimentos. É o mesmo problema de arquitetura visto pelo avesso: uma atualização é uma mudança de produção, mesmo quando o artefato é uma geladeira.

Retenha a regra que serve para os dois casos: deploy sem caminho de reversão e sem sinal de verificação é aposta, não engenharia. Se o seu serviço tem rollback em minutos, o canário é uma formalidade; se não tem, ele é a diferença entre um incidente curto e uma madrugada longa.

Para levar

• Leia a exclusão de escopo de um advisory antes do impacto declarado — ela normalmente é a informação mais acionável do texto.
• Triage dependência no grafo, nunca no manifesto de topo.
• Separe severidade declarada de severidade prática: um serviço interno com entrada estática e um serviço público com entrada de terceiro no mesmo intervalo de versões não são o mesmo incidente.
• Toda resposta precisa de uma medida de contenção e uma de detecção, não só de correção.
• Termine com o controle permanente. O próximo CVE da mesma classe já está no seu grafo.

Radar Tech é o resumo diário da ArchPrompts sobre notícias de tecnologia traduzidas para decisões de arquitetura de software.