CVE-2025-55182

Falha de deserialização insegura em React Server Components que permite execução remota de código sem autenticação, através de requisições HTTP manipuladas para endpoints de Server Function. Batizada de "React2Shell" pela comunidade, atinge não só apps que usam Server Functions explicitamente, mas qualquer aplicação que suporte RSC — inclusive Next.js 15.x/16.x com App Router — e já está sob exploração ativa por grupos ligados à China dentro de horas da divulgação.

A vulnerabilidade (deserialização insegura, CWE-502) está no código que traduz requisições HTTP recebidas em chamadas de função no servidor. Segundo análise técnica discutida publicamente, o deserializador resolve o nome do módulo/exportação enviado pelo cliente via um lookup direto (`moduleExports[metadata.name]`) sem validar que essa propriedade pertence de fato ao objeto (sem checagem de `hasOwnProperty`), permitindo que o atacante referencie qualquer identificador acessível no namespace do servidor, não apenas as funções explicitamente marcadas com `use server`.

O ponto crítico é que o mecanismo de RPC implícito criado pelo RSC trata o payload do cliente como índice direto para código executável no servidor, sem esquema, sem validação de superfície de API e sem exigir que o endpoint tenha sido explicitamente exposto pelo desenvolvedor. Isso significa que uma aplicação pode ser vulnerável mesmo sem implementar nenhum Server Function próprio — basta que o runtime RSC esteja presente e ativo no processo servidor.

O fornecedor (React Team/Meta) declarou que detalhes técnicos completos do mecanismo de exploração seriam divulgados somente após o rollout da correção estar concluído, então parte da mecânica exata (payload de deserialização, formato do wire protocol abusado) não foi publicada oficialmente — o que se sabe vem de análise da comunidade sobre o commit de correção.

O CVSS 10.0 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H) reflete corretamente a ausência de qualquer pré-condição de autenticação, interação do usuário ou configuração não padrão — a superfície vulnerável é o comportamento default do runtime RSC nas versões afetadas.

O vetor é uma requisição HTTP crafted enviada diretamente ao endpoint de Server Function exposto pela aplicação (a rota que o RSC usa para receber chamadas do cliente). Não há necessidade de autenticação, sessão válida ou interação do usuário — o atacante só precisa alcançar a rede/porta onde a aplicação RSC está servindo. A complexidade de exploração é baixa (AC:L) uma vez que o payload malicioso é compreendido.

AWS reportou, via honeypots MadPot, exploração ativa por múltiplos grupos com nexo à China (infraestrutura associada a Earth Lamia e Jackpot Panda, além de clusters não atribuídos) horas após a divulgação pública em 3 de dezembro de 2025. Esses grupos combinaram scanners automatizados (alguns com randomização de user-agent para evadir detecção) com PoCs públicos. É importante notar que boa parte dos PoCs públicos circulando é tecnicamente falha: vários exemplos registram deliberadamente módulos perigosos (`fs`, `child_process`, `vm`) no manifesto do servidor — algo que aplicações reais nunca deveriam fazer — e outros permanecem "funcionais" apenas contra versões já corrigidas. Isso gera exploração em massa de baixa qualidade (volume sobre precisão), mas não reduz o risco real da falha em ambientes genuinamente vulneráveis.

O resultado final da exploração bem-sucedida é execução arbitrária de código no processo servidor Node.js que hospeda o runtime RSC — controle total do processo, com as implicações de acesso a variáveis de ambiente, segredos, rede interna e possivelmente pivô lateral, dependendo do ambiente de execução.

A correção definitiva é atualizar os pacotes react-server-dom-webpack, react-server-dom-parcel e react-server-dom-turbopack para as versões corrigidas 19.0.1, 19.1.2 ou 19.2.1 (conforme a linha 19.x em uso). Como muitos frameworks empacotam ou dependem dessas bibliotecas, a atualização real geralmente precisa acontecer no framework: Next.js corrigiu em 14.2.35 (linha 13.3–14.x), 15.0.8, 15.1.12, 15.2.9, 15.3.9, 15.4.11, 15.5.10, 16.0.11, 16.1.5 e nas respectivas releases canary; react-router (APIs RSC instáveis), waku, @parcel/rsc, @vitejs/plugin-rsc e rwsdk também publicaram atualizações que devem ser aplicadas via upgrade de react, react-dom e do pacote react-server-dom-* correspondente.

Algumas hospedeiras aplicaram mitigações temporárias em nível de infraestrutura (ex.: regras WAF, como o AWSManagedRulesKnownBadInputsRuleSet versão 1.24+) e o próprio React Team foi explícito: essas mitigações de borda não substituem a correção e não devem ser tratadas como solução — apenas reduzem a janela de exposição enquanto o patch não é aplicado. Não há flag de configuração ou desativação de feature documentada pelo fornecedor que neutralize a falha sem atualizar o código; a única mitigação real é a troca de versão.

Aplicações que não usam framework, bundler ou plugin com suporte a RSC não são afetadas, segundo o fornecedor — mas qualquer app que suporte RSC é candidato, mesmo sem implementar Server Functions próprios, já que o runtime vulnerável responde ao endpoint independentemente de uso explícito.

Procurar em logs de acesso requisições HTTP para os endpoints de Server Function (tipicamente rotas usadas pelo RSC para chamadas RPC do cliente para o servidor) com payloads anômalos, malformados ou contendo referências a nomes de módulo/exportação suspeitos (ex.: tentativas de invocar 'fs', 'child_process', 'vm' ou caminhos que não correspondem a funções esperadas da aplicação). A AWS reportou uso de scanners automatizados com randomização de user-agent, o que dificulta bloqueio por assinatura simples de UA.

Como muitos PoCs públicos são não funcionais ou testam abordagens genéricas, espera-se volume alto de tentativas falhas gerando ruído significativo nos logs — presença de tentativas não implica necessariamente sucesso da exploração. Não há um IOC único e confiável publicado pelo fornecedor; regras de WAF (como AWSManagedRulesKnownBadInputsRuleSet 1.24+) e assinaturas Nuclei/Metasploit existentes servem como sinal complementar, mas a ausência de detecção não garante que o ambiente não foi comprometido antes da aplicação de mitigações.