O mundo da cibersegurança está em polvorosa com React2Shell (CVE-2025-55182), uma vulnerabilidade crítica de execução remota de código (RCE) que afeta o React e o Next.js. A escala da ameaça é enorme: pesquisadores já identificaram mais de 77.000 endereços IP vulneráveis expostos à internet e confirmaram que atores patrocinados por estados e mineradores de criptomoedas oportunistas já invadiram pelo menos 30 organizações.
Mas, se você olhar com atenção, esta não é realmente uma história sobre o React.
É uma história sobre Roubo de Identidade de Infraestrutura.
Quando um invasor explora o React2Shell, ele não apenas invade sua rede; ele se torna sua aplicação. Ele herda a identidade, as chaves de API e a confiança implícita que seu backend deposita em seus servidores frontend. Isso transforma uma falha de código em uma crise de identidade para suas APIs internas, destruindo a fronteira de confiança entre seu frontend e seus dados críticos.
A "virada": do RCE no frontend à violação de API
O React2Shell explora uma falha no protocolo "Flight" usado pelos React Server Components para serializar dados. Ao enviar um payload malicioso, frequentemente disfarçado dentro de uma requisição HTTP padrão usando o cabeçalho next-action, um invasor não autenticado pode enganar o servidor para que ele execute código arbitrário.
É aqui que a história muda. Assim que um invasor obtém a execução de código no seu servidor Next.js, ele não para por aí. Ele essencialmente "assume o controle" de um nó confiável dentro da sua rede.
De acordo com análises aprofundadas de pesquisadores de segurança, os invasores já estão usando esse ponto de apoio para extrair credenciais de nuvem, acessar serviços de metadados e implantar backdoors como o Sliver. Para os seus sistemas de backend, as solicitações provenientes desse servidor comprometido parecem legítimas. Isso cria uma plataforma de lançamento perfeita para o movimento lateral Leste-Oeste.
O impacto real: 7 maneiras pelas quais o React2Shell compromete suas APIs
Uma vez estabelecida essa base, o invasor pode usar o servidor comprometido para atacar seu ecossistema de API interno. Isso abre as portas para sete riscos distintos:
- Acesso a Shadow APIs: Os invasores podem escanear e acessar APIs internas relacionadas a microsserviços que nunca deveriam ter sido expostas à internet, contornando a obscuridade que geralmente as protege.
- Contorno de controles de acesso: Como a solicitação vem de um IP interno confiável (o servidor web), ela frequentemente ignora verificações de autenticação rigorosas, regras de WAF ou listas de permissão de IP destinadas ao tráfego externo.
- Roubo de identidade na nuvem: Os invasores visam especificamente as APIs de metadados de nuvem internas (por exemplo, 169.254.169.254) para roubar credenciais temporárias de IAM, permitindo que elevem privilégios dentro do seu ambiente de nuvem.
- Roubo de dados confidenciais: Os invasores podem consultar diretamente bancos de dados de backend ou armazenamentos de dados de usuários, exfiltrando grandes quantidades de PII sem disparar alarmes de perímetro.
- Modificação da lógica de backend: Com acesso a APIs de configuração interna, os invasores podem potencialmente alterar a lógica de negócios ou conceder a si mesmos acesso administrativo persistente.
- Sequestro de recursos: Os invasores podem abusar dos seus recursos de API internos para implantar mineradores de criptomoedas ou lançar ataques de Negação de Serviço (DoS) contra outros serviços internos.
- Comprometimento total do ambiente (movimento lateral): A partir do servidor web, eles podem se mover lateralmente para outros contêineres, pipelines de CI/CD ou componentes de infraestrutura sensíveis.
Por que a defesa de perímetro não é suficiente
Ferramentas de segurança tradicionais, como WAFs, estão com dificuldades para detectar isso.
- O exploit inicial: O payload malicioso do React2Shell frequentemente contorna WAFs porque aparece como dados de aplicação serializados válidos (usando o cabeçalho next-action).
- O tráfego interno: Uma vez que o invasor está dentro, o tráfego dele é Leste-Oeste (de servidor interno para servidor interno). A maioria das ferramentas de segurança de borda não detecta isso. Elas protegem a porta da frente, mas não têm visibilidade do que acontece no corredor.
Como a Salt Security fecha essa lacuna
O React2Shell valida exatamente por que a visibilidade de API Leste-Oeste é fundamental. Você não pode depender apenas do perímetro.
A Salt Security protege você de duas maneiras principais:
1. Descoberta da superfície de ataque de API
Você não pode proteger seu backend se não souber o que ele expõe. A Salt descobre automaticamente toda a sua pegada de API, identificando as Shadow APIs e endpoints internos que um frontend comprometido visaria. Ao mapear todo o seu ecossistema de APIs, a Salt ajuda você a entender o potencial "raio de explosão" de uma violação de frontend como o React2Shell, garantindo que você saiba exatamente quais dados e serviços críticos estão acessíveis a partir da sua camada web.
2. Monitoramento do "Insider Confiável" (Tráfego Leste-Oeste)
O aspecto mais perigoso do React2Shell é que o ataque vem de uma fonte confiável: seu próprio servidor web. Para sua rede interna, essas solicitações parecem legítimas porque se originam de um endereço IP válido e na lista de permissões.
A Salt Security adota uma abordagem diferente. Nós não olhamos apenas para a origem do tráfego; nós analisamos o comportamento da identidade.
- Estabelecendo uma base de confiança: A Salt estabelece uma base de comportamento normal para cada ativo. Sabemos que o seu frontend Next.js normalmente chama APIs de consumidor específicas para buscar o conteúdo da página.
- Detectando abusos pós-exploração: Se esse servidor confiável começar subitamente a escanear portas internas, chamar APIs administrativas que nunca usou antes ou consultar serviços de metadados em nuvem (um sinal claro da cadeia de ataque React2Shell), a Salt identifica imediatamente esse desvio. Detectamos a consequência da violação, o movimento lateral, mesmo que o exploit inicial tenha contornado o WAF.
Conclusão
O React2Shell é um lembrete importante de que seu modelo de segurança não pode presumir que o frontend é seguro. Uma única falha em um framework web pode voltar sua própria infraestrutura confiável contra você.
Para proteger seus dados, você precisa olhar além do perímetro e ver o que está acontecendo atrás do servidor web. Corrigir este CVE específico é necessário, mas a verdadeira resiliência exige uma estratégia que presuma que a violação já aconteceu. Você precisa da visibilidade profunda e interna de API que apenas a Salt Security oferece para garantir que, quando o próximo zero-day de frontend surgir, seus dados de backend permaneçam fora de alcance.
Se você quiser saber mais sobre a Salt e como podemos ajudá-lo, por favor entre em contato conosco, agende uma demonstração, ou visite nosso site. Você também pode obter uma Avaliação de Superfície de Ataque de API gratuita da equipe de pesquisa da Salt Security e descobrir o que os atacantes já sabem.