React2Shell: Análise Aprofundada da Vulnerabilidade no React

ATUALIZAÇÃO em 11/12/2025:

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 RCE pode 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:

PacoteVersões vulneráveisVersões corrigidas
react-server-dom-webpack19.0.0 a 19.2.019.0.1+, 19.1.2+, 19.2.1+
react-server-dom-parcel19.0.0 a 19.2.019.0.1+, 19.1.2+, 19.2.1+
react-server-dom-turbopack19.0.0 a 19.2.019.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

4.3 Atividade Maliciosa Confirmada

Organizações de segurança reportaram:

  • Scanners em larga escala buscando endpoints RSC;
  • Explorações automatizadas visando Next.js exposto;
  • 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étricaValor
Score Inicial0.46%
Score Atual13.86% (8 de dezembro de 2025)
76,01% (atualizado em 11/12/2025)
PercentilEm 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:

  1. Exploração Ativa em Andamento: Grupos de ameaças vinculados à China já foram observados explorando a vulnerabilidade (AWS)
  2. Liderança em Bug Bounty: É o #1 CVE mais explorado na plataforma HackerOne
  3. Remediação Acelerada: Organizações estão remediando em menos de um dia em média
  4. 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

Referências:

  1. Portal informativo sobre a vulnerabilidade: https://react2shell.com/
  2. NVD / NIST – CVE-2025-55182
    https://nvd.nist.gov/vuln/detail/CVE-2025-55182
  3. CVE.org – CVE Record CVE-2025-55182
    https://www.cve.org/CVERecord?id=CVE-2025-55182
  4. NVD / NIST – CVE-2025-66478 (Next.js)
    https://nvd.nist.gov/vuln/detail/CVE-2025-66478
  5. React Team. React Server Components Documentation.
    https://react.dev/reference/react-server
  6. React Flight Protocol (repositório oficial).
    https://github.com/facebook/react/tree/main/packages/react-server
  7. Vercel. Next.js App Router and React Server Components.
    https://nextjs.org/docs/app/building-your-application/rendering/server-components
  8. MITRE. CWE-502: Deserialization of Untrusted Data
    https://cwe.mitre.org/data/definitions/502.html
  9. OWASP. Deserialization of Untrusted Data
    https://owasp.org/www-community/vulnerabilities/Deserialization_of_untrusted_data

WhatsApp: a nova porta de entrada

Nos últimos dias, foi identificado novamente um ataque veiculado via WhatsApp Web envolvendo o envio de um arquivo VBS (Visual Basic Script) altamente ofuscado. A ofuscação é feita por meio de códigos ASCII convertidos com a função Chr() e concatenados em tempo de execução, o que dificulta a análise estática do arquivo.

Após a desofuscação do script, foi possível recuperar os endereços de rede utilizados e toda a cadeia de ações executadas. O VBS cria pastas temporárias em C:\ (como C:\temp), gera arquivos .bat e realiza o download de múltiplos componentes, incluindo Python em modo “embedded”, ChromeDriver e um arquivo MSI. Esses artefatos são então utilizados para montar um ambiente capaz de executar scripts adicionais, automatizar o navegador e, potencialmente, interagir com sessões do WhatsApp Web ou outras aplicações sensíveis.

Um ponto relevante é que o arquivo VBS foi prontamente detectado pela solução XDR, pois o WhatsApp Web salva o anexo localmente em uma pasta temporária antes mesmo de o usuário clicar em “baixar” ou abrir o arquivo. Isso permite que mecanismos de segurança baseados em monitoramento de disco interceptem o artefato ainda no início da cadeia de ataque.

Principais IOCs:
Domínio: 193[.]36[.]109[.]208[.]host[.]secureserver[.]net
IP: 208[.]109[.]36[.]193

Domínio: empautlipa[.]com
IPs: 172[.]67[.]155[.]220, 104[.]21[.]50[.]29

A Botnet Aisuru e o Ataque Recorde à Microsoft: O Papel Estratégico do DNS

Kim Morgan (kim@acmesecurity.org) & Adriano Cansian (adriano.cansian@unesp.br)

Em 17 de novembro de 2025, a Microsoft anunciou ter mitigado o maior ataque de negação de serviço distribuído (DDoS) já registrado em sua nuvem [1]. O ataque, que atingiu um pico de 15,72 terabits por segundo (Tbps), foi direcionado a um único endpoint da plataforma Azure na Austrália no dia 24 de outubro de 2025. A operação massiva, que utilizou mais de 500.000 endereços IP comprometidos para gerar um dilúvio de tráfego UDP, foi atribuída à Aisuru, uma botnet que exemplifica a sofisticação das ameaças modernas e destaca o papel central e estratégico do Sistema de Nomes de Domínio (DNS) em seu funcionamento.

Tendências de Ataque e distribuição geográfica de vítimas de ataques DDoS da Aisuru
Figura 1: Tendências de Ataque e distribuição geográfica de vítimas de ataques DDoS da Aisuru. Fonte: (WANG et al., 2025)

Ascensão da Aisuru: De Botnet Comum a Ameaça Global

A Aisuru, inicialmente uma botnet de escala relativamente comum, teve uma ascensão meteórica em abril de 2025. O ponto de virada ocorreu quando os operadores da rede comprometeram um servidor de atualização de firmware da fabricante de roteadores Totolink. Ao modificar a URL de atualização, eles passaram a distribuir um script malicioso para qualquer dispositivo que buscasse o firmware oficial. Essa tática engenhosa resultou na infecção de milhares de roteadores, expandindo a botnet para mais de 100.000 dispositivos em um curto período e consolidando a Aisuru como uma das maiores redes de bots ativas atualmente, com uma contagem de nós estimada em 300.000 [2].

Para se propagar, a Aisuru explora uma gama diversificada de vulnerabilidades, desde falhas antigas até 0-days, demonstrando a capacidade de seus operadores de integrar rapidamente novos vetores de ataque. A tabela abaixo detalha algumas das vulnerabilidades notáveis exploradas pelo grupo.

Vulnerabilidades exploradas para o comprometimento de dispositivos utilizados pelo grupo da Aisuru
Figura 2: Vulnerabilidades exploradas para o comprometimento de dispositivos utilizados pelo grupo da Aisuru. Fonte: (WANG et al., 2025)

O DNS como Pilar da Operação

A infraestrutura de comando e controle (C2) da Aisuru depende criticamente do DNS. Para evitar a detecção e facilitar a rotação de seus servidores, a botnet utiliza registros de recurso TXT para comunicar os endereços IP dos servidores C2 aos dispositivos infectados. O malware consulta um domínio C2 e decodifica a informação contida no registro TXT para estabelecer a conexão. As técnicas de decodificação evoluíram, passando de uma combinação de base64 e ChaCha20 para base64 e XOR, numa tentativa contínua de evadir a detecção por ferramentas de segurança [2].

Hosts consultados pelos dispositivos comprometidos da botnet
Figura 3: Hosts consultados pelos dispositivos comprometidos da botnet. Fonte: (ALIENVAULT, 2025)

A escala da operação da Aisuru foi exposta de forma dramática em novembro de 2025. Após mudar o resolvedor DNS padrão de seus bots do serviço do Google (8.8.8.8) para o da Cloudflare (1.1.1.1), o volume massivo de consultas geradas fez com que dois de seus domínios de C2 alcançassem as posições de 1º e 3º lugar no ranking global de domínios mais consultados da Cloudflare [3].

O evento, embora tenha levado a Cloudflare a remover os domínios maliciosos de sua lista pública, revelou a imensa escala da botnet, superando em tráfego de DNS gigantes como Google e Apple por um breve período.

Domínios da botnet Aisuru redigidos no ranking global da Cloudflare
Figura 4: Domínios da botnet Aisuru redigidos no ranking global da Cloudflare. Fonte: (KREBS et al., 2025)

Monetização Além do DDoS

Embora seja conhecida por seus ataques DDoS de grande impacto, a Aisuru diversificou suas fontes de receita, operando também como um lucrativo serviço de proxy residencial. Os operadores da botnet alugam o acesso aos dispositivos infectados, permitindo que clientes pagantes roteiem seu tráfego de internet através dessas conexões residenciais.

Isso não apenas garante o anonimato do cliente, mas também faz com que o tráfego malicioso (como raspagem de conteúdo em larga escala, fraude de anúncios ou ataques de preenchimento de credenciais) pareça originar-se de um usuário legítimo, dificultando enormemente sua detecção e bloqueio [4].

Conclusão: A Defesa Começa no DNS

O caso da Aisuru é um poderoso lembrete de que o DNS, um dos protocolos fundamentais da internet, permanece como um pilar estratégico tanto para o funcionamento da rede quanto para as operações de cibercriminosos.

A capacidade de uma botnet de usar o DNS para comando e controle de forma resiliente e de expor sua escala através do volume de tráfego de consultas demonstra a criticidade deste vetor. Enquanto domínios maliciosos permanecerem ativos, a operação de ameaças como a Aisuru continuará.

A mitigação eficaz depende de uma defesa proativa do DNS, com o monitoramento e o bloqueio automático de domínios associados a atividades maliciosas, impedindo a comunicação e a propagação dessas redes em escala global.

Referências

[1] Whalen, S. “Defending the cloud: Azure neutralized a record-breaking 15 Tbps DDoS attack”. Azure Infrastructure Blog, Microsoft Tech Community, 17 Nov. 2025. Disponível em: `

[2] Wang, H., Alex.Turing, & Acey9. “The Most Powerful Ever? Inside the 11.5Tbps-Scale Mega Botnet AISURU”. 奇安信 XLab, 15 Set. 2025. Disponível em: `

[3] Krebs, B. “Cloudflare Scrubs Aisuru Botnet from Top Domains List”. Krebs on Security, 5 Nov. 2025. Disponível em: `

[4] Krebs, B. “Aisuru Botnet Shifts from DDoS to Residential Proxies”. Krebs on Security, 28 Out. 2025. Disponível em: `

[5] ALIENVAULT. “LevelBlue – Open Threat Exchange – Pulse 67ba293ff8ebb490de5f6761”. Disponível em: `

Instabilidade na Cloudflare não é um ataque cibernético

Nessa manhã de 18 de novembro de 2025, uma instabilidade global no serviço da Cloudflare causou interrupções generalizadas, afetando o acesso a grandes plataformas como o ChatGPT, X (antigo Twitter) e Canva [2]. Usuários no Brasil e no mundo relataram dificuldades de acesso e mensagens de erro, como a notificação “Please unblock challenges.cloudflare.com to proceed”.

Não há evidências de que a instabilidade da Cloudflare em 18 de novembro de 2025 tenha sido causada por um ataque cibernético. Com base nas declarações oficiais da empresa e nas análises de especialistas, o incidente parece estar relacionado a problemas internos de infraestrutura.

A falha, que começou por volta das 8h da manhã no horário de Brasília, foi atribuída pela Cloudflare a um “pico de tráfego incomum” em sua rede [1].

Se você receber a mensagem “Please unblock challenges.cloudflare.com to proceed“, não é necessário fazer nada. Esta é uma mensagem de erro relacionada à instabilidade interna da Cloudflare, e não um problema de bloqueio no seu dispositivo ou rede.

Veja no final dessa postagem, há um timeline a respeito dessa instabilidade.

Entretanto, este cenário evidencia a profunda dependência da internet global em um número restrito de provedores de infraestrutura. A Cloudflare, que gerencia aproximadamente 20% de todo o tráfego da web, atua como uma camada essencial de segurança e desempenho para milhões de sites [2]. Uma falha em seus sistemas, mesmo que temporária, tem um efeito cascata imediato e visível para usuários em todo o mundo.

O Ataque Recorde à Azure e a Ameaça Crescente das Botnets

Coincidentemente, a instabilidade da Cloudflare ocorreu no dia seguinte à divulgação, pela Microsoft, de detalhes sobre um ataque de negação de serviço (DDoS) de escala recorde que sua plataforma Azure sofreu. Em 24 de outubro de 2025, a infraestrutura da Azure mitigou com sucesso um ataque que atingiu um pico de 15.72 Tbps, originado pela botnet Aisuru [3].

Ainda que alguns veículos estejam especulando que esses eventos estão relacionados, ainda não, até o momento da escrita desse post, nenhuma evidência ou confirmação disso.

Este ataque massivo envolveu mais de 500.000 dispositivos IoT comprometidos, como roteadores e câmeras, e destaca o poder destrutivo que as botnets modernas podem alcançar. Embora a Microsoft tenha conseguido neutralizar a ameaça sem impacto para seus clientes, o episódio serve como um forte indicativo da crescente sofisticação e escala dos ataques cibernéticos contra a infraestrutura de nuvem 3.

Confusão com o Ataque à Azure

Uma fonte significativa de confusão é que duas grandes notícias de cibersegurança foram divulgadas quase simultaneamente:

Notícia 1: Instabilidade da Cloudflare (18 de novembro de 2025)

• Evento atual, em andamento.

• Causa: Pico de tráfego incomum, origem desconhecida.

• Impacto: Interrupção de serviços globais.

Notícia 2: Ataque DDoS à Azure (divulgado em 17-18 de novembro de 2025)

• Evento ocorrido em 24 de outubro de 2025.

• Causa: Ataque DDoS da botnet Aisuru.

• Resultado: Microsoft mitigou com sucesso, sem impacto aos clientes

Importante: O ataque à Azure ocorreu há quase um mês e foi mitigado com sucesso. A Microsoft apenas divulgou os detalhes técnicos do ataque nesta semana. Não há conexão entre o ataque à Azure e a instabilidade da Cloudflare.

Um Alerta para a Infraestrutura Crítica da Internet

Como dito, embora não haja, até o momento, nenhuma evidência que conecte a instabilidade da Cloudflare ao ataque contra a Azure, a ocorrência de dois eventos de tão grande magnitude em um curto espaço de tempo é um alerta contundente. Ambos os incidentes, cada um à sua maneira, expõem as vulnerabilidades inerentes à arquitetura centralizada da internet moderna.

A dependência de poucos grandes players, como Cloudflare, AWS e Azure, significa que uma falha técnica ou um ataque bem-sucedido pode ter consequências globais. A resiliência da internet depende da capacidade dessas empresas de não apenas inovar em segurança e desempenho, mas também de responder rapidamente a incidentes inevitáveis.

Para empresas e desenvolvedores, a lição é clara: a resiliência digital não pode ser terceirizada por completo. É fundamental adotar práticas de contingência, como arquiteturas multi-cloud, monitoramento proativo e planos de resposta a incidentes, para garantir a continuidade dos negócios diante de um cenário de ameaças e falhas cada vez mais complexo.

Referências:

[1] The Guardian. (2025, 18 de novembro). Cloudflare outage causes error messages across the internet.

[2] Reuters. (2025, 18 de novembro). Cloudflare outage easing after impacting thousands of internet users.

[3] Microsoft Azure Infrastructure Blog. (2025, 17 de novembro). Defending the cloud: Azure neutralized a record-breaking 15 Tbps DDoS attack.

Linha do tempo | Instabilidade da Cloudflare

A Cloudflare publicou as seguintes atualizações em sua página de status (referência: Página oficial de status da Cloudflare):

13:35 UTC (10:35 AM horário de Brasília): A empresa continua trabalhando na restauração dos serviços para clientes de serviços de aplicação. Alguns serviços já foram restaurados, mas o trabalho de recuperação ainda está em andamento.

13:13 UTC (10:13 AM horário de Brasília): A Cloudflare implementou mudanças que permitiram a recuperação do Cloudflare Access e do WARP. Os níveis de erro para usuários desses serviços retornaram às taxas anteriores ao incidente. O acesso WARP em Londres foi reabilitado.

13:09 UTC (10:09 AM horário de Brasília): O problema foi identificado e uma correção está sendo implementada.

12:21 UTC (9:21 AM horário de Brasília): A empresa reportou que os serviços estavam se recuperando, mas os clientes ainda poderiam observar taxas de erro acima do normal durante os esforços de remediação.

11:48 UTC (8:48 AM horário de Brasília): Início da investigação oficial do problema, confirmando degradação interna do serviço.

Alerta: Vulnerabilidade Crítica em Equipamentos Fortinet com Exploração Ativa

Alerta Técnico – Vulnerabilidade CVE-2025-64446

Data: 14/11/2025
Severidade: Crítica – CVSS 9.8
Status: Explorada ativamente desde outubro/2025
Produtos afetados: FortiWeb 7.0 a 8.0 (múltiplas versões)

Resumo Executivo

Em 14 de novembro de 2025, a Fortinet e a Agência de Segurança Cibernética e de Infraestrutura dos EUA (CISA) divulgaram um alerta sobre uma vulnerabilidade crítica de Path Traversal (CWE-23) que afeta os produtos FortiWeb, o Web Application Firewall (WAF) da Fortinet. A falha, identificada como CVE-2025-64446, possui uma pontuação CVSSv3 de 9.8 (Crítica) e está sendo ativamente explorada por atacantes desde o início de outubro de 2025 1.

A vulnerabilidade permite que um atacante não autenticado execute comandos administrativos remotos em sistemas vulneráveis, levando a um comprometimento total do dispositivo. A CISA já adicionou esta falha ao seu catálogo de Vulnerabilidades Exploradas Conhecidas (KEV), com um prazo de remediação obrigatório até 21 de novembro de 2025

1. Visão Geral da Vulnerabilidade

A CVE-2025-64446 é uma vulnerabilidade crítica de Path Traversal (CWE-23) combinada com bypass de autenticação, permitindo que um atacante não autenticado execute operações administrativas via CGI (fwbcgi).

Esta é a terceira vulnerabilidade crítica da linha FortiWeb nos últimos 18 meses, reforçando o padrão preocupante de falhas severas na superfície de ataque de dispositivos de borda da Fortinet.

A falha ocorre em dois estágios principais:

  1. Path Traversal no endpoint /api/v2.0/…
  2. Impersonação via header CGIINFO (base64) aceito pela função cgi_auth() sem validação real

O resultado é o comprometimento total do dispositivo FortiWeb, com capacidade de persistência, desvio de políticas de segurança e movimentação lateral na rede.

A falha foi adicionada em 14/11/2025 ao catálogo CISA KEV (Known Exploited Vulnerabilities Catalog) com prazo de mitigação obrigatório até 21/11/2025.

2. Detalhes de Exploração

2.1 Estágio 1 – Path Traversal

No primeiro estágio, o atacante utiliza um endpoint de API válido para escapar do diretório esperado e alcançar o executável administrativo fwbcgi:

POST /api/v2.0/cmd/system/admin%3F/../../../../../cgi-bin/fwbcgi HTTP/1.1

O Path Traversal permite que requisições atinjam o binário fwbcgi, responsável por operações administrativas no dispositivo.

2.2 Estágio 2 – Impersonação via CGIINFO

O binário fwbcgi utiliza a função cgi_auth(), que:

  • não valida corretamente credenciais de autenticação;
  • aceita um header HTTP chamado CGIINFO;
  • confia em informações de identidade fornecidas em JSON, codificadas em Base64.

Exemplo de payload JSON, antes de ser codificado em Base64:

{
  "username": "admin",
  "profname": "super_admin",
  "vdom": "root",
  "loginname": "admin"
}

Quando esse payload é aceito, o sistema concede privilégios administrativos completos, permitindo ao atacante criar novas contas, alterar configurações e manter persistência no dispositivo.

3. Impacto Operacional

Um atacante que explore com sucesso a CVE-2025-64446 pode:

  • Criar usuários administradores persistentes e ocultos;
  • Modificar políticas, regras e perfis de proteção do WAF;
  • Desabilitar ou contornar mecanismos de segurança;
  • Exfiltrar dados inspecionados e registrados pelo WAF;
  • Realizar movimentação lateral a partir do dispositivo comprometido.

Por se tratar de um WAF de borda, a vulnerabilidade abre um vetor crítico para ataques internos a partir de um equipamento que, normalmente, é considerado parte da camada de proteção.

4. Versões Afetadas (Confirmadas)

ProdutoVersões Vulneráveis
FortiWeb 8.08.0.0 – 8.0.1
FortiWeb 7.67.6.0 – 7.6.4
FortiWeb 7.47.4.0 – 7.4.9
FortiWeb 7.27.2.0 – 7.2.11
FortiWeb 7.07.0.0 – 7.0.11

5. Ação Recomendada (Imediata)

5.1 Atualizar Firmware – Única Remediação Definitiva

A Fortinet disponibilizou versões corrigidas. (Fortinet PSIRT FG-IR-25-910). A atualização é a única forma de remediação completa:

Versão AtualAtualizar para
8.0.x8.0.2
7.6.x7.6.5
7.4.x7.4.10
7.2.x7.2.12
7.0.x7.0.12

5.2 Mitigação Temporária (Workaround)

Se a atualização não puder ser aplicada imediatamente, recomenda-se:

  • Bloquear o acesso HTTP/HTTPS externo às interfaces administrativas do FortiWeb;
  • Permitir acesso de administração apenas por redes internas ou via VPN segura;
  • Monitorar tráfego para /cgi-bin/fwbcgi e padrões anômalos envolvendo /api/v2.0/... com Path Traversal.

Atenção: a mitigação reduz a superfície de ataque, mas não elimina a vulnerabilidade. A atualização de firmware continua obrigatória.

6. Indicadores de Comprometimento (IoCs)

6.1 Rede / Proxy / WAF Logs

Procurar por requisições com padrão de Path Traversal direcionadas ao binário CGI:

/api/v2.0/cmd/system/admin%3F/../../../../../cgi-bin/fwbcgi

Além disso, monitorar requisições contendo o header CGIINFO com conteúdo Base64, principalmente oriundas de IPs externos ou não autorizados.

CGIINFO: <string_base64_suspeita>

IPs com múltiplas tentativas de POST para esses caminhos devem ser tratados como suspeitos, com correlação adicional em outros logs.

6.2 Sistema / Configurações

Nos próprios dispositivos FortiWeb, verificar:

  • Criação de novas contas de administrador, principalmente a partir de outubro de 2025;
  • Contas com perfil de acesso prof_admin ou super_admin não reconhecidas pela equipe de segurança;
  • Configurações de trust host definidas como 0.0.0.0/0 ou ::/0 em contas administrativas;
  • Alterações não autorizadas em políticas, perfis, certificados e regras de inspeção.

7. Procedimentos de Resposta a Incidente

Em caso de suspeita de exploração da CVE-2025-64446, recomenda-se o seguinte fluxo para equipes de Blue Team / CERT / CSIRT:

  1. Isolar o dispositivo: restringir acesso administrativo externo, mantendo apenas o mínimo necessário para análise e operação.
  2. Coletar logs: exportar logs de sistema, eventos, auditoria e administração para um servidor seguro de análise.
  3. Revisar contas de usuário: identificar contas administrativas novas ou modificadas, sobretudo com perfis elevados.
  4. Analisar headers CGIINFO: quando possível, decodificar strings Base64 para determinar tentativas de impersonação de administradores.
  5. Aplicar atualização de firmware para as versões corrigidas recomendadas pela Fortinet.
  6. Revalidar configuração: revisar políticas, objetos, perfis e parâmetros de segurança para identificar alterações maliciosas.
  7. Verificar persistência: buscar scripts, agendamentos, acessos remotos ou configurações suspeitas que indiquem backdoors.
  8. Monitorar pós-correção: manter monitoramento reforçado por pelo menos 72 horas após a atualização e a revisão de segurança.

8. Conclusão

A CVE-2025-64446 representa uma vulnerabilidade de alta criticidade em dispositivos FortiWeb, com exploração ativa e baixo nível de complexidade técnica para o atacante. Dispositivos expostos à Internet, principalmente em ambientes de alta criticidade, estão sob risco significativo.

A atualização para versões corrigidas deve ser tratada como prioridade máxima em planos de resposta a incidentes e gestão de vulnerabilidades, especialmente em:

  • Provedores de serviços de Internet (ISPs e provedores regionais);
  • Órgãos públicos e infraestruturas críticas;
  • Instituições financeiras e meios de pagamento;
  • Ambientes acadêmicos com grande exposição de aplicações web;
  • Empresas que utilizam o FortiWeb para proteger aplicações sensíveis.

Equipes de segurança devem tratar essa vulnerabilidade como um incidente de severidade máxima, combinando correção, caça a ameaças (threat hunting) e monitoramento contínuo.

Referências

Cadeia de suprimentos monitorada?

Peguei um caso em que duas pessoas da equipe financeira receberam um e-mail que se passava pelo CEO da empresa. A mensagem autorizava um pagamento de R$ 28.900,00 pelos serviços prestados. A equipe rapidamente identificou que se tratava de uma fraude e reportou o incidente para a área de cibersegurança. Ainda bem!

O atacante criou uma conta @outlook.com utilizando o nome do CEO, tentando conferir legitimidade ao envio (ex.: abc.xyz@outlook.com).

Além disso, ele alterou o campo Display Name da mensagem para o nome completo do executivo e criou uma assinatura com o logo da empresa.

No corpo do e-mail, o fraudador enviava uma chave Pix para a realização do pagamento, sendo essa chave o próprio CNPJ da empresa recebedora.

Até aí tudo comum em um ataque de phishing…

Por curiosidade, busquei informações sobre a empresa fraudadora e, por meio do CNPJ, cheguei até o proprietário. A empresa estava localizada em Arapongas – PR.

Ao analisar o histórico profissional do dono da empresa, encontrei um dado relevante: em 2023, o fraudador havia trabalhado em uma empresa prestadora de serviços para a companhia que agora estava sendo alvo.

Como o ataque foi direcionado, com conhecimento dos e-mails e dos nomes específicos envolvidos no processo de pagamentos, é bem provável que o atacante tenha se apropriado de alguma base contendo dados dos clientes do seu emprego anterior e, agora, estivesse aplicando golpes.

Infelizmente, trata-se de mais um caso típico de falhas de controle em múltiplos processos. A superfície de risco só cresce quando a cadeia de suprimentos não é monitorada de ponta a ponta.

Novo Malware Bancário – “Herodotus”

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.

Mais informações nos links :

https://www[.]cybersecbrazil.com.br/post/novo-malware-para-android-imita-digita%C3%A7%C3%A3o-humana-para-evitar-detec%C3%A7%C3%A3o-e-roubar-dinheiro

https://www[.]cisoadvisor.com.br/novo-malware-bancario-ataca-usuarios-android/?utm_campaign=&utm_medium=email&utm_source=newsletter

Fique atento as configurações de BIOCs

Recentemente, me deparei com um incidente gerado após a detecção de um BIOC, o qual possuía o seguinte título: “Windows LOLBIN executable connected to a rare external host”.

O incidente informava a detecção de uma conexão externa suspeita realizada por um processo nomeado como “sc.exe”. Isso me levou a pensar que o alerta estava fazendo referência ao software nativo e amplamente conhecido do Windows, responsável pelo gerenciamento de serviços, “Service Control” e que o mesmo estaria sendo utilizado para realizar conexões com servidores de “Command and Control“, uma vez que entendo não ser nada comum esse processo realizar conexões externas.

Bom… neste caso, a realidade era bem diferente. Ao aprofundar as investigações, identifiquei que o software nomeado como “sc.exe” e responsável por realizar a conexão externa nada tinha a ver com o processo nativo do Windows “Service Control”. Inclusive, era assinado por outro fabricante. Da mesma forma, realizei todas as verificações necessárias para me certificar de que a conexão detectada não apresentava qualquer risco para o ambiente.

Foi então que me veio a ideia: o fator que levou a essa detecção foi a existência de uma regra de BIOC configurada especificamente para detectar conexões realizadas por processos que possuem como fator de validação apenas “nomes conhecidos do sistema operacional Windows”. Porém, ao surgir um software de terceiros que possui o mesmo nome que um desses processos, a BIOC irá disparar sem qualquer validação prévia, aumentando a chance da geração de falsos positivos…

Ou seja, não seria mais prático e acertivo, adicionar também como um dos requisitos de validação para o disparo desta BIOC a verificação da “Assinatura Digital“? A fim de certificar que apenas processos do sistema Windows sejam responsáveis pela “Trigger” desta regra.

Ataque ao time service chinês. Já pensou no impacto?

Acompanhando algumas notícias recentemente a China acusou a NSA de ter realizado um ataque ao serviço de tempo (National Time Service Center) responsável por manter e transmitir o horário de Pequim

Assim como alguns problemas geopolíticos recentes do Brasil com o Estados Unidos, em que surgiu rumores da possibilidade de bloquearem o serviço de GPS, o Time Service poderia ter causado um grande caos para os chineses, parando serviços como comunicação de rede e até sistemas financeiros.

O mais interessante é que tudo começou por um ataque de triangulação de celulares e em seguida o roubo de credenciais.

E várias vezes já pegamos de problemas de autenticação relacionados ao Active Directory em que a causa raiz era os relógios dessincronizados.

Reforço a atenção para um serviço negligenciado

Link da matéria:

hxxps[://]thehackernews[.]com/2025/10/mss-claims-nsa-used-42-cyber-tools-in[.]html?m=1