1. Visão Geral da Vulnerabilidade

Nos últimos dias, uma vulnerabilidade de RCE por desserialização no React tem causado alvoroço, com a CVSS oficial atribuindo uma pontuação máxima de 10,0, igualando-se ao Log4j da época. Imediatamente, espalharam-se rumores de que se tratava do "Log4j do frontend moderno", causando pânico entre desenvolvedores de várias empresas. Assim, ao acordar, todos começaram a pesquisar documentação e aplicar patches... Simultaneamente, também surgiram muitas vozes de dúvida online. Alguns testaram e descobriram que a vulnerabilidade não era tão grave como se propagava; pelo contrário, a exploração exigia certas condições. Por isso, decidi dedicar algum tempo para estudar a fundo esta vulnerabilidade.

1.1 Informações da Vulnerabilidade

• ID CVE: CVE-2025-55182
• Pontuação CVSS: 10.0 (Crítica)
• Tipo de Vulnerabilidade: Poluição de protótipo → Execução Remota de Código
• Versões Afetadas: react-server-dom-webpack < 19.2.0, react-server-dom-turbopack < 19.2.0
• Escopo de Impacto: Aplicações que usam React Server Components

---

2. Análise do Princípio da Vulnerabilidade

2.1 Causa Raiz da Vulnerabilidade

A causa desta vulnerabilidade é a seguinte: no [email protected], a função chave do servidor para analisar Server Actions é requireModule (pseudocódigo):

function requireModule(metadata) {
  var moduleExports = __webpack_require__(metadata[0]);
  // ...
  return "*" === metadata[2]
    ? moduleExports
    : "" === metadata[2]
      ? moduleExports.__esModule
        ? moduleExports.default
        : moduleExports
      : moduleExports[metadata[2]];  // ← Ponto vulnerável
}

2.2 Problema Central da Vulnerabilidade

O núcleo do problema está na parte moduleExports[metadata[2]], que não valida o metadata[2]. Isso permite que o invasor não apenas acesse as propriedades exportadas pelo próprio módulo, mas também propriedades na cadeia de protótipos (como constructor, __proto__, etc.). Quando o invasor manipula metadata[0] (por exemplo, apontando-o para vm), ele pode então manipular metadata[2] para exportar métodos perigosos de módulos específicos, como vm.runInThisContext, resultando na exploração da vulnerabilidade.

---

3. Análise de Exploração da Vulnerabilidade

Na minha análise, consultei o ambiente de teste e a exploração fornecidos por ejpir, usando como exemplo o gadget vm_runInThisContext para executar código. O processo é o seguinte (nota: em ambientes reais, o processo de exploração pode ter diferenças!):

Passo 1: Receber a Solicitação

Primeiro, após enviar uma solicitação com o payload, defino um ponto de interrupção no local onde a solicitação é recebida:

Passo 2: Analisar os Dados do Formulário

Em seguida, o programa executa até const formData = parseMultipart(buffer, boundaryMatch[1]);. Entro em parseMultipart

parseMultipart extrai os dados do corpo da solicitação e os retorna para formData

Passo 3: Chamar decodeAction (Entrada da Vulnerabilidade)

Entro em const actionFn = await decodeAction(formData, serverManifest); Local onde a vulnerabilidade é gerada

Entro em loadServerReference

Passo 4: Código Principal da Vulnerabilidade requireModule

Agora chegamos ao código principal onde a vulnerabilidade é gerada, requireModule. Entro

Retorna o valor id com o # como separador entre módulo e método, e o valor do parâmetro bound como argumento do método

Passo 5: Executar o Payload

Entro em actionFn e executo o payload final

A exploração da vulnerabilidade está concluída!

---

4. Resumo e Defesas

Esta vulnerabilidade, em si, ainda é causada por validação insuficiente de entrada, exatamente como Log4j e fastjson. No teste acima, usei vm_runInThisContext, mas na verdade existem múltiplos gadgets exploráveis para esta vulnerabilidade, como:

• vm#runInThisContext
• vm#runInNewContext
• child_process#execSync
• child_process#execFileSync
• child_process#spawnSync
• fs#readFileSync
• fs#writeFileSync
• #constructor
• #__proto__
• #prototype

O invasor pode usar esta vulnerabilidade para conseguir:

• Execução Remota de Código (RCE): Através de vm#runInThisContext ou child_process#execSync para executar comandos arbitrários do sistema
• Operações no Sistema de Arquivos: Através de fs#readFileSync, fs#writeFileSync para ler/escrever arquivos arbitrários
• Ataques de Persistência: Escrever chaves públicas SSH, modificar .bashrc, sobrescrever arquivos da aplicação, etc.
• Vazamento de Informações: Ler arquivos de configuração sensíveis (.env, chaves privadas, credenciais de banco de dados, etc.)

Com base nisso, podemos fornecer as seguintes medidas de defesa:

1. Defesa Temporária

Para defesa temporária, podemos considerar os seguintes ângulos: configurar regras de bloqueio para esses campos perigosos no WAF para interceptar ataques maliciosos em tempo hábil. Além disso, também podemos fazer correspondência e bloqueio no Nginx, como abaixo:

# Exemplo de configuração Nginx
location /formaction {
    # Bloquear solicitações que contenham referências a módulos perigosos
    if ($request_body ~* "(vm#|child_process#|fs#|module#)") {
        return 403;
    }
    # Bloquear tentativas de poluição de protótipo
    if ($request_body ~* "(#constructor|#__proto__|#prototype)") {
        return 403;
    }
}

2. Atualizar o Mais Rápido Possível

A equipe oficial já lançou uma atualização de segurança. Atualize imediatamente para a versão segura!:

# Atualizar react-server-dom-webpack
npm install react-server-dom-webpack@>=19.2.0

# Atualizar react-server-dom-turbopack
npm install react-server-dom-turbopack@>=19.2.0