Confira recomendações de especialistas para mitigar riscos.
A falha permite a execução remota de código (RCE) sem autenticação, usando apenas uma requisição HTTP especialmente construída.
Segundo a Wiz Research, 39% dos ambientes de nuvem analisados possuem instâncias vulneráveis. A facilidade de exploração e a ampla superfície exposta fizeram com que diversos pesquisadores e empresas de segurança classificassem o incidente como um dos mais graves do ecossistema JavaScript moderno.
Empresas como Wiz, Datadog, Amazon Threat Intelligence e GreyNoise confirmaram a exploração ativa. Há registros de roubo de credenciais, instalação de backdoors, mineração de criptomoedas e movimentos laterais dentro da infraestrutura comprometida, inclusive em cenários que envolvem servidores dedicados, clusters Kubernetes e serviços hospedados em provedores globais.
A vulnerabilidade está no protocolo Flight, responsável por transportar dados entre cliente e servidor nos React Server Components.
O erro ocorre durante a desserialização lógica do payload — processo em que informações recebidas são convertidas em estruturas internas utilizadas pelo servidor.
Nesse momento, o servidor:
O resultado é uma RCE completa antes mesmo que a aplicação execute qualquer camada de segurança interna.
Em termos práticos, a falha permite que um criminoso envie um frame de Flight malicioso capaz de manipular o fluxo de execução e ativar trechos arbitrários de código no servidor — com potencial para comprometer toda a infraestrutura crítica conectada a ele.
O cenário reúne fatores raros em incidentes dessa magnitude:
A maioria das aplicações geradas por create-next-app já nasce vulnerável, mesmo sem que os desenvolvedores utilizem diretamente React Server Components.
A combinação de falha crítica e adoção massiva faz com que o impacto seja proporcional ao crescimento global do React como base de aplicações web modernas.
As versões vulneráveis incluem:
A Wiz Research identificou que:
A densidade de exposição torna a vulnerabilidade globalmente significativa, especialmente em países que concentram operações digitais críticas, incluindo o Brasil, que tem visto forte expansão em serviços de colocation no Brasil, cargas de trabalho distribuídas e aplicações que exigem baixa latência.
As primeiras tentativas de ataque surgiram poucas horas após a prova de conceito circular online. Sensores de diversas empresas detectaram:
A GreyNoise identificou pelo menos 95 IPs que realizavam exploração oportunista.
A AWS relatou que grupos associados à China testaram vetores dias antes da divulgação completa.
O exploit depende de um payload RSC que altera:
Por não validar adequadamente o frame recebido, o servidor trata valores maliciosos como parte do fluxo legítimo de execução.
Em seguida, o ambiente Node.js executa o código resultante como se fosse originado pela própria aplicação.
Esse comportamento ocorre antes de validações internas, autenticações, middlewares ou controles de acesso — o que torna a falha especialmente perigosa para arquiteturas modernas de microserviços, CI/CD contínuo e nuvens corporativas que dependem de resiliência e escalabilidade.
1. Aplicar patches imediatamente
2. Auditar repositórios e pipelines de CI/CD
Ferramentas automatizadas podem reinstalar versões vulneráveis.
3. Analisar contêineres e imagens base
Especialmente em ambientes Kubernetes e cloud híbrida, onde atualizações podem levar tempo para se propagar.
4. Monitorar indicadores pós-exploração
A HostDime Brasil, que opera data centers Tier III em João Pessoa e São Paulo, destaca que a vulnerabilidade rompe a camada mais exposta da aplicação: a entrada do fluxo HTTP.
Segundo Saulo Brito, especialista da HostDime:
“Como a falha ocorre na camada do framework (desserialização), não existe código de aplicação (Userland) que possa sanitizar o payload de forma segura antes que o React o processe. A mitigação a nível de código resume-se a atualização e redução de superfície de ataque.”
Saulo reforça que ambientes modernos cloud-native aumentam a superfície de impacto:
“Se não for possível atualizar o sistema imediatamente, é possível reduzir o risco aplicando medidas temporárias no código. Uma medida é adicionar um middleware de bloqueio. Esse middleware, rodando em Node.js ou no Edge Runtime, deve interceptar requisições POST direcionadas aos endpoints de ação, como o path /_next/server-action no Next.js. Ele deve rejeitar payloads suspeitos antes que cheguem ao renderizador do React.
Use o WAF como defesa temporária e estratégia de mitigação (virtual patch) até que a atualização seja aplicada. Configure regras para inspecionar o body de requisições POST enviadas aos endpoints RSC, normalmente identificados por headers como Next-Action ou paths como /*.rsc e /_next/server-action.
Bloqueie requisições cujo payload contenha:
Para empresas que operam aplicações críticas em infraestrutura de data center, o risco é imediato:
“A correção precisa ser aplicada sem demora. E não basta atualizar: é necessário revisar logs, validar contêineres, girar credenciais e confirmar que não houve exploração anterior. Esse tipo de ataque deixa rastros que não aparecem na primeira análise.”
Ambientes hospedados na HostDime contam com data centers próprios projetados para alta disponibilidade e conseguem aplicar patches com continuidade operacional, mesmo em cenários sensíveis.
O uso crescente de Next.js no Brasil, especialmente em empresas de tecnologia, plataformas SaaS, serviços financeiros, provedores de serviços digitais e negócios que dependem de baixa latência no Brasil, amplia o risco de exposição.
Ambientes distribuídos, rodando em cloud pública ou híbrida, são particularmente sensíveis a vulnerabilidades desse tipo, já que o comprometimento de uma aplicação pode se estender a toda a cadeia de serviços.
Empresas que utilizam data center Tier III, servidores dedicados de missão crítica e arquitetura de colocation têm vantagem operacional ao aplicar correções sem interrupções, reduzindo a janela de exposição e preservando a continuidade de serviços essenciais.