A Anthropic revelou que seu projeto de segurança ofensiva defensiva, chamado Project Glasswing, já identificou mais de 10 mil vulnerabilidades de alta ou crítica severidade em softwares amplamente utilizados ao redor do mundo desde o lançamento da iniciativa, ocorrido no mês passado. O programa utiliza um modelo experimental de inteligência artificial chamado Claude Mythos Preview, desenvolvido especificamente para análise autônoma de falhas de segurança em códigos e infraestruturas críticas. Segundo a empresa, o objetivo do Glasswing é fortalecer a segurança de softwares considerados “sistemicamente importantes”, permitindo que equipes defensivas encontrem vulnerabilidades antes que criminosos cibernéticos consigam explorá-las. O acesso ao modelo foi inicialmente restrito a cerca de 50 parceiros estratégicos ligados à segurança ofensiva, pesquisa de vulnerabilidades e proteção de infraestruturas críticas. De acordo com os dados divulgados, 6.202 vulnerabilidades identificadas foram classificadas como falhas de alta ou crítica severidade em mais de mil projetos open source. Após análises técnicas adicionais, 1.726 ocorrências foram confirmadas como verdadeiros positivos, enquanto 1.094 falhas foram consideradas efetivamente críticas ou de alta gravidade. Entre os casos citados pela Anthropic está uma vulnerabilidade crítica descoberta na biblioteca criptográfica WolfSSL, registrada como CVE-2026-5194 e com pontuação CVSS de 9.1. A falha poderia permitir que invasores falsificassem certificados digitais e se passassem por serviços legítimos, comprometendo a confiança em conexões seguras e autenticações criptográficas. A empresa afirmou que os esforços do projeto já resultaram em 97 correções aplicadas diretamente pelos desenvolvedores dos softwares afetados, além da publicação de 88 comunicados oficiais de segurança. A Anthropic reconheceu que a velocidade com que modelos de IA conseguem identificar vulnerabilidades começa a superar significativamente a capacidade das equipes técnicas de corrigir os problemas. Segundo a companhia, esse desequilíbrio representa um dos maiores desafios atuais para a segurança digital. O avanço ocorre em meio a uma crescente adoção de inteligência artificial na descoberta automatizada de falhas. A Microsoft, por exemplo, já afirmou recentemente que espera um aumento contínuo no volume mensal de patches devido à aceleração proporcionada por ferramentas de IA voltadas à pesquisa de vulnerabilidades. A plataforma XBOW, especializada em segurança ofensiva autônoma, descreveu o Mythos Preview como um avanço significativo em relação aos modelos anteriores, destacando sua capacidade de analisar código-fonte com foco em segurança ofensiva e identificar cadeias completas de exploração. Pesquisas recentes também indicam que o modelo apresenta desempenho elevado na transformação de vulnerabilidades isoladas em ataques completos de múltiplas etapas. Além da identificação de falhas técnicas, a Anthropic afirmou que o modelo também demonstrou capacidade operacional em cenários reais de fraude e detecção de ameaças. Em um dos casos apresentados, um banco parceiro do projeto utilizou o Mythos Preview para impedir uma transferência fraudulenta de US$ 1,5 milhão após um invasor comprometer a conta de e-mail de um cliente e utilizar chamadas telefônicas falsas para tentar validar a transação. Diante da evolução dessas capacidades, a Anthropic alertou que modelos semelhantes ao Mythos poderão se tornar amplamente acessíveis no futuro próximo, aumentando drasticamente a velocidade de descoberta e exploração de vulnerabilidades por grupos hackers. Como resposta, a empresa recomenda que organizações reduzam seus ciclos de correção de falhas e acelerem a aplicação de patches críticos. Entre as recomendações estão o endurecimento das configurações padrão de rede, adoção obrigatória de autenticação multifator, melhoria da telemetria de segurança e manutenção de logs completos para detecção e resposta a incidentes. O cenário também começa a provocar mudanças operacionais entre grandes fornecedores de tecnologia. A Oracle, por exemplo, recentemente abandonou ciclos trimestrais para adotar atualizações mensais de segurança voltadas à correção mais rápida de vulnerabilidades críticas. Paralelamente, a Anthropic anunciou um novo programa chamado Cyber Verification Program, que permitirá que profissionais legítimos de segurança utilizem versões dos modelos sem determinados mecanismos restritivos para atividades como pesquisa de vulnerabilidades, pentests e exercícios de red team. A iniciativa segue uma abordagem semelhante ao programa Daybreak, da OpenAI, que disponibiliza o GPT-5.5-Cyber para fluxos especializados de defesa cibernética. Apesar dos avanços, modelos como o Mythos Preview e o GPT-5.5-Cyber ainda não foram disponibilizados publicamente. As empresas envolvidas alegam que ainda não existem salvaguardas suficientes para impedir o uso abusivo dessas tecnologias em larga escala por agentes maliciosos. A Anthropic afirmou que o Glasswing busca fornecer uma vantagem assimétrica para defensores cibernéticos, mas destacou que existe uma necessidade urgente de que organizações reforcem rapidamente suas posturas de segurança diante da evolução acelerada das capacidades ofensivas baseadas em inteligência artificial.

Uma violação de dados em larga escala atingiu hospitais universitários da Alemanha após hackers comprometerem a infraestrutura da Unimed, empresa terceirizada responsável pelo processamento de faturamento de pacientes privados e particulares para diversas instituições médicas do país. O incidente expôs informações pessoais, dados administrativos e, em alguns casos, informações médicas sensíveis relacionadas a diagnósticos e tratamentos. De acordo com os hospitais afetados, o ataque ocorreu em meados de abril, mas os detalhes começaram a ser divulgados publicamente apenas agora. As instituições afirmaram que seus próprios ambientes clínicos e sistemas hospitalares não foram comprometidos, e que o atendimento aos pacientes não sofreu interrupções operacionais. Entre os hospitais impactados estão os centros universitários de Colônia, Freiburg, Heidelberg, Tübingen, Ulm e Mannheim. A quantidade de vítimas varia conforme cada instituição, indicando que o comprometimento pode ter afetado múltiplas bases de dados mantidas pela prestadora de serviços. O Hospital Universitário de Colônia informou que quase 30 mil pessoas tiveram dados acessados pelos invasores. Segundo a instituição, os hackers obtiveram nomes, endereços e informações sobre médicos responsáveis pelos atendimentos. Em mais de 840 casos, também houve exposição de informações adicionais relacionadas à saúde, incluindo comunicações trocadas com a empresa de faturamento. Dados bancários e de pagamento foram comprometidos em cinco casos confirmados. Na região de Baden-Württemberg, outros hospitais também relataram impactos significativos. O Hospital Universitário de Freiburg afirmou que dados pessoais básicos de aproximadamente 54 mil pacientes foram roubados. Em cerca de 900 registros, os invasores também tiveram acesso a informações de faturamento ligadas a diagnósticos ou tratamentos médicos. Já o Hospital Universitário de Heidelberg informou que aproximadamente 11 mil pacientes foram afetados, incluindo cerca de 2.700 casos nos quais informações de cobrança médica podem ter sido expostas. O Hospital Universitário de Ulm relatou cerca de 1.600 vítimas, sendo aproximadamente 300 casos envolvendo dados de diagnóstico e tratamento. As instituições explicaram que a Unimed era responsável pelo processamento administrativo e financeiro de pacientes com seguros privados, seguros complementares e pacientes particulares, incluindo estrangeiros atendidos pelos hospitais alemães. Segundo os hospitais, pacientes cobertos exclusivamente pelo sistema público de saúde estatutário da Alemanha, em geral, não foram afetados pelo incidente. Após a descoberta da invasão, os hospitais interromperam imediatamente a transferência de dados para a prestadora terceirizada. Até o momento, a Unimed não comentou oficialmente o ataque e também não respondeu aos pedidos de esclarecimento feitos pela imprensa internacional. Ainda não há informações públicas sobre a identidade dos responsáveis pela invasão nem detalhes técnicos sobre a cadeia de ataque utilizada. Nenhum grupo de ransomware ou operação de cibercrime reivindicou autoria do incidente até agora. Mesmo sem detalhes técnicos divulgados, o caso reforça os riscos associados à cadeia de fornecedores no setor de saúde, especialmente quando empresas terceirizadas processam informações altamente sensíveis relacionadas a faturamento, histórico médico e tratamentos clínicos. Ataques contra prestadores de serviços externos têm sido utilizados com frequência por grupos hackers para ampliar o impacto de comprometimentos sem precisar invadir diretamente os ambientes hospitalares principais. Além da exposição de dados pessoais, o vazamento de informações médicas pode gerar consequências relevantes para privacidade, reputação e conformidade regulatória, principalmente em países europeus sujeitos às exigências do GDPR, a legislação de proteção de dados da União Europeia. Alguns hospitais informaram que estudam medidas legais contra a prestadora de serviços. O Hospital Universitário de Heidelberg confirmou que registrou uma denúncia criminal contra autores ainda não identificados. “Dados de saúde estão entre os dados mais sensíveis que existem. Seu roubo representa uma grave violação dos direitos das pessoas afetadas”, afirmou Frederik Wenz, diretor médico do Hospital Universitário de Freiburg.

Em um ataque de precisão cirúrgica e escala industrial, uma campanha automatizada identificada como Megalodon comprometeu 5.561 repositórios no GitHub em apenas seis horas — entre 11h36 e 17h48 UTC do dia 18 de maio de 2026. No total, foram enviados 5.718 commits maliciosos, todos projetados para roubar credenciais de ambientes de integração e entrega contínua (CI/CD), chaves de acesso a nuvem e segredos de desenvolvimento. O ataque foi detalhado pela empresa de segurança SafeDep, que mapeou toda a cadeia de comprometimento. Para não levantar suspeitas, os hackers criaram contas descartáveis no GitHub com nomes de usuário aleatórios de oito caracteres — como rkb8el9r, bhlru9nr e lo6wt4t6 — e falsificaram identidades de autores usando nomes que imitam bots legítimos de automação: build-bot, auto-ci, ci-bot e pipeline-bot. As mensagens de commit também foram escolhidas a dedo para parecerem manutenção rotineira de pipeline, reduzindo a chance de que desenvolvedores percebessem algo errado ao revisar o histórico do repositório. Como o ataque funcionou, passo a passo O núcleo técnico do Megalodon está na injeção de arquivos de workflow do GitHub Actions contendo payloads em bash codificados em Base64. Esse tipo de codificação é uma técnica clássica de ofuscação: ao transformar o código malicioso em uma sequência aparentemente inofensiva de caracteres, o hacker dificulta a detecção por ferramentas automáticas de análise de código. Uma vez que um repositório comprometido recebe um merge do commit malicioso, o payload é executado diretamente dentro do pipeline CI/CD da vítima. A partir daí, o código começa a exfiltrar dados para um servidor de comando e controle (C2) localizado no endereço 216.126.225[.]129:8443. A lista do que é roubado é extensa e preocupante: variáveis de ambiente de CI, credenciais da Amazon Web Services (AWS), tokens de acesso do Google Cloud, credenciais de papel de instância obtidas consultando endpoints de metadados de AWS IMDSv2, Google Cloud e Microsoft Azure IMDS, chaves privadas SSH, configurações de Docker e Kubernetes, tokens de Vault, credenciais do Terraform, histórico de comandos shell, chaves de API, strings de conexão com bancos de dados, JWTs, chaves privadas PEM e tokens de nuvem identificados por mais de 30 padrões de expressão regular. Além disso, o malware captura o token OIDC do GitHub Actions, além de tokens do GitHub, GitLab e Bitbucket, e arquivos de configuração como .env, credentials.json e service-account.json. Duas variantes, duas estratégias Pesquisadores identificaram dois tipos de payload na campanha, com abordagens operacionais distintas. A primeira, chamada SysDiag, é uma variante em massa: injeta um novo workflow que dispara a cada push e pull request, garantindo execução automática e ampla cobertura de alvos. A segunda, chamada Optimize-Build, adota uma abordagem mais cirúrgica: é ativada apenas via workflow_dispatch, um gatilho manual do GitHub Actions que exige intervenção explícita do usuário ou de outro sistema. Essa escolha sacrifica alcance em troca de maior sigilo operacional. A lógica por trás da escolha é reveladora. O gatilho on: push garante execução em cada commit ao branch principal, atingindo mais alvos sem intervenção. Já o workflow_dispatch reduz a frequência de disparo, mas torna a atividade menos detectável por sistemas de monitoramento automatizado. Com mais de 5.700 repositórios comprometidos, mesmo uma pequena fração que contenha um GITHUB_TOKEN válido já oferece ao hacker um volume considerável de alvos ativáveis sob demanda. Um dos pacotes diretamente impactados foi o @tiledesk/tiledesk-server, no qual a variante Optimize-Build foi usada especificamente para comprometer runners de CI/CD — e não quando o pacote npm é instalado por usuários finais. O contexto maior: TeamPCP e a era dos ataques de cadeia de suprimentos O Megalodon não existe no vácuo. A campanha se insere num padrão crescente de ataques à cadeia de suprimentos de software, onde a infiltração em ferramentas amplamente utilizadas por desenvolvedores se torna um vetor de infecção massiva e de difícil detecção. O grupo hacker identificado como TeamPCP está no centro desse movimento. Nas últimas semanas, o grupo transformou a cadeia de suprimentos de software open-source em um vetor de ataque encadeado: uma vulnerabilidade explora a próxima, em um efeito dominó que já atingiu projetos como TanStack, Grafana Labs, OpenAI, Mistral AI e, mais recentemente, o próprio GitHub — de propriedade da Microsoft. Em alguns casos, as vítimas foram extorquidas diretamente. O TeamPCP também tem conexões estabelecidas com fóruns underground como o BreachForums e parceria com grupos de extorsão como LAPSUS$ e VECT. Além da motivação financeira, há evidências de motivação geopolítica: o grupo já foi associado ao deploy de malware do tipo wiper — software que apaga dados permanentemente — em máquinas detectadas em Israel e no Irã. O worm Mini Shai-Hulud, associado ao mesmo ecossistema de ataques, levou o npm a tomar uma medida drástica: invalidar todos os tokens de acesso granular com permissão de escrita que contornam a autenticação de dois fatores (2FA). A plataforma também passou a recomendar que mantenedores de pacotes migrem para o sistema de Trusted Publishing, que reduz a dependência de tokens estáticos. A empresa Socket, especializada em segurança de aplicações, foi direta na avaliação da medida: ao invalidar todos os tokens que contornavam o 2FA, o npm cortou as credenciais já coletadas pelo worm. Mas os mantenedores emitem novos tokens. E o worm, ainda ativo, recomeça a coleta. A ação ganha tempo — mas não fecha a brecha estrutural. Pacotes falsos no npm: a ameaça paralela do Polymarket Em paralelo ao Megalodon, pesquisadores identificaram outra operação de comprometimento via supply chain, desta vez focada em usuários de criptomoedas. Uma conta descartável de nome polymarketdev publicou nove pacotes maliciosos no npm em uma janela de apenas 30 segundos, todos se passando por ferramentas legítimas de trading da plataforma Polymarket. Os nomes dos pacotes foram escolhidos para parecerem oficiais: polymarket-trading-cli, polymarket-terminal, polymarket-trade, polymarket-auto-trade, polymarket-copy-trading, polymarket-bot, polymarket-claude-code, polymarket-ai-agent e polymarket-trader. No momento da publicação desta reportagem, todos ainda estavam disponíveis para download no npm. O mecanismo de ataque é elegante em sua crueldade: ao instalar qualquer um desses pacotes, um script postinstall exibe um prompt falso de configuração de carteira, solicitando que o usuário cole sua chave privada de Ethereum ou Polygon. O prompt alega que a chave "fica criptografada" — mas o que acontece na prática é o oposto: a chave é enviada em texto puro para um worker da Cloudflare no endereço: hxxps://polymarketbot.polymarketdev.workers[.]dev/v1/wallets/keys. Para dar credibilidade à operação, o hacker construiu uma interface funcional de trading ao redor do script malicioso e criou um repositório no GitHub para simular legitimidade. A engenharia social, nesse caso, é o vetor principal: o prompt de instalação imita fielmente os fluxos de onboarding de carteiras legítimas, incluindo mascaramento de entrada que simula digitação segura. O que está em jogo Moshe Siman Tov Bustan, da empresa OX Security, foi direto ao ponto: o comprometimento do GitHub pelo TeamPCP foi apenas o início. O que vem a seguir é uma onda contínua — um tsunami de ataques direcionados a desenvolvedores em todo o mundo. A avaliação reflete uma mudança estrutural no cenário de ameaças. Ataques como o Megalodon não visam usuários finais diretamente: eles miram os próprios construtores do ecossistema digital — desenvolvedores, mantenedores de pacotes, equipes de DevOps. Ao comprometer pipelines de CI/CD, os hackers obtêm acesso a credenciais que podem abrir portas para ambientes de produção, infraestrutura de nuvem e dados corporativos sensíveis. Para as empresas, o risco é duplo: há o impacto operacional imediato do roubo de credenciais, e há o risco de reputação e compliance associado ao vazamento de dados de clientes ou de propriedade intelectual. Para desenvolvedores individuais, a ameaça é igualmente concreta — especialmente aqueles que mantêm pacotes open-source amplamente utilizados sem o suporte de uma equipe de segurança dedicada.

A Microsoft confirmou que duas vulnerabilidades críticas presentes no Microsoft Defender estão sendo exploradas ativamente em ataques reais. As falhas envolvem escalonamento local de privilégios e negação de serviço (DoS), afetando diretamente componentes do mecanismo de proteção antimalware da empresa. A vulnerabilidade mais grave, identificada como CVE-2026-41091, recebeu pontuação CVSS 7.8 e permite que invasores obtenham privilégios SYSTEM — o nível mais alto de acesso no Windows. Segundo a Microsoft, o problema está relacionado a uma falha de resolução inadequada de links antes do acesso a arquivos, conhecida como “link following”. Esse comportamento pode permitir que um invasor autenticado abuse do Defender para elevar privilégios localmente dentro do sistema operacional. Já a segunda falha, registrada como CVE-2026-45498, é uma vulnerabilidade de negação de serviço com pontuação CVSS 4.0. Embora menos crítica em termos de impacto técnico, ela também já está sendo explorada em ambientes reais. O defeito afeta o funcionamento do Defender e pode comprometer a disponibilidade do mecanismo de proteção da plataforma. As duas vulnerabilidades foram corrigidas nas versões 1.1.26040.8 e 4.18.26040.7 da plataforma Microsoft Defender Antimalware. A Microsoft informou que sistemas com o Defender desativado não são afetados e destacou que as atualizações são distribuídas automaticamente por meio do mecanismo padrão de atualização de assinaturas e engine antimalware. Apesar da confirmação de exploração ativa, a empresa ainda não divulgou detalhes técnicos sobre os vetores de ataque utilizados pelos invasores. Esse tipo de retenção de informação costuma ocorrer para evitar que grupos maliciosos acelerem campanhas de exploração antes que a maioria dos ambientes esteja corrigida. A gravidade do cenário levou a Agência de Segurança Cibernética e Infraestrutura dos Estados Unidos, a Cybersecurity and Infrastructure Security Agency, a adicionar ambas as falhas ao catálogo Known Exploited Vulnerabilities (KEV). Com isso, agências federais civis norte-americanas passaram a ser obrigadas a aplicar as correções até 3 de junho de 2026. A Microsoft também creditou cinco pesquisadores pela descoberta e divulgação responsável das falhas, incluindo Sibusiso, Diffract, Andrew C. Dorman (ACD421), Damir Moldovanov e um pesquisador anônimo. Para verificar se o sistema está protegido, a Microsoft recomenda acessar o Windows Security, navegar até “Virus & threat protection”, selecionar “Protection Updates” e confirmar se as versões mais recentes da plataforma antimalware já foram instaladas. O alerta surge poucos dias após a Microsoft divulgar outra vulnerabilidade explorada ativamente, desta vez afetando versões on-premise do Exchange Server. A falha CVE-2026-42897, classificada com CVSS 8.1, envolve cross-site scripting (XSS) e já estaria sendo utilizada em ataques reais contra ambientes corporativos. Além das novas vulnerabilidades, a CISA também adicionou ao catálogo KEV diversas falhas antigas da Microsoft, incluindo problemas históricos do Internet Explorer, DirectX e Windows Server Service, alguns datados de 2008, 2009 e 2010. Entre eles está a CVE-2008-4250, famosa vulnerabilidade do serviço RPC do Windows explorada por worms e ataques automatizados ao longo dos anos. Outro destaque foi a inclusão da CVE-2009-3459, uma vulnerabilidade de corrupção de memória no Adobe Acrobat e Reader capaz de permitir execução remota de código por meio de arquivos PDF maliciosos. A movimentação reforça uma tendência observada nos últimos meses: a exploração contínua de vulnerabilidades antigas e recentes em ambientes Windows corporativos, muitas vezes combinadas em cadeias de ataque para escalonamento de privilégios, evasão de segurança e movimentação lateral dentro das redes.

Um novo exploit de prova de conceito (PoC) voltado para o kernel Linux está preocupando pesquisadores e administradores de sistemas após a divulgação pública da vulnerabilidade CVE-2026-31635, apelidada de DirtyDecrypt ou DirtyCBC. A falha permite escalonamento local de privilégios (LPE), possibilitando que usuários sem privilégios obtenham acesso root em sistemas vulneráveis. A vulnerabilidade foi identificada pelas equipes da Zellic e V12 Security em maio de 2026 e afeta especificamente o mecanismo rxgk_decrypt_skb() do kernel Linux. O problema ocorre devido à ausência de uma proteção Copy-on-Write (COW), mecanismo utilizado pelo Linux para impedir que gravações em páginas compartilhadas de memória afetem outros processos. Sem essa proteção, invasores conseguem modificar diretamente áreas críticas da memória e até arquivos privilegiados no page cache do sistema. Segundo os pesquisadores, a falha impacta distribuições que utilizam CONFIG_RXGK, incluindo Fedora, Arch Linux e openSUSE Tumbleweed. Em ambientes containerizados, o problema também representa risco adicional, já que nós vulneráveis podem abrir caminho para escape de containers e comprometimento do host. A exploração da DirtyDecrypt pode permitir alterações em arquivos extremamente sensíveis, como /etc/shadow, /etc/sudoers e binários SUID, comprometendo completamente a integridade do sistema operacional. A técnica segue a mesma linha de outras vulnerabilidades recentes do Linux, como Copy Fail, Dirty Frag e Fragnesia, todas associadas a falhas envolvendo manipulação incorreta de memória compartilhada e page cache no kernel. O cenário chamou atenção da comunidade Linux devido à velocidade com que novas variantes vêm sendo descobertas. O caso ganhou ainda mais repercussão após pesquisadores divulgarem detalhes técnicos e PoCs antes do encerramento completo do período de embargo coordenado, acelerando o risco de weaponização por grupos maliciosos. Um dos pesquisadores envolvidos afirmou que conseguiu transformar rapidamente um patch público em um exploit funcional, prática conhecida como “n-day weaponization”. Além da DirtyDecrypt, outras falhas recentes elevaram o alerta em torno da segurança do kernel Linux. Entre elas está a CVE-2026-46333, apelidada de “ssh-keysign-pwn”, capaz de expor segredos pertencentes ao usuário root, incluindo chaves SSH privadas. Diversas distribuições já publicaram atualizações e alertas de segurança relacionados ao problema, incluindo Red Hat, Ubuntu, Fedora, SUSE, Gentoo e Amazon Linux. O aumento da frequência dessas vulnerabilidades levou desenvolvedores do kernel Linux a discutirem a criação de um mecanismo emergencial chamado “killswitch”. A proposta permitiria que administradores desativassem funções vulneráveis do kernel em tempo de execução até que patches oficiais fossem disponibilizados. A funcionalidade atuaria como uma mitigação temporária contra zero-days críticos em ambientes produtivos. Paralelamente, o Rocky Linux anunciou um novo repositório opcional focado em atualizações emergenciais de segurança. A iniciativa busca acelerar a entrega de correções em situações nas quais exploits públicos surgem antes da disponibilidade de patches oficiais upstream. Segundo os mantenedores, o recurso será opcional para preservar a estabilidade tradicional da distribuição, mas poderá ser ativado por administradores que precisem responder rapidamente a ameaças críticas. A sequência de falhas envolvendo page cache, Copy-on-Write e subsistemas criptográficos do kernel reforça a pressão sobre administradores Linux para manter sistemas atualizados e monitorar rapidamente novas divulgações de segurança. Em ambientes corporativos e cloud, especialmente aqueles com workloads críticos e containers compartilhados, a exploração dessas vulnerabilidades pode resultar em comprometimento completo da infraestrutura.

Pesquisadores de cibersegurança identificaram quatro pacotes maliciosos publicados no repositório npm contendo malwares voltados para roubo de informações e ataques distribuídos de negação de serviço (DDoS). Um dos pacotes analisados traz uma cópia praticamente direta do worm Shai-Hulud, código malicioso que havia sido vazado publicamente pelo grupo TeamPCP. Os pacotes identificados são “chalk-tempalte”, “@deadcode09284814/axios-util”, “axois-utils” e “color-style-utils”. Apesar de todos terem sido publicados pelo mesmo usuário, identificado como “deadcode09284814”, cada biblioteca possuía cargas maliciosas diferentes embutidas no código. Segundo a OX Security, o pacote “chalk-tempalte” contém um clone funcional do Shai-Hulud, reutilizando praticamente sem alterações o código divulgado publicamente dias antes. O malware foi adaptado com um servidor de comando e controle próprio e uma chave privada específica do operador da campanha. O Shai-Hulud ficou conhecido recentemente após ser associado a ataques de supply chain contra desenvolvedores, comprometendo ambientes de desenvolvimento para roubo de credenciais, tokens e acesso a plataformas como GitHub. No caso da nova campanha, as credenciais roubadas eram enviadas para um servidor remoto identificado como “87e0bbc636999b.lhr[.]life”. Além disso, o malware utilizava os tokens GitHub capturados para criar automaticamente novos repositórios públicos através da API da plataforma. Esses repositórios recebiam a descrição “A Mini Sha1-Hulud has Appeared”, funcionando como possível mecanismo de propagação e rastreamento das infecções. Outro pacote analisado, “axois-utils”, foi desenvolvido para instalar o Phantom Bot, uma botnet escrita em Golang com capacidade de executar ataques DDoS utilizando protocolos HTTP, TCP e UDP. A ferramenta também implementava persistência em sistemas Windows e Linux, adicionando o malware à pasta de inicialização do Windows e criando tarefas agendadas para garantir execução contínua após reinicializações. Já os pacotes “@deadcode09284814/axios-util” e “color-style-utils” apresentavam funcionalidades típicas de infostealers. As cargas maliciosas coletavam chaves SSH, variáveis de ambiente, credenciais cloud, informações do sistema operacional, endereço IP da vítima e dados relacionados a carteiras de criptomoedas. Os dados roubados eram enviados para os endereços “80.200.28[.]28:2222” e “edcf8b03c84634.lhr[.]life”. Segundo os pesquisadores, o uso simultâneo de diferentes técnicas e malwares indica uma evolução rápida nas campanhas de supply chain direcionadas ao ecossistema JavaScript e npm. A investigação também destaca o impacto do vazamento público do código do Shai-Hulud. Para a OX Security, a disponibilidade open source do worm reduziu significativamente a barreira técnica para novos ataques, permitindo que outros operadores reutilizem rapidamente o código em campanhas próprias de comprometimento da cadeia de suprimentos. O cenário preocupa especialmente porque ataques desse tipo exploram a confiança natural existente em bibliotecas de terceiros amplamente utilizadas por desenvolvedores e pipelines de CI/CD. Técnicas de typo-squatting — quando pacotes usam nomes muito parecidos com bibliotecas legítimas — continuam sendo uma das principais formas de distribuição de malware dentro do ecossistema npm. Os pesquisadores recomendam que usuários que baixaram qualquer um dos pacotes removam imediatamente as bibliotecas comprometidas, revisem configurações maliciosas em IDEs e agentes de codificação como Claude Code, rotacionem credenciais e segredos expostos, além de verificar a existência de repositórios GitHub contendo a descrição “A Mini Sha1-Hulud has Appeared”. Também foi recomendada a implementação de bloqueios de rede para os domínios e endereços utilizados pelos operadores da campanha, reduzindo o risco de exfiltração adicional de dados ou persistência do malware nos ambientes comprometidos.

Uma nova análise sobre o malware Fast16, baseado em Lua, confirmou que a ferramenta foi projetada para sabotagem cibernética contra simulações de testes de armas nucleares. Segundo equipes da Symantec, da Broadcom, e da Carbon Black, o Fast16 foi desenvolvido para corromper simulações de compressão de urânio, uma etapa considerada central no projeto de armas nucleares. De acordo com a análise, o mecanismo de hooks do Fast16 tinha interesse seletivo em simulações de alto explosivo executadas em softwares como LS-DYNA e AUTODYN. O malware verificava a densidade do material simulado e só entrava em ação quando esse valor ultrapassava 30 g/cm³, um limite associado à compressão por choque do urânio em um dispositivo de implosão. A descoberta aprofunda uma investigação apresentada semanas antes pela SentinelOne, que descreveu o Fast16 como possivelmente o primeiro framework de sabotagem cibernética conhecido, com componentes que podem ter sido desenvolvidos ainda em 2005. Isso colocaria a ferramenta cerca de dois anos antes das primeiras versões conhecidas do Stuxnet, malware usado posteriormente contra centrífugas de enriquecimento de urânio no Irã. O nome “fast16” apareceu em um arquivo de texto vazado em 2017 pelo grupo The Shadow Brokers. O material fazia parte de um grande conjunto de ferramentas e exploits supostamente ligados ao Equation Group, um agente estatal frequentemente associado à Agência de Segurança Nacional dos Estados Unidos, a NSA. No centro da operação estavam 101 regras capazes de alterar cálculos matemáticos realizados por programas de engenharia e simulação usados na época. Inicialmente, a SentinelOne havia apontado três possíveis alvos: LS-DYNA versão 970, Practical Structural Design and Construction Software, conhecido como PKPM, e Modelo Hidrodinâmico, ou MOHID. A nova análise da Symantec e da Carbon Black confirmou que LS-DYNA e AUTODYN estavam entre os alvos do Fast16. Ambos são usados para simular problemas físicos do mundo real, incluindo resistência de veículos a colisões, modelagem de materiais e simulações de explosivos. No caso do Fast16, os hooks eram ativados apenas durante execuções completas de explosões transitórias e detonações, sugerindo uma interferência cuidadosamente planejada para alterar resultados sem chamar atenção em testes comuns. As 101 regras foram organizadas em cerca de 9 a 10 grupos de hooks, cada um voltado a diferentes versões do LS-DYNA ou do AUTODYN. Para os pesquisadores, isso indica que os desenvolvedores acompanhavam atualizações dos softwares e adicionavam suporte a novas versões ao longo do tempo. Em alguns casos, um grupo de hooks para uma versão anterior teria sido adicionado depois de outro voltado a uma versão mais recente, o que sugere que os usuários afetados poderiam ter voltado para versões antigas ao perceberem anomalias nos resultados. O Fast16 também foi criado para evitar infecção em computadores que tivessem determinados produtos de segurança instalados. Além disso, ele tinha capacidade de se espalhar automaticamente para outros endpoints na mesma rede, garantindo que qualquer máquina usada para executar as simulações produzisse saídas adulteradas de maneira consistente. Os achados indicam que operações de sabotagem industrial altamente especializadas já eram conduzidas por agentes estatais há cerca de 20 anos, antes mesmo do Stuxnet se tornar conhecido por atacar controladores lógicos programáveis da Siemens na usina nuclear de Natanz, no Irã. Para Vikram Thakur, diretor técnico da Symantec, o nível de conhecimento necessário para desenvolver um malware desse tipo em 2005 é considerado impressionante. A ferramenta exigia domínio não apenas de engenharia reversa e desenvolvimento de malware, mas também de física aplicada, simulação numérica, explosivos, modelos de estado da matéria e comportamento de softwares científicos específicos. Ainda não há confirmação sobre a existência de uma versão moderna do Fast16 em circulação. Mesmo assim, os pesquisadores afirmam que o framework pertence à mesma linhagem conceitual do Stuxnet: malware criado não apenas para atacar um produto de determinado fornecedor, mas para interferir em um processo físico específico, seja ele simulado ou controlado por software. O caso amplia a compreensão sobre a evolução da sabotagem cibernética patrocinada por Estados. Em vez de apenas roubar dados ou interromper sistemas, o Fast16 teria sido desenhado para comprometer a confiança nos resultados de simulações críticas, afetando diretamente pesquisas sensíveis e decisões técnicas relacionadas ao desenvolvimento de armas nucleares.

Um novo zero-day no Microsoft Windows está chamando atenção da comunidade de segurança após a divulgação de um proof-of-concept (PoC) funcional capaz de conceder privilégios SYSTEM mesmo em máquinas totalmente atualizadas. A falha, apelidada de MiniPlasma, foi divulgada pelo pesquisador conhecido como Chaotic Eclipse, o mesmo responsável pelas recentes vulnerabilidades YellowKey e GreenPlasma. Segundo o pesquisador, o problema afeta o driver “cldflt.sys”, componente ligado ao Windows Cloud Files Mini Filter Driver. A vulnerabilidade está localizada em uma rotina chamada “HsmOsBlockPlaceholderAccess” e teria sido originalmente reportada à Microsoft em setembro de 2020 pelo pesquisador James Forshaw, do Google Project Zero. Na época, acreditava-se que a vulnerabilidade havia sido corrigida pela Microsoft em dezembro de 2020 por meio da atualização relacionada à CVE-2020-17103. No entanto, Chaotic Eclipse afirma que novas análises revelaram que “o mesmo problema continua presente e sem correção” mesmo após anos de patches e atualizações de segurança. De acordo com o pesquisador, o PoC original desenvolvido pelo Google Project Zero continua funcionando sem necessidade de alterações. Para demonstrar o impacto da falha, ele modificou o exploit para abrir um shell com privilégios SYSTEM, o nível mais alto de acesso disponível no Windows. O ataque explora uma race condition, um tipo de vulnerabilidade que ocorre quando múltiplos processos acessam simultaneamente um recurso crítico do sistema em uma sequência inesperada. Esse tipo de exploração costuma ser mais difícil de reproduzir com estabilidade, mas o pesquisador afirma que o exploit funciona de maneira confiável em seus testes, embora a taxa de sucesso possa variar dependendo do ambiente. Outro ponto que elevou a preocupação da comunidade é o fato de que praticamente todas as versões do Windows podem estar vulneráveis. Em publicação na rede Mastodon, o pesquisador Will Dormann afirmou que o MiniPlasma consegue abrir um “cmd.exe” com privilégios SYSTEM de forma confiável em sistemas Windows 11 executando as atualizações mais recentes de maio de 2026. Dormann destacou, porém, que o exploit aparentemente não funciona nas versões mais recentes do canal Insider Preview Canary do Windows 11, o que pode indicar que mudanças internas mais recentes no sistema operacional acabaram mitigando o problema, ainda que sem anúncio oficial da Microsoft. A descoberta também reacende o alerta em torno do componente “cldflt.sys”. Em dezembro de 2025, a própria Microsoft corrigiu outra vulnerabilidade de escalonamento de privilégios no mesmo driver, identificada como CVE-2025-62221, com pontuação CVSS 7.8. Segundo a empresa, essa falha já vinha sendo explorada ativamente por invasores não identificados. O caso reforça um cenário cada vez mais frequente em ambientes Windows: vulnerabilidades antigas consideradas corrigidas acabam ressurgindo anos depois, seja por correções incompletas, regressões em atualizações posteriores ou mudanças internas no sistema operacional. Para equipes de segurança, isso amplia a complexidade da gestão de risco, principalmente porque falhas de privilege escalation são frequentemente utilizadas após o comprometimento inicial para obtenção de controle total da máquina, evasão de mecanismos de defesa e movimentação lateral dentro de redes corporativas.

Fabricantes amplamente utilizados em ambientes corporativos divulgaram correções para uma série de vulnerabilidades críticas que podem permitir desde bypass de autenticação até execução remota de código e escalonamento de privilégios em sistemas comprometidos. Entre os fornecedores afetados estão Ivanti, Fortinet, SAP, Broadcom e a plataforma de automação n8n. A vulnerabilidade mais severa da lista afeta o Ivanti Xtraction. Identificada como CVE-2026-8043, a falha recebeu pontuação CVSS 9.6 e permite que invasores autenticados leiam arquivos sensíveis e gravem arquivos HTML arbitrários em diretórios web da aplicação. Segundo a empresa, o problema está relacionado ao controle inadequado de nomes de arquivos, o que pode resultar em vazamento de informações e ataques client-side. A correção foi disponibilizada na versão 2026.2. A Fortinet também divulgou atualizações para duas falhas críticas em produtos amplamente utilizados em ambientes corporativos. A CVE-2026-44277 impacta o FortiAuthenticator e pode permitir que um invasor não autenticado execute código ou comandos arbitrários por meio de requisições manipuladas. Já a CVE-2026-26083 afeta o FortiSandbox, incluindo as versões Cloud e PaaS, permitindo execução não autorizada de código via interface web HTTP. As vulnerabilidades foram corrigidas em diferentes versões das plataformas afetadas. No ecossistema da SAP, duas falhas críticas chamaram atenção por envolverem SQL Injection e ausência de autenticação adequada. A CVE-2026-34260 afeta o SAP S/4HANA e pode ser explorada por invasores autenticados com baixo privilégio para injetar comandos SQL maliciosos e acessar informações sensíveis do banco de dados. Embora a falha não permita alteração direta dos dados, ela pode comprometer confidencialidade e disponibilidade da aplicação. A segunda vulnerabilidade da SAP, CVE-2026-34263, afeta o ambiente de configuração do SAP Commerce Cloud. De acordo com a análise divulgada, regras de segurança excessivamente permissivas e verificações inadequadas de autenticação permitem que usuários não autenticados realizem upload de configurações maliciosas e injeção de código, resultando em execução arbitrária no lado do servidor. A Broadcom também corrigiu uma vulnerabilidade de alta severidade no VMware Fusion. A falha, identificada como CVE-2026-41702, envolve uma condição TOCTOU (Time-of-check Time-of-use) em um binário SETUID, permitindo que usuários locais sem privilégios administrativos elevem permissões até nível root. O problema foi corrigido na versão 26H1 da plataforma. Outro destaque do pacote de correções envolve o n8n, que recebeu patches para cinco vulnerabilidades críticas ligadas principalmente a técnicas de prototype pollution. Essas falhas podem ser exploradas por usuários autenticados com permissão para criar ou modificar workflows, permitindo execução remota de código no host do n8n. Parte dos problemas envolve o parser XML baseado na biblioteca xml2js, enquanto outras falhas exploram parâmetros não validados em nodes HTTP e Git. Em um dos cenários, invasores conseguem injetar flags de linha de comando para leitura arbitrária de arquivos do servidor e comprometimento total do ambiente. Além dessas correções, diversos outros fabricantes divulgaram atualizações de segurança recentemente, incluindo Cisco, Microsoft, Google, Apple, Palo Alto Networks, Sophos, Zoom e diversas distribuições Linux.

Usuários do Google Cloud estão enfrentando cobranças inesperadas de milhares de dólares após terem suas chaves de API utilizadas por invasores para executar cargas massivas de inteligência artificial usando modelos avançados de geração de vídeo e imagem da própria Google. Os relatos vêm se espalhando em fóruns como Reddit e redes sociais, envolvendo desenvolvedores que normalmente possuíam contas com baixo consumo mensal e, de repente, passaram a receber cobranças relacionadas a serviços como Veo 3 e Gemini, ferramentas de IA generativa com custo elevado por processamento. Segundo os afetados, o problema vai além de simples vazamento de credenciais. Muitos afirmam que estavam seguindo exatamente as recomendações oficiais do Google ao utilizar determinadas chaves de API em aplicações públicas, principalmente integrações envolvendo Google Maps. Um dos casos mais comentados envolve Rod Danan, CEO da Prentus, empresa que desenvolve plataformas de preparação para entrevistas e monitoramento de empregabilidade em universidades. Ele utilizava APIs do Google Maps em seu produto e mantinha gastos mensais abaixo de US$ 50. Em março, Danan recebeu alertas sucessivos informando cobranças de US$ 3 mil, depois US$ 5 mil e, minutos depois, mais de US$ 10 mil em consumo de APIs. Segundo ele, os valores estavam ligados principalmente ao uso de tokens de geração de vídeo do Veo 3 e geração de imagens do Gemini — serviços que jamais haviam sido utilizados por sua empresa. O executivo afirma que possuía limites de gastos configurados na conta, mas isso não impediu o aumento exponencial das cobranças. Em poucos minutos, o cartão de crédito já havia acumulado US$ 10.138 em despesas indevidas antes que ele conseguisse desativar as APIs comprometidas. A situação se tornou ainda mais controversa após pesquisadores apontarem que o problema pode estar relacionado à reutilização de chaves API originalmente criadas para Google Maps. Durante anos, o próprio Google orientava desenvolvedores a expor essas chaves no frontend de aplicações web para integração de mapas públicos. O pesquisador Joe Leon, da Truffle Security, revelou que cerca de três anos atrás o Google passou a permitir que algumas dessas mesmas chaves também fossem utilizadas para acessar modelos Gemini. Isso criou um cenário no qual APIs originalmente consideradas seguras para exposição pública passaram a fornecer acesso indireto a serviços de IA extremamente caros. Segundo Leon, milhares de sites ainda mantêm essas chaves publicamente expostas. A investigação identificou aproximadamente 3 mil APIs vulneráveis utilizando o prefixo “AIza”, padrão comum em chaves do Google Maps que posteriormente ganharam permissões adicionais relacionadas ao Gemini. Na prática, invasores conseguem localizar essas credenciais em repositórios públicos, páginas web ou aplicações frontend e então abusar dos recursos de IA para executar inferências massivas, gerar imagens, vídeos e consumir grandes volumes computacionais em questão de minutos. Outro caso citado envolve o desenvolvedor australiano Isuru Fonseka, usuário do Google Cloud há cerca de dez anos. Ele afirmou possuir um limite rígido de orçamento configurado em aproximadamente AUD$ 250, mas ainda assim sofreu cobranças que ultrapassaram AUD$ 17 mil. Segundo Fonseka, o ataque gerou consumo tão fora do padrão que sua própria operadora de cartão começou a bloquear automaticamente parte das transações. Ainda assim, diversos pagamentos foram processados com sucesso antes que ele conseguisse entender o que estava acontecendo. A investigação revelou um detalhe importante sobre o funcionamento interno do Google Cloud. O Google confirmou que seu sistema pode aumentar automaticamente os limites de gastos de contas conforme determinados critérios são atingidos. Entre eles estão tempo de conta superior a 30 dias e histórico acumulado de pagamentos acima de US$ 1 mil. Isso significa que contas inicialmente limitadas a pequenas quantias podem ser promovidas automaticamente para faixas de consumo que variam entre US$ 20 mil e US$ 100 mil sem necessidade de aprovação manual do usuário. A mudança faz parte de uma política anunciada pelo Google em março, criada para facilitar acesso a quotas maiores da API Gemini. Segundo a empresa, o sistema “automaticamente promove” usuários para novos níveis conforme o uso cresce. Especialistas alertam que esse comportamento reduz drasticamente a efetividade de mecanismos tradicionais de controle financeiro em ambientes cloud. Mesmo usuários que configuram budgets e alertas podem acabar expostos caso credenciais sejam comprometidas. O Google afirma que o problema não é específico de sua plataforma e que se trata de uma questão recorrente em toda a indústria cloud envolvendo vazamento de credenciais, principalmente APIs publicadas inadvertidamente em GitHub e aplicações públicas. A empresa recomenda MFA, restrições por IP, limitação de APIs específicas e segmentação adequada de permissões. Ainda assim, pesquisadores destacam que a situação evidencia um risco crescente envolvendo IA generativa integrada a plataformas cloud. APIs originalmente consideradas de baixo risco podem se transformar em vetores financeiros altamente críticos quando associadas a modelos avançados de inferência, capazes de consumir milhares de dólares em poucos minutos. Os relatos também expõem outro problema operacional: o tempo de resposta para investigação. Segundo os usuários afetados, o suporte do Google demorava até 36 horas para conseguir visualizar detalhes completos do consumo suspeito, enquanto as cobranças continuavam ocorrendo em tempo real. Após a repercussão pública do caso, o Google acabou reembolsando alguns dos clientes entrevistados pela imprensa. Mesmo assim, a empresa indicou que continuará mantendo a política de expansão automática de limites de consumo.

A discussão sobre inteligência artificial aplicada à segurança ofensiva ganhou um novo capítulo após pesquisadores demonstrarem que modelos avançados de IA não apenas conseguem identificar vulnerabilidades em softwares, mas também desenvolver exploits funcionais capazes de comprometer sistemas reais. O estudo foi conduzido por pesquisadores da UC Berkeley, Max Planck Institute for Security and Privacy, UC Santa Barbara, Arizona State University, além de equipes da Anthropic, OpenAI e Google. O grupo criou uma plataforma chamada ExploitGym, desenvolvida especificamente para medir a capacidade de agentes de IA em transformar falhas de segurança em ataques práticos. Model Agent Total U B K Cost (USD) Time (min) Succ. Full Succ. Full Claude Mythos Preview † Claude Code 157 107 38 12 – – 54.7 102.1 Claude Opus 4.6 † Claude Code 15 12 2 1 8.08 21.76 18.1 66.7 Claude Opus 4.7 Claude Code 7 4 3 0 8.64 3.40 22.1 14.4 Gemini 3.1 Pro Gemini CLI 12 10 2 0 8.56 9.02 51.1 75.6 GLM-5.1 Claude Code 4 4 0 0 3.75 6.39 63.3 118.0 GPT-5.4 Codex CLI 54 38 15 1 12.20 25.43 51.1 103.5 GPT-5.5 ‡ Codex CLI 120 71 27 22 22.99 34.55 49.6 69.8 U = Userspace · B = Browser V8 · K = Kernel · Succ. = successful runs · Full = full benchmark · † preview model · ‡ see notes A proposta do benchmark é avaliar um cenário muito mais crítico do que a simples descoberta de bugs. Na prática, encontrar vulnerabilidades nem sempre significa que elas possam ser exploradas de forma útil por invasores. Muitas falhas são consideradas de baixo impacto, difíceis de explorar ou dependem de condições extremamente específicas. O diferencial do estudo foi justamente testar se os modelos seriam capazes de criar cadeias reais de exploração. O ExploitGym utiliza 898 vulnerabilidades reais encontradas em aplicações, no motor JavaScript V8 do Google Chrome e também no kernel Linux. Os agentes recebem uma vulnerabilidade acompanhada de uma prova de conceito inicial que aciona a falha. A partir daí, precisam desenvolver um exploit funcional capaz de alcançar execução arbitrária de código. Os resultados chamaram atenção principalmente pelo desempenho dos modelos mais avançados. O Claude Mythos Preview, da Anthropic, conseguiu explorar com sucesso 157 instâncias durante uma janela de duas horas. Já o GPT-5.5 alcançou 120 explorações bem-sucedidas no mesmo período. Segundo os pesquisadores, parte dos exploits continuou funcionando mesmo com mecanismos modernos de proteção habilitados, incluindo ASLR (Address Space Layout Randomization) e o sandbox do V8. Essas tecnologias são amplamente utilizadas para dificultar exploração de memória e isolamento de processos em navegadores e sistemas operacionais. Um dos pontos mais preocupantes observados no estudo foi a capacidade dos modelos de agir “fora do roteiro”. Em diversos testes de Capture The Flag (CTF), os agentes ignoraram deliberadamente a vulnerabilidade originalmente proposta e encontraram caminhos alternativos para obter acesso ou capturar as flags escondidas. O comportamento foi especialmente evidente no Claude Mythos Preview e no GPT-5.5. O Mythos completou 226 desafios CTF, mas utilizou a vulnerabilidade esperada em apenas 157 casos. O GPT-5.5 capturou 210 flags, usando a falha originalmente indicada em somente 120 situações. Isso significa que os modelos frequentemente descobriram novas vulnerabilidades durante o processo de exploração. Os pesquisadores destacam que diferentes modelos encontraram diferentes caminhos de exploração, com baixa sobreposição entre alguns ataques identificados. Na prática, isso sugere que múltiplos modelos podem ser utilizados simultaneamente tanto em cenários ofensivos quanto defensivos, aumentando significativamente a superfície de descoberta de falhas. O estudo avaliou agentes como Claude Code utilizando Claude Opus 4.6, Opus 4.7 e Mythos Preview; Codex CLI com GPT-5.4 e GPT-5.5; além do Gemini CLI com Gemini 3.1 Pro. Mesmo modelos mais antigos conseguiram desenvolver alguns exploits funcionais. Os testes foram executados com os mecanismos de segurança e guardrails desativados. Quando os pesquisadores repetiram os testes com os filtros de segurança padrão do GPT-5.5 habilitados, o modelo recusou 88,2% das tentativas antes mesmo de executar ferramentas auxiliares. Apesar disso, o relatório ressalta que pesquisadores de segurança já demonstraram diversas técnicas de prompt engineering capazes de contornar esses mecanismos de recusa. Isso reforça uma preocupação crescente dentro da indústria: os guardrails atuais podem reduzir riscos acidentais, mas ainda possuem limitações significativas diante de usuários experientes. O trabalho reacende o debate sobre o impacto da IA generativa na segurança ofensiva. Até pouco tempo, o principal temor era que modelos ajudassem apenas na descoberta automatizada de vulnerabilidades. Agora, os pesquisadores argumentam que a exploração autônoma de falhas já deixou de ser uma hipótese teórica. Segundo os autores do estudo, os agentes atuais ainda não conseguem explorar todos os tipos de alvo com alta confiabilidade, mas já demonstram capacidade suficiente para comprometer uma parcela relevante de vulnerabilidades reais, incluindo componentes complexos como o kernel Linux. O avanço pode alterar profundamente tanto operações ofensivas quanto estratégias de defesa. Ferramentas automatizadas capazes de desenvolver exploits em larga escala podem acelerar testes de segurança legítimos, mas também reduzir drasticamente a barreira técnica para campanhas maliciosas, descoberta de zero-days e ataques automatizados conduzidos por grupos hackers ou operações estatais.

A Europa vem acelerando investimentos em iniciativas de nuvem soberana para reduzir sua dependência tecnológica e jurídica dos Estados Unidos. Programas como o IPCEI-CIS, da União Europeia, já movimentam mais de €2 bilhões em infraestrutura, enquanto a França fortalece o modelo SecNumCloud, considerado um dos frameworks de certificação de cloud mais rígidos do continente. O objetivo é garantir que dados sensíveis europeus permaneçam protegidos contra leis extraterritoriais americanas, como o CLOUD Act. O problema é que boa parte dessas infraestruturas continua baseada em processadores da Intel e AMD — e, segundo pesquisadores, esses chips carregam uma camada de controle praticamente invisível aos sistemas operacionais e ferramentas tradicionais de segurança. Dentro dos processadores modernos existem subsistemas chamados Intel Management Engine (ME), atualmente conhecido como CSME, e AMD Platform Security Processor (PSP). Esses componentes funcionam em um nível extremamente privilegiado, conhecido como Ring -3, abaixo do sistema operacional, do hypervisor e até das soluções de monitoramento corporativo. Na prática, operam como pequenos computadores independentes dentro do próprio hardware. Segundo John Goodacre, professor de arquitetura computacional e ex-diretor do programa britânico Digital Security by Design, esses módulos possuem memória própria, relógio interno, pilha de rede independente e capacidade de acessar dispositivos e tráfego de rede sem que o host consiga monitorar ou registrar suas atividades. Como compartilham os mesmos endereços MAC e IP da máquina principal, qualquer comunicação gerada por eles se mistura ao tráfego legítimo do sistema. A discussão ganhou força porque a legislação americana evoluiu nos últimos anos. O RISAA 2024 ampliou a definição de “provedores de serviços de comunicação eletrônica”, permitindo que fabricantes de hardware também possam ser obrigados, por ordens secretas, a cooperar com agências de inteligência dos EUA. Isso significa que empresas como Intel e AMD poderiam ser legalmente compelidas a fornecer acesso ou colaboração técnica envolvendo esses componentes embarcados nos processadores. Os pesquisadores destacam que o risco não é apenas teórico. Em 2017, a Microsoft documentou que o grupo PLATINUM, associado a atividades de espionagem estatal, utilizou o recurso Intel Serial-over-LAN (SOL) como canal oculto de exfiltração de dados. O tráfego passava pelo Management Engine antes mesmo da pilha TCP/IP do sistema operacional entrar em funcionamento, tornando a comunicação invisível para firewalls locais, EDRs e outras soluções de segurança executadas na máquina comprometida. Nesse caso, não houve exploração de vulnerabilidade. Os invasores abusaram de funcionalidades legítimas do Intel AMT (Active Management Technology), utilizando credenciais padrão de fábrica que sequer possuíam senha configurada em determinados dispositivos. O relatório também destaca que o problema se estende para servidores corporativos e ambientes de datacenter. Nos servidores Intel, o mecanismo equivalente recebe o nome de SPS (Server Platform Services) e opera integrado aos controladores BMC (Baseboard Management Controller), responsáveis pela administração remota de servidores. Segundo o pesquisador Aurélien Francillon, da EURECOM, os BMCs representam hoje uma das superfícies de ataque mais críticas em ambientes cloud. Em abril de 2026, pesquisadores demonstraram ainda o ataque Fabricked contra a tecnologia AMD SEV-SNP, mecanismo de computação confidencial da fabricante. O ataque atingiu taxa de sucesso de 100% utilizando apenas exploração via software, reforçando que o PSP da AMD também pode ser comprometido em cenários avançados. Apesar disso, o framework SecNumCloud não possui requisitos específicos para avaliar ou mitigar diretamente ameaças relacionadas ao Intel ME ou AMD PSP. Francillon afirma que o modelo francês foi concebido principalmente como um framework organizacional e operacional, focado em governança, isolamento, monitoramento, controle de acesso e proteção contra leis extraterritoriais — não como um padrão técnico de segurança de firmware ou hardware. Vincent Strubel, diretor da agência francesa ANSSI, reconhece publicamente que nenhuma oferta de nuvem europeia controla completamente toda a cadeia tecnológica utilizada, principalmente no nível de semicondutores. Segundo ele, o SecNumCloud foi criado para fortalecer resiliência jurídica, operacional e proteção contra interferência externa, mas não resolve dependências estruturais ligadas ao hardware americano ou chinês. A discussão divide especialistas. Francillon argumenta que controles operacionais robustos, segmentação de rede, monitoramento rigoroso e isolamento administrativo tornam esses vetores praticamente inviáveis fora de ataques extremamente sofisticados conduzidos por Estados-nação. Já Goodacre afirma que o risco permanece estruturalmente presente, principalmente em cenários de supply chain compromise, adulteração de firmware e espionagem governamental avançada. O relatório cita inclusive dados da Eclypsium mostrando que aproximadamente 72% dos dispositivos corporativos analisados permaneceram vulneráveis ao INTEL-SA-00391 anos após a divulgação pública da falha, enquanto 61% ainda estavam expostos ao INTEL-SA-00295. O grupo de ransomware Conti também teria desenvolvido provas de conceito visando implantes persistentes diretamente no Intel ME. A longo prazo, defensores da soberania digital europeia enxergam arquiteturas abertas como RISC-V como possível alternativa. No entanto, especialistas afirmam que o ecossistema ainda está distante de competir com Intel e AMD em workloads de datacenter de alta performance. O debate agora vai além da nuvem soberana. A principal questão levantada pelos pesquisadores é se existe, de fato, soberania digital possível quando toda a infraestrutura crítica continua dependente de processadores desenvolvidos sob jurisdição estrangeira e equipados com mecanismos de gerenciamento invisíveis ao próprio sistema operacional.