CVE-2026-94545

01Sumário executivo

O CVE-2026-94545 é uma falha de execução remota de código sem autenticação no next/og, o componente do Next.js que gera imagens de compartilhamento social (Open Graph) [1] [2]. A Vercel, mantenedora do Next.js, atribuiu ao problema uma pontuação CVSS v4 de 9.5, com exploração pela rede, baixa complexidade, sem autenticação e sem interação do usuário [2] [5]. A raiz é um defeito de escape de saída (CWE-116) na biblioteca Satori, que compõe o SVG a partir do JSX; a consequência, na configuração vulnerável, é a execução de comandos no servidor [1] [4].

A exploração encadeia quatro etapas [1]. Primeiro, a injeção de SVG: o texto do atacante fecha o elemento onde deveria ficar contido e insere marcação própria. Segundo, o alcance do parser nativo: com a biblioteca sharp instalada, o SVG é processado por libvips, librsvg e libxml2, e não pelo renderizador seguro em WebAssembly. Terceiro, a corrupção de memória: uma referência XInclude combinada com entidades DTD aninhadas corrompe a memória dentro do analisador. Quarto, o controle de execução: como o binário oficial do Node.js não é compilado como PIE (Position-Independent Executable), seus endereços de código são fixos, e uma cadeia ROP (Return-Oriented Programming) predefinida chama execve sem precisar descobrir endereço nenhum [1].

O impacto é execução de comandos com os privilégios do processo do servidor Next.js [1] [2]. O ataque é cego: ao ter sucesso, o comando substitui o processo trabalhador, então a resposta HTTP simplesmente encerra e o resultado precisa voltar por outro caminho, como um shell reverso [1]. O mesmo efeito derruba o trabalhador, e o servidor para de responder até ser reiniciado [1]. Como os endereços do binário do Node são estáveis, não há necessidade de vazamento nem de força bruta por alvo [1].

A correção definitiva é atualizar para Next.js 16.3.6 (com Satori 0.33.5 ou superior), que escapa o texto do SVG na serialização e fecha a injeção [1] [2]. As versões da linha 15.x do Next.js não são afetadas pela execução remota de código [2]. Este relatório inclui, na seção 7, a verificação de que a plataforma CiberLab não está exposta a essa falha.

02Identificação do objeto analisado

03Contexto técnico: do JSX ao pixel

Imagens Open Graph são as pré-visualizações que aparecem quando um link é compartilhado em uma rede social ou aplicativo de mensagens [2]. O Next.js oferece o next/og para gerá-las dinamicamente: o desenvolvedor descreve a imagem como se fosse um componente, em JSX, e o framework a transforma em uma imagem PNG [1] [2]. Essa conversão passa por três estágios, e a falha nasce na costura entre o segundo e o terceiro.

3.1Satori: de JSX para SVG

O primeiro estágio é o Satori, biblioteca da Vercel que converte a estrutura JSX (ou semelhante a HTML) em um documento SVG [1] [2]. É aqui que o texto fornecido pelo desenvolvedor, e eventualmente pelo usuário, é escrito dentro dos elementos do SVG [1]. O defeito está justamente neste ponto: o Satori não escapa esse texto ao serializá-lo (CWE-116) [1] [4].

3.2Os dois rasterizadores: WebAssembly isolado ou nativo

O segundo estágio transforma o SVG em pixels, a rasterização, e o Next.js tem dois caminhos possíveis para isso [1]:

1. Caminho isolado: no runtime Edge, ou quando a biblioteca sharp não está instalada, a imagem é rasterizada pelo resvg compilado em WebAssembly. É um ambiente isolado (sandbox), no qual uma injeção de SVG não escapa para o sistema [1].
2. Caminho nativo: no runtime Node.js com a biblioteca sharp instalada, o Next.js entrega o SVG a bibliotecas nativas do sistema, a libvips, que aciona a librsvg e, por baixo dela, a libxml2 [1]. Esse é o caminho vulnerável, porque essas bibliotecas em C não têm o isolamento do WebAssembly e processam recursos avançados de XML [1].

3.3libxml2 e os recursos perigosos de XML

SVG é XML, e o analisador libxml2 implementa recursos poderosos da especificação XML que, num contexto de segurança, são armadilhas [1]. Dois importam aqui: as entidades DTD (Document Type Definition), que permitem definir abreviações expansíveis dentro do documento, e o XInclude, que permite a um documento XML incluir o conteúdo de outro [1]. Quando o atacante controla a marcação SVG que chega a essa biblioteca, ele controla também o uso desses recursos, e é a combinação deles que corrompe a memória do analisador [1].

04Mecanismo da vulnerabilidade e causa raiz

A falha não é um único bug, mas uma cadeia em que cada elo só é alcançável porque o anterior falhou [1]. Esta seção percorre a causa raiz; a seção 5 mostra a exploração concreta.

4.1Causa raiz: texto sem escape vira marcação

Quando o Satori serializa o SVG, o texto do usuário é inserido verbatim dentro de um elemento, por exemplo um <title> [1]. Sem o escape, os caracteres < e > do texto do atacante são interpretados como marcação, e não como conteúdo textual [1] [4]. Isso permite ao atacante encerrar prematuramente o elemento que o continha e escrever elementos SVG inteiramente novos, controlados por ele [1]. É o equivalente, no mundo do SVG, de uma injeção clássica: o dado ultrapassa a fronteira que deveria contê-lo e vira código de marcação.

4.2O papel decisivo do runtime e da biblioteca sharp

A injeção de SVG, por si só, seria de baixo impacto se o SVG resultante fosse desenhado pelo renderizador isolado em WebAssembly [1]. O que eleva a falha à execução de código é a presença simultânea de duas condições: a rota rodar no runtime Node.js e a biblioteca sharp estar instalada [1] [2]. Juntas, elas desviam a rasterização para o caminho nativo (libvips, librsvg, libxml2), onde a marcação injetada é processada por código em C sem isolamento [1].

4.3A corrupção de memória no analisador nativo

Com o SVG malicioso alcançando a libxml2, o atacante monta uma estrutura que combina uma referência XInclude a um documento externo com entidades DTD aninhadas, cujo conteúdo se expande de forma controlada [1]. O processamento dessa estrutura corrompe a memória dentro do analisador nativo [1]. A prova de conceito da EQSTLab calibra o tamanho exato dessa expansão (com valores de preenchimento fixos) para dispor a memória de maneira previsível, um trabalho que depende das versões precisas das bibliotecas nativas [1].

4.4O binário não-PIE do Node e a cadeia ROP

Corromper a memória não basta: é preciso converter essa corrupção em controle da execução [1]. Aqui entra uma propriedade do próprio Node.js: o binário oficial distribuído pelo projeto não é compilado como PIE, ou seja, seu código não é carregado em endereços aleatórios (não há ASLR sobre a imagem principal) [1]. Isso torna os endereços das instruções, as gadgets, fixos e conhecidos para cada versão do Node [1].

Com endereços fixos, o atacante monta previamente uma cadeia ROP: uma sequência de endereços que reaproveita trechos do próprio binário para, passo a passo, montar uma chamada de sistema execve e executar um comando [1]. Como nada precisa ser descoberto em tempo de execução, não há necessidade de um vazamento de endereço nem de força bruta, e o mesmo payload funciona em qualquer host com aquela mesma compilação do Node [1].

05A cadeia de exploração completa

A prova de conceito da EQSTLab reúne os elos numa única requisição HTTP contra a rota de imagem [1]. Esta seção mostra o formato do ataque e o comportamento observável, sem reproduzir a cadeia ROP em si.

5.1A rota vulnerável do laboratório

O laboratório expõe uma rota que reproduz a configuração vulnerável: runtime Node.js e a entrada da requisição indo direto para um elemento de texto do SVG [1]. O trecho central é este:

export const runtime = 'nodejs'

// A entrada nao autenticada do usuario vai direto para o texto do SVG.
const value = request.method === 'POST'
  ? await request.text()
  : (url.searchParams.get('value') ?? '')
return new ImageResponse(
  <svg width="1200" height="630"><title>{value}</title></svg>,
  { width: 1200, height: 630 }
)

O valor de value, vindo do corpo da requisição ou da query string, é escrito no <title> do SVG sem qualquer tratamento [1]. É o ponto exato onde a injeção descrita na seção 4.1 acontece.

5.2Formato da requisição

O exploit envia uma requisição POST /api/og com o corpo em texto simples [1]. Esse corpo, do ponto de vista da estrutura, faz três coisas: fecha o elemento de texto onde a entrada foi colocada, insere uma referência XInclude que aponta para um documento SVG malicioso (embutido como URL de dados), e reabre o elemento para manter o SVG bem formado [1]. O documento referenciado, por sua vez, carrega as entidades DTD aninhadas e a estrutura calibrada que dispara a corrupção [1]. A cadeia ROP é codificada dentro de um elemento <path>, cujas coordenadas numéricas representam os endereços das gadgets [1].

06Condições de exposição e impacto

6.1Quando uma aplicação está exposta

Nem toda aplicação Next.js está vulnerável. As quatro condições precisam valer ao mesmo tempo [1] [2]:

6.2Impacto

Onde as condições valem, o impacto é máximo [1] [2]:

1. Execução de código sem autenticação: rotas de imagem OG são públicas por natureza, porque os rastreadores de redes sociais precisam alcançá-las sem login. O atacante executa comandos com os privilégios do processo do servidor [1] [2].
2. Comprometimento do servidor: a partir da execução de comandos, o atacante lê os segredos que o processo da aplicação pode ler, alcança variáveis de ambiente e credenciais, e pode buscar persistência [1] [2].
3. Negação de serviço: mesmo uma tentativa que apenas derruba o trabalhador interrompe o atendimento da aplicação até o reinício [1].
4. Payload estável e reutilizável: como os endereços do binário do Node são fixos, o mesmo payload atinge qualquer host com a mesma compilação, o que favorece exploração em escala [1].

07Verificação: o CiberLab não é afetado

A plataforma CiberLab é construída em Next.js, então foi verificada diretamente contra as condições da tabela 3. A conclusão é que a plataforma não está vulnerável ao CVE-2026-94545, e por mais de um motivo independente [1] [2].

Recomenda-se manter essa postura em futuras evoluções da plataforma: se algum dia uma imagem Open Graph dinâmica for desejada, ela deve usar o runtime Edge (export const runtime = 'edge') ou escapar rigorosamente qualquer dado de usuário antes de compor a imagem, e a versão do Next.js deve permanecer atualizada [1] [2].

08Detecção

A detecção vai da inspeção mais barata (a requisição na borda) para a mais cara (a atividade posterior no host) [1]. O padrão da requisição de exploração é distintivo e não aparece em uso legítimo de uma rota de imagem [1].

8.1Assinatura da requisição

Uma requisição legítima a uma rota next/og é curta e não carrega marcação XML no corpo [1]. A requisição de exploração, ao contrário, tem um corpo grande, de dezenas de milhares de bytes, que contém marcação SVG, referências xi:include e URLs de dados data:image/svg+xml [1]. Esses três elementos juntos, numa requisição a uma rota de imagem, são um sinal de alta confiança.

8.2Regra Suricata para o tráfego HTTP

Para sensores que inspecionam o corpo HTTP antes da terminação TLS, a regra abaixo alerta um corpo grande com os marcadores da injeção em uma requisição a rota de imagem [1]:

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"CIBERLAB NEXTJS OG CVE-2026-94545 SVG INJECTION RCE ATTEMPT"; \
    flow:to_server,established; http.method; content:"POST"; \
    http.request_body; content:"xi:include"; nocase; content:"data:image/svg+xml"; nocase; distance:0; \
    content:"XInclude"; nocase; \
    classtype:web-application-attack; sid:1000120; rev:1; \
    reference:cve,2026-94545; reference:url,ciberlab.seg.br/reports/nextjs-og-rce;)

title: Tentativa de RCE no next/og do Next.js (CVE-2026-94545)
id: 86abcdef-012d-4c24-b514-795d346d6592
status: experimental
description: Detecta POST a rota de imagem OG com corpo grande e marcadores de injecao de SVG
author: Lucas Rayan Guerra (CiberLab)
references:
    - https://github.com/EQSTLab/CVE-2026-94545
    - https://github.com/vercel/next.js/security/advisories/GHSA-vcvr-r3jv-pc5j
logsource:
    category: webserver
detection:
    selection_method:
        cs-method: 'POST'
    selection_body:
        cs-body|contains:
            - 'xi:include'
            - 'data:image/svg+xml'
    condition: selection_method and selection_body
fields:
    - c-ip
    - cs-uri-stem
    - cs-bytes
    - sc-status
falsepositives:
    - Desconhecidos em rotas de imagem legitimas
level: high
tags:
    - attack.initial_access
    - attack.t1190
    - attack.execution
    - attack.t1059.004

8.4Sinais no host

No servidor, três observações confirmam o sucesso [1]. Reinícios inesperados ou quedas do trabalhador do Next.js logo após uma requisição à rota de imagem indicam a substituição do processo [1]. Um processo filho de shell (por exemplo bash ou sh) descendente do processo do Node é altamente anômalo em um servidor web e sugere execução de comando [1]. E uma conexão de saída do servidor para um endereço externo, sobretudo em porta não padronizada, é o traço do shell reverso [1]. Correlacione os três com o registro de acesso da rota de imagem.

09Mitigação e resposta a incidentes

9.1Correção definitiva

A solução completa é atualizar o Next.js para 16.3.6 ou superior (que traz o Satori 0.33.5 ou superior) e reimplantar [1] [2]. A correção escapa o texto do SVG ao serializá-lo, o que fecha a injeção na origem, antes de o SVG chegar a qualquer rasterizador [1].

9.2Mitigações enquanto a atualização não é aplicada

Se a atualização imediata não for possível, qualquer uma das medidas abaixo interrompe a cadeia [1]:

1. Mover a rota para o runtime Edge: declare export const runtime = 'edge' nas rotas next/og, para forçar o rasterizador isolado em WebAssembly [1].
2. Remover a biblioteca sharp: onde ela não for necessária, sua ausência já desvia a rasterização para o caminho seguro [1].
3. Sanitizar a entrada: mantenha dados não tratados do usuário fora dos filhos do ImageResponse; se algum texto de usuário precisar aparecer na imagem, escape-o rigorosamente antes [1].
4. Restringir o acesso e a saída: coloque as rotas de imagem atrás de autenticação ou de uma lista de permissão quando possível, e limite o tráfego de saída do servidor para dificultar a exfiltração cega [1].

9.3Resposta a um comprometimento

Se houver indício de exploração bem-sucedida, trate o servidor como comprometido [1]. Gire os segredos que o processo da aplicação podia ler (variáveis de ambiente, chaves de API, credenciais de banco e de serviços), procure mecanismos de persistência instalados pelo atacante, e reconstrua a instância a partir de uma imagem limpa em vez de tentar higienizá-la no lugar [1]. Reveja os registros de saída em busca de conexões para endereços externos após a requisição suspeita.

9.4Mapeamento de técnicas MITRE ATT&CK

IDs e nomes conferidos na base oficial do MITRE ATT&CK for Enterprise [6]:

10Indicadores de comprometimento

Os indicadores são de comportamento: o ataque usa requisições HTTP e não deposita um binário conhecido no servidor [1]. A tabela consolida os padrões a caçar na borda e no host [1].

11Limitações da análise

1. Ausência de detonação em laboratório próprio: o CiberLab não construiu nem executou o ambiente vulnerável, nem rodou o exploit. A descrição da causa raiz e da cadeia de exploração vem da prova de conceito publicada pela EQSTLab [1], e os metadados vêm de fontes abertas verificadas [2] a [5].
2. Detalhes de baixo nível não reproduzidos: este relatório descreve a cadeia ROP e a corrupção de memória em termos funcionais, sem reproduzir os endereços das gadgets, o layout exato da memória nem o payload. Esses detalhes são específicos da compilação do Node e das versões das bibliotecas nativas do laboratório [1].
3. Fonte primária de terceiros: a análise técnica se apoia na prova de conceito da EQSTLab [1]. As páginas do comunicado oficial da Vercel e da análise da Checkmarx estavam inacessíveis a partir do ambiente de produção deste relatório, e os seus dados foram confirmados por fontes secundárias de inteligência [2] [3] [4] [5].
4. Regras de detecção derivadas: as regras Suricata e Sigma da seção 8 foram deduzidas do padrão de exploração descrito na prova de conceito [1] e não foram testadas em produção. Homologue-as antes de qualquer uso em bloqueio; em particular, a inspeção do corpo HTTP exige que o sensor tenha visibilidade sobre o tráfego já decifrado.
5. Escopo da verificação do CiberLab: a verificação da seção 7 cobre o estado atual do código-fonte da plataforma na data de emissão. Mudanças futuras que introduzam rotas de imagem dinâmicas devem ser reavaliadas contra as condições da tabela 3.