Nos últimos dias, fui bombardeado com alertas que indicavam a detecção de um potencial software malicioso em diversos ambientes distintos, pelos quais sou responsável. Até então, mais um dia normal na vida de um analista de SOC. Porém, desta vez, algo estava diferente: coincidentemente, todos os alertas estavam correlacionados e apresentavam os mesmos indicadores e comportamentos, mesmo ocorrendo em ambientes distintos e sem qualquer relação entre si.
Ao analisar a origem desse suposto arquivo malicioso, por meio de pesquisas, cheguei à conclusão de que o executável estava relacionado a um serviço da Microsoft Store presente em endpoints Windows 10 e Windows 11, o que justificava o fato de diversos ambientes não correlacionados apontarem o mesmo EXE como suspeito.
Nesse momento, considerei duas possibilidades. A primeira, e mais crítica: a Microsoft teve essa aplicação comprometida e estaria, involuntariamente, distribuindo malware para o mundo inteiro o clássico “Supply chain attack”. Se fosse esse o caso, “fujam para as colinas!“. A segunda hipótese era a existência de alguma característica ou comportamento potencialmente legítimo do software que estivesse sendo identificado como disruptivo pelo XDR.
Com isso em mente, a melhor abordagem foi buscar outras fontes de dados, a fim de entender se essas detecções já eram conhecidas pela comunidade, vendors e demais analistas. Assim eu fiz. Após alguns minutos de pesquisa, observei que outros analistas, que operavam soluções de XDR alternativas, enfrentavam o mesmo problema, um número considerável de alertas indicando que o software da Microsoft estava sendo reconhecido e classificado como malware. A princípio, isso é um fator preocupante, pois aumenta a probabilidade de o arquivo ser realmente malicioso. No entanto, ao me aprofundar ainda mais, identifiquei em um fórum oficial da Microsoft a provável justificativa para o motivo de as soluções de segurança estarem realizando essa detecção, segundo o próprio vendor.
O arquivo executável passou a apresentar uma estrutura de código com seções de alta entropia e uso de packers, recurso comumente empregado em softwares maliciosos, pois é utilizado para proteger o código da aplicação e dificultar a engenharia reversa por parte dos analistas de Malware. colher as informações oficiais do fabricante foram um ponto chave para a finalização destes alertas.
Após a resolução de todas as questões relacionadas a esses incidentes e a classificação deles como falso positivo, surge a pergunta: O XDR errou? Apesar de a resposta parecer óbvia, vale analisar os fatos. A ferramenta foi criada para identificar comportamentos e ações suspeitas em qualquer executável, independentemente de assinatura digital, hash ou processo pai. Sua principal função é atuar como uma sirene para o analista. Essencialmente, ela não valida se a atividade representa um incidente real, pois, embora possua estratégias de mitigação associadas, essa não é sua função principal.
A decisão final sempre será do analista. Mesmo em cenários de automação utilizando SOAR, este fato se aplica, afinal, é o analista quem cria o playbook a ser executado. Portanto, nunca confie 100% na ferramenta, independentemente de sua classificação ou ranking no mercado. A máquina não faz nada por si só; ela apenas executa exatamente aquilo para o qual foi projetada. O bom analista é, e sempre será, aquele que reconhece isso e busca desenvolver as habilidades técnicas necessárias para absorver todas as informações fornecidas pelas ferramentas e, somente após uma análise minuciosa, identificar se determinado incidente é ou não verdadeiro.
Graduado em Análise e Desenvolvimento de Sistemas pela Universidade Paulista, e Pós-graduando em “Defensive Cyber Security” pela FIAP, atua como N1 no time de SOC da CYLO, é responsável por realizar a primeira análise e resposta de incidentes cibernéticos, realizou capacitações no campo de SOC/CSIRT, tendo como destaque os treinamentos promovidos pela CERT.BR em conjunto com a instituição Carnegie Mellon University “Foundations of Incident Management” e “Advanced Topics in Incident Handling”
O valor do EPSS saltou de 13,9% em 08/12/2025 para 76,01% HOJE 11/12/2025.
Com um valor de CVSS 10,0 é fundamental que sejam aplicadas as medidas de resolução imediatamente.
1. Introdução
No início de dezembro de 2025, uma vulnerabilidade de severidade crítica, apelidada de React2Shell, emergiu, abalando a comunidade de desenvolvimento web.
Identificada oficialmente como CVE-2025-55182, trata-se de uma falha de Execução Remota de Código Não Autenticada ou Unauthenticated Remote Code Execution (Unauthenticated RCE) e recebeu a pontuação máxima de 10.0 no Common Vulnerability Scoring System (CVSS), sinalizando um risco extremo para uma vasta gama de aplicações modernas.
Uma Execução Remota de Código Não Autenticada é uma vulnerabilidade que permite a um atacante executar comandos ou código arbitrário em um servidor remoto sem necessidade de possuir credenciais válidas ou autenticação prévia.
Diferentemente de vulnerabilidades que exigem que o invasor esteja logado ou tenha acesso autorizado ao sistema, uma Unauthenticated RCEpode ser explorada por qualquer pessoa com acesso à rede (geralmente a internet), tornando-a extremamente perigosa.
A vulnerabilidade reside no coração dos React Server Components (RSC), uma tecnologia cada vez mais adotada em frameworks populares como Next.js, afetando potencialmente mais de 40% dos principais websites da Internet.
Este artigo oferece uma análise técnica aprofundada da React2Shell, detalhando seu mecanismo de exploração, o impacto que pode causar e as medidas essenciais que as equipes de segurança e desenvolvimento devem tomar para mitigar esta ameaça iminente.
2. O Mecanismo da Exploração: Desserialização Insegura
A React2Shell NÃO é uma vulnerabilidade comum. Sua periculosidade reside na simplicidade de sua exploração.
Um atacante, sem qualquer tipo de autenticação, pode comprometer completamente um servidor vulnerável através de uma única requisição HTTP POST maliciosamente elaborada.
A raiz do problema está na forma como os React Server Components lidam com a desserialização de dados.
Quando um cliente envia uma requisição para um endpoint que utiliza Server Functions, o React transforma os dados recebidos em chamadas de função do lado do servidor.
Durante este processo, a vulnerabilidade permite que um payload manipulado seja desserializado sem as devidas validações de segurança. Isso cria um caminho direto para que o atacante injete e execute código arbitrário com os mesmos privilégios do processo do servidor Node.js, abrindo as portas para um comprometimento total do sistema.
2. Análise de Impacto: As Consequências de uma Exploração Bem-Sucedida
Uma vulnerabilidade de RCE pré-autenticação é o ativo mais cobiçado no arsenal de um agente malicioso. No caso da React2Shell, as consequências de uma exploração bem-sucedida são catastróficas e podem se manifestar de várias formas:
Comprometimento Total da Infraestrutura: O atacante obtém controle total sobre o servidor, permitindo acesso irrestrito ao sistema de arquivos, roubo de credenciais e a instalação de backdoors para acesso persistente.
Exfiltração de Dados Sensíveis: Uma vez dentro do sistema, o invasor pode acessar e exfiltrar informações críticas, como bancos de dados de clientes, segredos de aplicação (chaves de API, tokens), propriedade intelectual e lógica de negócios.
Movimento Lateral na Rede: O servidor comprometido torna-se um ponto de pivô, a partir do qual o atacante pode lançar novas ofensivas contra outros sistemas internos, bancos de dados e recursos na nuvem, expandindo o alcance do ataque por toda a organização.
Ataques de Ransomware e Interrupção de Negócios: Com controle total, os atacantes podem implantar ransomware, criptografando dados vitais e exigindo um resgate, ou simplesmente interromper as operações, causando perdas financeiras e danos à reputação.
2. Descrição Técnica
A vulnerabilidade decorre de desserialização insegura no protocolo Flight, mecanismo responsável por transportar estruturas dos Server Components entre cliente e servidor.
Ao receber um payload malicioso, o servidor interpreta dados arbitrários como referências de função, o que permite execução remota de código com privilégios equivalentes ao processo Node.js.
Condições de exploração
Não exige autenticação;
Não exige cookie, API key ou token;
Pode ser explorada por qualquer atacante com acesso ao endpoint RSC;
Vetor principal: HTTP POST com conteúdo Flight manipulado.
Impacto técnico
Execução remota de código (RCE);
Execução arbitrária de processos no host ou container;
Exfiltração de dados sensíveis;
Movimento lateral;
Possível comprometimento total de infraestrutura (quando mal configurada).
3. Sistemas Afetados
3.1 React e bibliotecas centrais
Conforme registros do NVD:
Pacote
Versões vulneráveis
Versões corrigidas
react-server-dom-webpack
19.0.0 a 19.2.0
19.0.1+, 19.1.2+, 19.2.1+
react-server-dom-parcel
19.0.0 a 19.2.0
19.0.1+, 19.1.2+, 19.2.1+
react-server-dom-turbopack
19.0.0 a 19.2.0
19.0.1+, 19.1.2+, 19.2.1+
3.2 Frameworks afetados
Next.js versões 15.x e 16.x; Associado adicionalmente ao CVE-2025-66478, conforme documentação CISA/NVD.
React Router com RSC;
Expo;
RedwoodJS;
Waku;
Plugins de integração RSC para Vite, Parcel e Turbopack.
4. Vetor de Ataque e Indicadores de Exploração
4.1 Vetor primário
POST /<endpoint-rsc>
Content-Type: application/json
Payload malformado contendo blocos Flight manipulados
4.2 Indicadores observáveis
Logs de erro do Flight referentes a parsing inesperado;
Picos súbitos de CPU em processos Node.js;
Tentativas de criação de processos via child_process.spawn/exec;
Comunicação egressa para hosts desconhecidos
Criação de artefatos suspeitos em /tmp em containers Linux
Comprometimento de clusters Kubernetes negligentemente isolados;
Uso da vulnerabilidade para implantação de webshells e reverse shells.
5. Mitigação
5.1 Patching obrigatório
Aplicar imediatamente as versões corrigidas dos pacotes React RSC e atualizar aplicações Next.js para releases não vulneráveis.
5.2 Controles compensatórios (temporários)
Regras de WAF para bloquear payloads suspeitos do protocolo Flight;
Monitoramento agressivo de tráfego de egressão;
Habilitar logs completos de chamadas RSC;
Bloquear criação de processos filho por Node.js quando possível;
Reforçar políticas noexec em diretórios temporários.
5.3 Defesa em profundidade
Execução do Node.js com mínimo privilégio;
Isolamento adequado de containers e namespaces;
Mecanismos RASP como camada adicional;
6. Avaliação de Risco
A vulnerabilidade é considerada Crítica, nível máximo no CVSS 10.0, devido a:
Exploração ativa confirmada globalmente
Ausência de barreiras de autenticação
Impacto direto em aplicações amplamente adotadas (React/Next.js)
Possibilidade de comprometimento total do ambiente
É altamente recomendável priorizar a correção em ambientes expostos à internet.
6.1. Sobre o EPSS e CVVS Score para React2Shel
Métrica
Valor
Score Inicial
0.46%
Score Atual
13.86% (8 de dezembro de 2025) 76,01% (atualizado em 11/12/2025)
Percentil
Em atualização contínua
O Problema: Uma Discrepância Crítica
Existe uma divergência significativa entre o CVSS (10.0 – Crítico) e o EPSS (13.86%), que revela uma limitação importante dos sistemas de scoring automatizados.
É importante entender que o EPSS é um “indicador retardado” (lagging indicator).
Embora tenha subido de 0.46% para 13.86% desde o início da publicação do CVE, ainda está muito abaixo do que os níveis reais de exploração justificariam, porque:
Exploração Ativa em Andamento: Grupos de ameaças vinculados à China já foram observados explorando a vulnerabilidade (AWS)
Liderança em Bug Bounty: É o #1 CVE mais explorado na plataforma HackerOne
Remediação Acelerada: Organizações estão remediando em menos de um dia em média
Escala Massiva: Mais de 12 milhões de sites potencialmente vulneráveis.
O Que Isso Significa
O EPSS demonstra que sistemas de scoring automatizados podem não acompanhar o ritmo de exploração em tempo real. Isso ressalta a importância de:
Não depender apenas de scores automatizados para priorização de vulnerabilidades críticas.
Usar feedback em tempo real de comunidades de segurança (bug bounty, threat intelligence).
Considerar o contexto operacional além dos scores numéricos
Adriano Mauro Cansian, Doutor em Física Computacional e Professor Associado e pesquisador da UNESP – Universidade Estadual Paulista, possui 30 anos de experiência em pesquisa, desenvolvimento e ensino de segurança cibernética. Fundador e coordenador do Laboratório ACME! Cybersecurity Research, e revisor das revistas “Computers & Security” e “International Journal of Forensic Computer Science“, consultor e membro de vários comitês e organizações técnicas para promover a pesquisa em segurança da informação, além de atuar como voluntário em organizações de governança da Internet.
Recentemente tivemos uma rápida disseminação do malware “Sorvepotel”, e agora novamente, nos deparamos com a notícia que me deixou preocupado, noticia está sobre um novo malware bancário chamado “Herodotus” e que vem atacando muitos usuários Android.
O novo malware se utiliza como principal estratégica de propagação através de campanhas de phishing por SMS, onde usuários recebem links fraudulentos que levam a páginas maliciosas onde o malware é baixado e instalado no seu dispositivo mobile. Após instalado, o malware obtém permissões críticas do sistema e utilizando de táticas sofisticadas como sobreposição de tela para roubar credenciais e tornando as sessões legitimas, dificultando a ação dos antivírus tradicionais ou mesmo não detectando o comprometimento do dispositivo.
Precisamos ficar atentos e reforçar a vigilância no mundo digital e começar a nos precaver com medidas de segurança como, baixar aplicativos somente de lojas oficiais(apesar de não ser 100% a prova de falha, ainda é a opção mais segura), suspeitar de SMS com links e fontes desconhecidas, não validar informações pelo SMS, onde mensagens podem ser interceptadas e alteradas, utilizar se de aplicativos autenticadores como Google ou Microsoft Authenticator, não autorizar permissões críticas no seu dispositivos a aplicativos suspeitos .
Precisamos ficar constantemente atentos, pois a sofisticação dos atacantes está sempre um passo à frente. Segurança não é somente ferramental, mas sim um processo.
