React2Shell: falha crítica no React Server Components e Next.js

Redação
8 de dez.
8 min de leitura

Uma vulnerabilidade com pontuação máxima de criticidade (CVSS 10.0) foi identificada no protocolo usado pelos React Server Components (RSC), popularmente apelidada de React2Shell, rastreada como CVE-2025-55182 no React e CVE-2025-66478 no Next.js. Essa falha permite execução remota de código não autenticada em aplicações que utilizam RSC em ambiente Node.js, afetando configurações padrão de frameworks como Next.js e outros bundlers que implementaram suporte a RSC.

O objetivo deste artigo é descrever tecnicamente o problema, o mecanismo de ataque, o escopo de impacto e um plano prático de mitigação, em linguagem orientada a times de desenvolvimento, SRE e segurança.

1. Arquitetura relevante: React Server Components e o protocolo Flight

Os React Server Components (RSC) foram introduzidos para deslocar parte da lógica de interface para o servidor, reduzindo JavaScript no cliente e permitindo acesso direto a dados e recursos somente disponíveis no backend.

Em alto nível, a arquitetura funciona da seguinte forma:

O cliente (navegador ou runtime que consome a aplicação) inicia uma navegação ou ação que envolve componentes de servidor.
O servidor React renderiza uma árvore de componentes de servidor e gera um payload serializado conhecido como Flight payload.
Esse payload:
- descreve componentes, resultados de renderização e estados necessários;
- é enviado para o cliente;
- é interpretado para reidratar a UI e compor com componentes de cliente.

Sobre essa base, surgem as Server Functions / Server Actions. Elas expõem um mecanismo remoto de chamada de funções no servidor, através do mesmo protocolo:

o cliente envia um payload Flight que representa uma chamada de função;
o servidor desserializa esse payload;
a função indicada é executada com os argumentos descritos nos dados recebidos.

Esse desenho implica que o protocolo Flight é mais do que um simples transporte de dados: ele carrega estruturas que modelam chamadas de função e estados do lado servidor.

2. O núcleo da vulnerabilidade: desserialização de instruções controladas pelo atacante

A falha React2Shell reside no modo como o protocolo Flight é processado no lado servidor para Server Functions.

O fluxo vulnerável pode ser resumido assim:

O servidor expõe um endpoint de Server Function ou outro endpoint que aceite payloads RSC.
O cliente envia um payload Flight que, em condições normais, descreveria:
- qual função de servidor deve ser chamada;
- quais argumentos devem ser passados;
- eventualmente, qual módulo contém essa função.
O código vulnerável:
- desserializa o payload em estruturas internas que representam essas chamadas;
- confia demais no conteúdo recebido;
- executa a lógica descrita sem validação rigorosa sobre o que foi solicitado.

Com isso, um atacante consegue:

forjar um payload Flight manualmente, usando HTTP direto, sem passar pela UI legítima;
instruir o servidor a executar caminhos de código não previstos para exposição pública;
alcançar execução remota de código (RCE) pre-auth, rodando JavaScript arbitrário no ambiente Node.js em que a aplicação está hospedada.

Do ponto de vista de segurança, trata-se de um caso de desserialização insegura:

a entrada do usuário não é apenas dados;
ela se torna efetivamente instruções sobre o que o servidor deve fazer;
não existe fronteira forte entre “dados” e “comandos” durante o processo de desserialização.

3. Escopo de impacto: React, Next.js, outros bundlers e Node.js

A falha tem origem na implementação do protocolo Flight nos pacotes de RSC, e se propaga em cascata pelo ecossistema.

3.1 React

A vulnerabilidade é registrada como CVE-2025-55182 e afeta principalmente os seguintes pacotes:

react-server-dom-webpack
react-server-dom-parcel
react-server-dom-turbopack

nas versões:

19.0
19.1.0
19.1.1
19.2.0

Esses pacotes são utilizados internamente por frameworks e bundlers para suportar RSC. Em muitos projetos, eles aparecem apenas como dependências transitivas e não diretamente no package.json.

3.2 Next.js

O Next.js, que implementa RSC via App Router, herdou o problema. Para esse impacto específico, foi registrado o CVE-2025-66478.

São afetadas diversas versões das linhas 15.x e 16.x, incluindo versões estáveis e canary, compatíveis com RSC. As versões corrigidas incluem, entre outras:

next 15.0.5
next 15.1.9
next 15.2.6
next 15.3.6
next 15.4.8
next 15.5.7
next 16.0.7

Qualquer aplicação Next.js com App Router, rodando em uma dessas faixas vulneráveis, e exposta à internet, torna-se alvo imediato.

3.3 Outros frameworks e plugins

Além do Next.js, o problema afeta qualquer stack que implemente RSC utilizando o protocolo Flight, incluindo:

integrações do React Router com RSC;
bundlers e plugins para RSC em:
- Waku;
- Parcel (RSC);
- Vite (plugin RSC);
- outras soluções que declararam suporte a RSC.

A condição crítica é sempre a mesma: recepção e desserialização de payloads Flight controlados pelo cliente em endpoints acessíveis externamente.

3.4 Papel do Node.js

O Node.js não é o componente onde o bug foi introduzido, mas é o runtime no qual a aplicação vulnerável executa. Na prática:

uma exploração bem sucedida resulta em RCE no processo Node.js;
o atacante adquire a capacidade de rodar código com os privilégios do usuário do processo;
a partir daí pode:
- exfiltrar variáveis de ambiente;
- acessar bancos de dados;
- implantar backdoors;
- pivotar para outros recursos da infraestrutura.

4. Modelo de ameaça e cenário de ataque

4.1 Pré-requisitos para exploração

Para que a aplicação seja explorável, em geral são necessários os seguintes requisitos:

Uso de versões vulneráveis de RSC ou frameworks que os incorporam (React 19.0 a 19.2.0 com RSC, Next.js vulnerável com App Router).
Exposição de endpoints de RSC ou Server Functions para a internet.
Capacidade do atacante enviar requisições HTTP diretamente para esses endpoints.

Não é exigida autenticação nem interação via interface do usuário legítima. A superfície é puramente HTTP.

4.2 Passos típicos do ataque

Um fluxo simplificado de ataque envolve:

Descoberta de superfície
- varredura em massa identificando aplicações React/Next;
- testes automatizados para detectar endpoints com RSC habilitado.
Envio de payload Flight forjado
- requisição HTTP (tipicamente POST multipart) com um corpo especificamente construído para RSC;
- manipulação dos campos que representam a chamada de Server Function, incluindo possíveis referências a módulos internos.
Desserialização e execução
- o servidor desserializa o payload como se fosse uma requisição legítima;
- a lógica vulnerável transforma os dados recebidos em chamada de função;
- ocorre a execução de código não intencional, muitas vezes refletida em respostas HTTP específicas, o que facilita a confirmação da vulnerabilidade.
Pós-exploração
- estabelecimento de persistência (webshell, backdoor, conta maliciosa em banco de dados);
- exfiltração de segredos (chaves de API, URLs de banco de dados, tokens de serviço);
- movimentação lateral dentro do ambiente em nuvem, se permissões de rede permitirem.

Ferramentas de varredura e exploração já incorporaram payloads específicos para React2Shell, com detecção automática baseada em respostas padronizadas, o que reduz drasticamente a barreira técnica para atacantes.

5. Como identificar se uma aplicação está vulnerável

A identificação deve combinar análise de dependências, inspeção de código e, se necessário, uso de scanners específicos.

5.1 Verificar dependências do React e RSC

Em qualquer projeto Node.js, recomenda-se:

Listar versões de React e pacotes de RSC:
npm ls react react-dom react-server-dom-webpack react-server-dom-parcel react-server-dom-turbopack
Verificar se algum desses pacotes está nas versões 19.0, 19.1.0, 19.1.1 ou 19.2.0.

Se sim, o projeto deve ser tratado como potencialmente vulnerável, especialmente se RSC estiver habilitado ou se houver uso de Server Functions.

5.2 Verificar versões de Next.js e uso de App Router

Conferir o package.json:
"dependencies": { "next": "15.3.2", ... }
Confirmar se a versão pertence a uma série afetada e se a aplicação usa App Router (pasta app/ ao invés de apenas pages/).

Se a versão está abaixo dos patamares de correção e App Router está presente, considerar o serviço vulnerável até atualização.

5.3 Uso de scanners especializados

Ferramentas específicas para React2Shell podem auxiliar:

scanners que enviam payloads Flight controlados e verificam respostas determinísticas;
templates de scanners genéricos de vulnerabilidades web (como Nuclei) dedicados a CVE-2025-55182 e CVE-2025-66478.

A recomendação é usar essas ferramentas para confirmar e mapear exposição, sem depender exclusivamente delas para decidir se um sistema é seguro. Versão vulnerável deve ser tratada como risco, mesmo que o scanner não encontre um endpoint óbvio em um primeiro momento.

6. Mitigação: plano técnico de resposta

A mitigação efetiva de React2Shell envolve três frentes principais:

atualização de pacotes;
mitigação de borda (WAF, proxies);
hardening e detecção em runtime.

6.1 Atualização de React e RSC

Para aplicações que dependem de RSC:

Atualizar React e os pacotes react-server-dom-* para versões corrigidas:
- 19.0.1
- 19.1.2
- 19.2.1
Após a atualização, confirmar com:
npm ls react-server-dom-webpack react-server-dom-parcel react-server-dom-turbopack
Garantir que o lockfile (package-lock.json ou yarn.lock) foi regenerado e que não há versões antigas persistindo via dependências transitivas.

6.2 Atualização de Next.js

Para aplicações em Next.js usando App Router:

Atualizar o pacote next para uma versão que contenha o patch, por exemplo:
npm install next@16.0.7
ou a versão corrigida correspondente à linha em uso (15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7).
Revisar o changelog da versão escolhida para entender impactos de breaking changes.
Executar a suíte de testes automatizados e testes manuais básicos para garantir que a atualização não quebrou a aplicação.

6.3 Mitigações de borda com WAF e gateways

Como medida temporária, até que todos os serviços sejam atualizados:

Aplicar regras de WAF específicas para React2Shell, focadas em:
- bloquear padrões típicos de payload Flight malicioso em endpoints de RSC;
- inspecionar cabeçalhos e estruturas multipart usadas por Server Functions.
Implantar as regras inicialmente em modo de observação (log) e, após validação, migrar para modo de bloqueio.
Ter cuidado com regras genéricas demais que possam causar indisponibilidade ampla, especialmente em CDNs e provedores de edge, como já ocorreu em incidentes envolvendo ajustes agressivos de WAF.

Mitigação em WAF não substitui atualização de pacotes. Ela apenas reduz a janela de exposição durante o processo de patching.

6.4 Hardening do ambiente Node.js

Mesmo depois da correção da vulnerabilidade, boas práticas de hardening reduzem o impacto de futuras falhas similares:

executar o processo Node.js com um usuário de sistema não privilegiado;
isolar serviços em containers com limites claros de recursos e permissões;
restringir conexões de saída a apenas os destinos necessários;
usar variáveis de ambiente e segredos com o menor escopo possível, evitando privilégios excessivos.

6.5 Monitoramento e detecção em runtime

Para identificar exploração efetiva ou tentativas:

habilitar logs detalhados de requisições HTTP para endpoints RSC e Server Functions, incluindo parâmetros relevantes (com atenção a dados sensíveis);
implementar regras de detecção em soluções de SIEM ou agentes de segurança para:
- processos shell ou comandos inusitados originados do processo Node.js;
- conexões de rede anômalas partindo de containers de aplicação;
- padrões de payload que se assemelhem a PoCs conhecidos de React2Shell.

Em ambientes onde o patch não pode ser aplicado imediatamente, detecção em runtime se torna essencial para identificar rapidamente qualquer exploração em andamento.

7. Checklist para times de desenvolvimento, SRE e segurança

Para organizar a resposta à vulnerabilidade React2Shell, recomenda-se seguir um checklist objetivo:

Inventário
- listar todas as aplicações que usam React 19.x com RSC ou Next.js com App Router expostas à internet.
Classificação de risco
- priorizar sistemas que processam dados sensíveis ou críticos para o negócio.
Patching
- atualizar React e os pacotes react-server-dom-* para versões corrigidas;
- atualizar Next.js para as versões com patch de segurança;
- revisar lockfiles e reconstruir imagens de container.
Mitigação temporária
- aplicar regras específicas de WAF e monitorar falsos positivos;
- ajustar gateways ou proxies para adicionar camadas de filtragem.
Hardening
- verificar usuários, permissões e isolamento dos processos Node.js;
- revisar permissões de acesso a bancos de dados e outros serviços.
Detecção e resposta
- configurar alertas para comportamentos suspeitos (execução de comandos, conexões inusuais, padrões de payload);
- revisar logs históricos em busca de indícios de exploração desde a data de disclosure.

8. Conclusão

React2Shell expõe uma fragilidade estrutural em qualquer tecnologia que mistura dados e instruções em um canal de comunicação entre cliente e servidor. Quando o protocolo de transporte passa a carregar descrições de chamadas de função, a responsabilidade de validar rigorosamente tudo o que é desserializado se torna crítica.

No contexto de React Server Components e Next.js, essa fronteira foi violada, resultando em uma vulnerabilidade de RCE não autenticada com potencial de impacto massivo. A resposta adequada envolve:

atualização rápida de pacotes;
mitigação de borda bem calibrada;
hardening consistente de ambientes Node.js;
capacidade de monitorar e detectar tentativas de exploração.

Organizações que tratam esse tipo de CVE apenas como “mais uma atualização de biblioteca” correm o risco de enxergar o problema tarde demais, quando o atacante já estiver dentro do ambiente. A abordagem correta é tratar React2Shell como um incidente de segurança em potencial e agir com a mesma disciplina aplicada a vulnerabilidades de infraestrutura críticas.