Hackers começaram a explorar ativamente uma vulnerabilidade crítica recentemente corrigida no VMware vCenter, da Broadcom, para comprometer servidores e estabelecer acesso remoto persistente, da empresa alemã de cibersegurança QUIRSO. A falha, identificada como CVE-2026-59310 e classificada com pontuação CVSS 9,8, é uma vulnerabilidade de directory traversal no VMware vCenter Server. Um invasor com acesso de rede ao sistema pode explorá-la para executar código arbitrário. A Broadcom disponibilizou correções para o problema no fim de julho. A atividade maliciosa foi identificada pela QUIRSO durante um trabalho de resposta a incidentes. A análise encontrou uma sequência de ataque com tentativas de manipulação de caminhos compatíveis com a CVE-2026-59310, seguidas pela criação de uma tarefa cron maliciosa para garantir persistência no servidor comprometido. Os invasores utilizaram o reverse_ssh, ferramenta de código aberto capaz de estabelecer conexões SSH reversas com infraestrutura controlada externamente. Dessa forma, o servidor comprometido inicia uma conexão de saída para o atacante, o que pode permitir contornar controles de segurança destinados principalmente a bloquear conexões suspeitas de entrada. Segundo a QUIRSO, os primeiros sistemas comprometidos começaram a se comunicar com domínios controlados pelos atacantes em 3 de agosto, cinco dias depois da divulgação pública da vulnerabilidade pela Broadcom. A investigação identificou até 361 endereços IP únicos associados a vítimas em 47 países. A maior concentração está na Alemanha, Estados Unidos, Turquia, Irã e França. Embora exista a possibilidade de os responsáveis já conhecerem a vulnerabilidade anteriormente, a proximidade entre sua divulgação e o início das invasões sugere, segundo a QUIRSO, que a publicação da falha tenha sido o ponto de partida da campanha. A identidade dos responsáveis ainda não foi determinada. Os pesquisadores, porém, acreditam que a operação possa estar relacionada a um possível grupo de ameaça persistente avançada (APT). Até o momento, não há evidências suficientes para atribuir a campanha a um grupo específico. Appliances da VMware já foram utilizados como alvo em operações anteriores de espionagem. Grupos ligados à China, como o UNC5174, exploraram vulnerabilidades em produtos como VMware Tools e VMware vCenter. Em abril de 2025, a SentinelOne também descreveu o cluster de ameaças PurpleHaze, associado à China, que utilizou o backdoor GoReShell contra uma organização de apoio a um governo do sul da Ásia. O GoReShell incorporava funcionalidades do próprio reverse_ssh para estabelecer conexões SSH reversas com servidores controlados pelos invasores. Apesar desse histórico, a QUIRSO ressalta que a presença da ferramenta, isoladamente, não comprova atividade maliciosa. Quando o reverse_ssh aparece instalado sem autorização, executando em um appliance vCenter vulnerável ou estabelecendo conexões externas inesperadas, porém, a empresa considera o comportamento um indicador de alta prioridade que deve ser investigado. Paralelamente, a Defused Cyber identificou um aumento nas varreduras direcionadas ao VMware vCenter que pode estar relacionado a tentativas de exploração de outra vulnerabilidade crítica, a CVE-2026-59309, também classificada com CVSS 9,8. Os honeypots da empresa registraram aumento de atividades de reconhecimento, incluindo consultas de versão por meio de POST /sdk/ e verificações do fluxo SAML SSO em /websso. A movimentação coincide com a divulgação do boletim VMSA-2026-0006, da Broadcom, relacionado à CVE-2026-59309, uma falha de bypass de autenticação no vmdir. Apesar da proximidade entre as atividades, Denis Szadkowski, COO e cofundador da QUIRSO, afirmou que ainda não existem evidências suficientes para relacionar as varreduras envolvendo a CVE-2026-59309 à mesma campanha ou infraestrutura associada à exploração da CVE-2026-59310. No caso investigado pela QUIRSO, entretanto, as evidências forenses indicam um comprometimento bem-sucedido, e não apenas tentativas de exploração. A análise aponta com maior confiança para a CVE-2026-59310 como o vetor inicial utilizado pelos invasores.

Pesquisadores demonstraram uma técnica que explora o mecanismo Plug and Play (PnP) do Windows para transformar a instalação automática de dispositivos USB em execução de código com privilégios SYSTEM em uma máquina Windows 11 totalmente atualizada. A pesquisa, intitulada "Plug And Pwn: Weaponizing Windows PnP Auto-Install", foi desenvolvida por Alejandro Hernando e Borja Martinez para apresentação na DEF CON 34. Os pesquisadores criaram ferramentas capazes de emular dispositivos USB arbitrários e induzir o Windows a buscar e instalar automaticamente softwares legítimos e assinados de diferentes fabricantes. O ataque explora o funcionamento normal do Plug and Play. Quando um dispositivo é conectado, o Windows recebe seus identificadores de hardware e compatibilidade e utiliza essas informações para localizar um pacote de driver correspondente. Os pesquisadores mostraram que componentes privilegiados instalados nesse processo podem ser combinados com vulnerabilidades em softwares de terceiros para obter privilégios SYSTEM. Na cadeia física demonstrada, os pesquisadores primeiro emulam um dispositivo da Sierra Wireless, fazendo o Windows instalar o SwiService.exe, um serviço executado como SYSTEM que disponibiliza uma funcionalidade SetDNS. Essa capacidade é utilizada para redirecionar consultas DNS. Em seguida, eles emulam um leitor Sony FeliCa. Segundo a pesquisa, o co-instalador associado ao dispositivo obtém arquivos de configuração por HTTP sem criptografia e utiliza os caminhos das URLs para determinar os nomes dos arquivos armazenados localmente. Uma vulnerabilidade de path traversal nesse processo permitiria colocar uma DLL dentro do diretório System32. Ao reconectar o dispositivo Sierra Wireless, a biblioteca inserida é carregada, resultando na execução de código com privilégios SYSTEM. A demonstração foi realizada em um Windows 11 totalmente atualizado. Os pesquisadores não afirmam que a mesma cadeia funcione em todas as versões do Windows, portanto o resultado não deve ser generalizado para sistemas que não foram testados. A pesquisa também apresenta uma variante remota que dispensa o dispositivo USB físico. Nesse cenário, o tráfego USB é sintetizado por meio de uma sessão de Remote Desktop Protocol (RDP), desde que os recursos necessários de redirecionamento Plug and Play ou USB de baixo nível estejam habilitados. O cliente Python desenvolvido pelos pesquisadores falsifica a identidade de um dispositivo USB e apresenta ao Windows um dispositivo Intel RealSense virtual. O sistema então inicia o processo de instalação correspondente ao hardware redirecionado. Segundo os pesquisadores, o software RealSense instalado pode ser explorado por meio de um sequestro da ordem de carregamento da biblioteca CRYPTBASE.dll em um diretório de instalação no qual o usuário pode escrever arquivos. A técnica permite que um usuário autenticado com poucos privilégios alcance execução de código como SYSTEM. Essa variante, porém, depende da configuração do ambiente. A Microsoft informa que o Remote Desktop Services não permite por padrão o redirecionamento de dispositivos Plug and Play compatíveis e de USB via RemoteFX. O encaminhamento USB de baixo nível também depende da habilitação do redirecionamento Plug and Play. No ataque físico existe outra condição necessária: o invasor precisa conseguir apresentar um dispositivo USB emulado à máquina alvo. Administradores que não utilizam o redirecionamento de dispositivos em ambientes RDP podem mantê-lo desabilitado. O Windows também disponibiliza políticas para permitir ou bloquear instalações com base em identificadores de hardware, IDs compatíveis, identificadores de instâncias e classes de dispositivos. Em servidores Remote Desktop, essas restrições também podem afetar dispositivos redirecionados. A pesquisa demonstra como um mecanismo legítimo e privilegiado do Windows pode ser combinado com falhas existentes em pacotes assinados de terceiros para elevar privilégios. Os detalhes específicos envolvendo softwares da Sierra Wireless, Sony e Intel foram apresentados pelos pesquisadores e devem permanecer atribuídos à pesquisa enquanto não houver documentação independente dos respectivos fabricantes confirmando essas condições.

A Mozilla revogou uma chave criptográfica utilizada para assinar downloads do Firefox e Thunderbird no Linux depois que uma cópia não criptografada do material foi adicionada por engano a um repositório privado de código da própria empresa. A chave é usada para verificar a autenticidade dos arquivos distribuídos pela Mozilla. Usuários e distribuições Linux podem validar a assinatura para confirmar que um pacote baixado, como um tarball do Firefox, realmente foi produzido pela organização e não sofreu alterações. Até o momento, não há evidências de que pessoas não autorizadas tenham obtido acesso à chave. Segundo a Mozilla, o repositório era privado e a análise dos registros de auditoria disponíveis não identificou acessos indevidos. As pessoas que podiam visualizar o repositório já possuíam acesso legítimo ao ambiente. Apesar disso, a Mozilla decidiu revogar a chave. A medida também afeta arquivos antigos: depois que o certificado de revogação é importado, downloads anteriores assinados com a chave deixam de passar pela verificação criptográfica. A maioria dos usuários do Firefox e Thunderbird não precisa realizar nenhuma ação. O impacto é maior para quem verifica manualmente assinaturas GPG e para usuários que instalam o Firefox por meio dos pacotes RPM oficiais da Mozilla. Quem realiza a validação manual precisa importar a nova chave e a revogação da anterior. No caso dos pacotes RPM, algumas distribuições conseguem buscar automaticamente a chave atualizada durante o processo de atualização e solicitar a confirmação de sua fingerprint. Em outros ambientes, a atualização pode falhar e exigir a substituição manual da chave. A nova subchave de assinatura foi publicada na segunda-feira e possui a fingerprint 827E 6586 0867 9618 CD34 9F93 678E 455D 7676 7AA3, com validade até 5 de agosto de 2028. A revogação chama atenção pelo motivo registrado no certificado OpenPGP. A análise do documento identificou o código 2, correspondente a "key material has been compromised", acompanhado da observação "We no longer trust this key". O certificado foi gerado em 6 de agosto de 2026, às 11h14 UTC. Essa classificação é relevante porque o OpenPGP diferencia uma chave simplesmente substituída ou retirada de uma chave revogada por comprometimento. No primeiro caso, assinaturas anteriores podem continuar válidas. Uma revogação por comprometimento, entretanto, coloca sob suspeita todas as assinaturas produzidas pela chave. Isso não significa, porém, que a Mozilla tenha confirmado o roubo da chave. A própria empresa afirma não ter encontrado evidências de acesso não autorizado, embora tenha optado por tratá-la como não confiável após sua exposição no repositório privado. A revogação envolve uma subchave vinculada à chave primária 14F26682D0916CDD81E37B6D61B7B526D98F0353, que permanece válida. A subchave revogada, 09BE ED63 F346 2A2D FFAB 3B87 5ECB 6497 C1A2 0256, havia sido anunciada em abril de 2025 e expiraria apenas em março de 2027. A substituição ocorreu cerca de sete meses antes do previsto no ciclo normal de rotação da Mozilla. Uma análise do histórico público encontrou outras cinco subchaves de assinatura desde 2015, todas retiradas por expiração. Esta seria a primeira revogação registrada nessa chave. Usuários de pacotes RPM que enfrentarem falhas poderão precisar remover a chave antiga antes de importar a nova, já que apenas executar rpm --import pode não substituir corretamente a chave existente. O Thunderbird não distribui pacotes RPM oficiais, portanto esse procedimento específico não se aplica ao cliente de e-mail. A Mozilla não informou qual repositório privado continha a chave, por quanto tempo ela permaneceu armazenada dessa forma ou como o problema foi descoberto. A empresa também não detalhou as novas proteções adotadas após o incidente. O repositório APT utilizado por usuários Debian e Ubuntu emprega uma chave diferente, e pacotes .deb não estão entre os formatos apontados como afetados pelo incidente.

Três vulnerabilidades no recurso de anotações do Zoom poderiam permitir que um participante de uma reunião comprometesse o cliente de outro usuário, inclusive em cenários nos quais a vítima apenas estivesse assistindo a um compartilhamento de tela. As falhas estavam relacionadas ao mecanismo que permite desenhar e inserir textos durante o compartilhamento. Segundo pesquisadores da startup israelense de segurança ofensiva A Security, a exploração não exigiria cliques, downloads ou confirmação da vítima, nem apresentaria sinais visíveis na tela. As correções já haviam sido distribuídas pelo Zoom em junho e julho, cerca de dois meses antes da divulgação pública da pesquisa. Até a publicação do estudo, não havia relatos de exploração das vulnerabilidades, e nenhuma delas constava no catálogo Known Exploited Vulnerabilities (KEV) da CISA. As falhas foram identificadas como CVE-2026-53413, uma sobrescrita de buffer com CVSS 8,3; CVE-2026-53414, uma leitura além dos limites do buffer com CVSS 6,5; e CVE-2026-53415, uma vulnerabilidade use-after-free também classificada com CVSS 8,3. As correções abrangem diferentes produtos. No Zoom Workplace, usuários devem utilizar as versões 7.1.5 ou 7.0.6, conforme a respectiva linha de versões. Para o Zoom Workplace VDI Client no Windows, as versões corrigidas são 7.0.11 e 6.6.16. Zoom Rooms e Zoom Meeting SDK receberam correções a partir da versão 7.1.0, enquanto a terceira vulnerabilidade exige a versão 7.1.5. A análise técnica da A Security indica que uma anotação não é transmitida pela rede simplesmente como uma imagem. O cliente do Zoom transforma o desenho em um objeto estruturado, contendo contagens seguidas pelos respectivos dados. No lado receptor, essas contagens são utilizadas para determinar quanto conteúdo deve ser processado. Em um dos casos analisados, dados poderiam preencher um buffer fixo de 128 bytes sem uma verificação adequada de tamanho. Como o campo afetado aparece no final do objeto, uma contagem excessivamente grande poderia ultrapassar os limites do buffer e alcançar o endereço de retorno, criando condições para execução de código. Outro elemento importante estaria na forma como determinadas mensagens são tratadas entre os participantes. Durante o compartilhamento, os clientes mantêm canais de comunicação entre quem apresenta a tela e quem acompanha a transmissão. Segundo os pesquisadores, em determinados caminhos o dispatcher verificava o tipo da mensagem recebida, mas não validava adequadamente a função ocupada pelo remetente na reunião. A análise identificou, por exemplo, os tipos de mensagem 0x10001, utilizado para transmitir um objeto, e 0x10002, empregado como confirmação de recebimento. Ao enviar o primeiro tipo por um caminho no qual deveria trafegar o segundo, seria possível fazer o cliente da vítima reconstruir integralmente um objeto malformado. Há, porém, divergências entre a avaliação da A Security e a classificação oficial do Zoom. A startup atribuiu pontuação 9,0 no CVSS 4.0 às três vulnerabilidades, enquanto os boletins do fornecedor apresentam notas inferiores. Os vetores publicados pelo Zoom também indicam necessidade de interação do usuário, diferentemente da caracterização de ataque zero-click apresentada pelos pesquisadores. A diferença é particularmente relevante na CVE-2026-53414. A A Security afirma ter conseguido recuperar memória heap não inicializada contendo ponteiros de código e vtable do cliente da vítima, informações potencialmente úteis para contornar mecanismos de randomização de endereços. O boletim do Zoom, por outro lado, descreve a possibilidade de negação de serviço e classifica o impacto sobre a confidencialidade como inexistente. Também existem diferenças na atribuição das descobertas. Dois boletins creditam Idan Levcovich, da A Security, enquanto a CVE-2026-53415 é atribuída pelo Zoom à sua própria equipe Offensive Security. A startup inclui as três vulnerabilidades em sua pesquisa, mas reconhece que o Zoom já conhecia a terceira falha e havia implementado uma filtragem no lado do servidor antes de receber o relatório. A A Security também afirma ter desenvolvido um exploit funcional em menos de um dia utilizando menos de 20 prompts em modelos públicos de inteligência artificial. A empresa, entretanto, não informou quais modelos foram utilizados, impedindo a verificação independente dessa alegação. Segundo o relato, a primeira análise automatizada identificou 3.762 funções potencialmente relevantes em 70 bibliotecas, mas não encontrou inicialmente a biblioteca vulnerável, que apareceu apenas na 45ª posição. As falhas foram identificadas posteriormente após os pesquisadores acompanharem o comportamento do cliente durante uma chamada real e analisarem os recursos individualmente.

A Cisco alertou que uma vulnerabilidade de alta severidade nos softwares Secure Firewall Adaptive Security Appliance (ASA) e Secure Firewall Threat Defense (FTD) está sendo explorada ativamente em ataques. Rastreada como CVE-2026-20349, a falha recebeu pontuação 8,6 no CVSS e decorre de verificações insuficientes de erros durante o processamento de requisições HTTP. O problema permite que um invasor remoto e não autenticado provoque uma condição de negação de serviço (DoS). Segundo a Cisco, a exploração ocorre por meio do envio de uma requisição HTTP especialmente manipulada ao serviço Remote Access SSL VPN de um dispositivo vulnerável. Se o ataque for bem-sucedido, o equipamento pode ser forçado a reiniciar, causando indisponibilidade dos serviços protegidos pelo dispositivo. A vulnerabilidade afeta equipamentos que executam versões vulneráveis do Cisco Secure Firewall ASA Software ou Secure FTD Software e possuem determinadas funcionalidades habilitadas. Entre as configurações expostas estão IKEv2 Remote Access VPN com serviços de cliente, SSL VPN e Zero Trust Network Access (ZTNA). No ASA, são afetadas versões das linhas 9.16, 9.18, 9.20, 9.22, 9.23 e 9.24. A Cisco disponibilizou versões corrigidas correspondentes, incluindo 9.16.4.50, 9.18.4.50, 9.20.4.235, 9.22.3.191, 9.23.1.211 e 9.24.1.221. Para o FTD, a vulnerabilidade atinge as versões 7.0, 7.2, 7.4, 7.6, 7.7 e 10.0. A fabricante disponibilizou hotfixes específicos para as diferentes versões e plataformas de hardware afetadas. Não existem soluções alternativas que eliminem a vulnerabilidade. Por isso, administradores de ambientes expostos precisam aplicar as atualizações ou hotfixes disponibilizados pela Cisco para corrigir o problema. A empresa informou que tomou conhecimento da exploração ativa no início de agosto. A vulnerabilidade foi identificada durante testes internos de segurança, e a Cisco também creditou o pesquisador Valerio Brussani pela descoberta e comunicação independente do problema. Até o momento, não foram divulgados detalhes sobre os ataques observados, incluindo a identidade ou origem dos hackers, organizações afetadas ou eventual sucesso das tentativas de exploração. A exploração ativa levou a Cybersecurity and Infrastructure Security Agency (CISA) dos Estados Unidos a adicionar a CVE-2026-20349 ao catálogo Known Exploited Vulnerabilities (KEV). Órgãos civis do Poder Executivo Federal norte-americano devem aplicar as correções até 14 de agosto de 2026.

A SAP lançou uma atualização de segurança para corrigir uma vulnerabilidade de severidade máxima no SAP Commerce Cloud (Data Hub Adapter) que pode permitir a execução arbitrária de código por invasores não autenticados. Identificada como CVE-2026-58231, a falha recebeu pontuação 10,0 no CVSS e está relacionada a verificações insuficientes de autorização e validação inadequada de entradas. Segundo a descrição publicada no CVE.org, um invasor sem autenticação pode abusar de um cliente de autenticação padrão do SAP Commerce Cloud e enviar entradas especialmente manipuladas para determinadas funções que não realizam validações adequadas. A exploração bem-sucedida pode resultar na execução arbitrária de código e no comprometimento de componentes internos da plataforma, com alto impacto sobre a confidencialidade, integridade e disponibilidade da aplicação. A empresa de segurança SAP Onapsis recomendou que os clientes atualizem o Commerce Cloud para uma versão corrigida e, em seguida, realizem novamente a implantação do ambiente atualizado. Como mitigação temporária, organizações que ainda não puderem aplicar a correção podem configurar um IP Filter Set para restringir o acesso ao endpoint vulnerável. Além da CVE-2026-58231, a SAP corrigiu outras três vulnerabilidades críticas em sua atualização de segurança de agosto de 2026. A CVE-2026-44772, com CVSS 9,9, afeta o SAP Manufacturing Integration and Intelligence e permite que um invasor com poucos privilégios envie uma entrada manipulada para um servlet vulnerável. A aplicação pode então buscar e processar conteúdo controlado pelo atacante a partir de uma fonte externa, levando à execução arbitrária de comandos no sistema operacional subjacente. Após a instalação da correção, os clientes precisam manter a nova propriedade de sistema "Secure Transformer" configurada com uma lista de hosts autorizados a hospedar arquivos XSL. Dessa forma, apenas arquivos provenientes desses servidores poderão ser processados pelo servlet. Outra vulnerabilidade, a CVE-2026-34265, recebeu pontuação CVSS 9,8 e afeta o Application Server ABAP para SAP NetWeaver e ABAP Platform. A falha de escrita fora dos limites da memória pode ser explorada sem autenticação por meio de erros no processamento do protocolo DIAG, provocando corrupção de memória. O problema pode resultar na exposição de informações sensíveis do sistema ou causar sua interrupção. Já a CVE-2026-44758, com CVSS 9,1, também afeta o Manufacturing Integration and Intelligence. Segundo a Onapsis, o problema envolve um componente servlet suscetível a Server-Side Template Injection (SSTI) e Server-Side Request Forgery (SSRF), condições que podem abrir caminho para execução de comandos. Nesse caso, o ataque exige privilégios elevados. A correção disponibilizada pela SAP remove o componente servlet vulnerável. Com quatro falhas críticas tratadas na atualização de agosto, a recomendação é que administradores avaliem rapidamente os sistemas afetados e priorizem a implantação das versões corrigidas, especialmente no caso da CVE-2026-58231, que pode ser explorada sem autenticação.

Pesquisadores identificaram um comprometimento da cadeia de suprimentos da BdThemes que afetou diversos plugins para WordPress. O incidente levou a equipe responsável pelo diretório de plugins da plataforma a suspender temporariamente os downloads dos produtos envolvidos enquanto realiza uma análise completa. Diferentemente de ataques tradicionais à cadeia de suprimentos, nenhum arquivo de código-fonte foi alterado no repositório oficial WordPress.org. Segundo a Wordfence, os invasores comprometeram um fluxo remoto de dados JSON utilizado pelos plugins para exibir banners promocionais no painel administrativo. Entre os plugins afetados estão Element Pack Addons for Elementor, com mais de 100 mil instalações ativas; Live Copy Paste for Elementor, com mais de 6 mil; Ultimate Store Kit, também com mais de 6 mil; além de Pixel Gallery Addons for Elementor, Prime Slider Addons for Elementor, Smart Admin Assistant e Ultimate Post Kit Addons for Elementor. As páginas desses plugins no diretório do WordPress informam que eles foram fechados em 7 ou 8 de agosto de 2026 e permanecem indisponíveis para download enquanto passam por revisão. O problema está relacionado a um componente interno chamado Biggopti, distribuído junto aos plugins. A biblioteca busca banners promocionais em um servidor de API e utiliza arquivos JSON armazenados em um bucket do DigitalOcean Spaces para apresentar o conteúdo dentro do painel administrativo do WordPress. A Wordfence identificou uma vulnerabilidade de cross-site scripting (XSS) no processamento das respostas JSON, relacionada ao parâmetro “display_id” da API Sigmative e à ausência de tratamento adequado do conteúdo no lado do cliente. Dessa forma, um invasor com capacidade de modificar as respostas da API pode inserir scripts que são executados no navegador. Como o código é carregado nas páginas do “wp-admin”, o JavaScript malicioso pode ser executado silenciosamente quando um administrador autenticado acessa o painel. A vulnerabilidade recebeu pontuação CVSS 5.4, classificada como de severidade média. A alteração vulnerável teria sido introduzida inicialmente em 1º de março de 2026 no plugin “bdthemes-prime-slider-lite” e posteriormente incorporada aos demais. O diferencial do ataque é que toda a cadeia funciona por meio da infraestrutura de API, sem necessidade de publicar atualizações maliciosas dos plugins ou modificar seus arquivos armazenados no servidor WordPress. Segundo a Wordfence, os responsáveis pelo ataque obtiveram acesso de escrita ao bucket utilizado pela BdThemes e substituíram respostas JSON legítimas por conteúdo preparado para explorar a vulnerabilidade XSS. A partir daí, o código executado no navegador de administradores cria contas privilegiadas não autorizadas, instala um plugin contendo um web shell e estabelece comunicação com uma infraestrutura de comando e controle (C2). O principal payload é distribuído aos plugins pelo endpoint “api-data-all-records”. Um arquivo JavaScript chamado “w2.js” entra em contato com o servidor C2 em “ia-cdn[.]com” e envia a origem do site comprometido para receber instruções sobre o alvo. Quando autorizado pelo servidor, o script cria uma nova conta administrativa utilizando a API REST do WordPress. Em seguida, baixa um arquivo ZIP apresentado como plugin e utiliza o mecanismo padrão de instalação da plataforma para implantar um web shell PHP chamado “emer-run.php”. O web shell instala posteriormente dois mecanismos de persistência no diretório de plugins obrigatórios, conhecido como “mu-plugins”. Um deles cria uma porta dos fundos para acesso administrativo não autenticado mediante um parâmetro específico na URL. O outro atua como mecanismo de ocultação, interferindo em consultas ao banco de dados do WordPress para esconder contas maliciosas da lista de usuários e alterar a contagem apresentada aos administradores. Os pesquisadores também localizaram um payload alternativo, chamado “x.js”, hospedado na própria infraestrutura do desenvolvedor e entregue por outro endpoint da API. Esse código gera credenciais administrativas determinísticas a partir do hostname do site comprometido. O algoritmo produz nomes de usuário e senhas previsíveis matematicamente a partir do domínio. Segundo a Wordfence, isso permite que os responsáveis pela campanha recriem posteriormente as credenciais de um site sem precisar manter uma lista centralizada de todas as instalações comprometidas. Para equipes de resposta a incidentes, a mesma característica pode ajudar na identificação das contas criadas pelo ataque. As credenciais geradas são utilizadas para criar um novo administrador malicioso, e informações sobre o comprometimento são posteriormente enviadas ao servidor C2. A infraestrutura de comando e controle utilizada na campanha também foi relacionada pelos pesquisadores a outros dois ataques recentes à cadeia de suprimentos envolvendo plugins WordPress: Advanced Responsive Video Embedder, associado à CVE-2026-18072, e OptinMonster. Nos incidentes anteriores, plugins foram modificados para fornecer acesso administrativo a invasores não autenticados, utilizando mecanismos como tokens incorporados ao código ou contas administrativas ocultas criadas quando um administrador legítimo acessava o site. A relação entre as campanhas indica, segundo a análise, que o objetivo é estabelecer persistência administrativa discreta e capacidade de execução remota de código em ambientes WordPress. Para a Wordfence, a presença tanto dos registros JSON maliciosos quanto do payload secundário “x.js” diretamente na infraestrutura do fornecedor indica um comprometimento significativo das credenciais de armazenamento em nuvem ou da infraestrutura interna da BdThemes. A descoberta ocorre poucos dias depois de o WordPress corrigir outra vulnerabilidade XSS, identificada como CVE-2026-64638 e apelidada de XSS2Shell. Com pontuação CVSS 8.9, a falha pode levar à execução de código PHP no servidor quando um administrador autenticado interage com uma página controlada por um invasor.

Hackers comprometeram os controles industriais de uma usina de cogeração na Polônia e desligaram uma turbina a vapor e o sistema de tratamento de água de processo após acessar o ambiente por uma rede celular privada usada para comunicação com equipamentos remotos. A instalação fornece aquecimento para aproximadamente 50 mil moradores. A recuperação começou por volta das 7h30, enquanto os invasores ainda estavam ativos na rede, mas o incidente não provocou interrupção no fornecimento de eletricidade ou aquecimento aos consumidores. O CERT Polska divulgou em 8 de agosto os detalhes do ataque, ocorrido em dezembro de 2025, após mais de três meses de investigação. Em janeiro, o primeiro-ministro da Polônia havia informado que duas usinas de cogeração haviam sido atingidas. Este é o segundo incidente detalhado. O acesso ocorreu por meio de um APN privado (Access Point Name), uma rede de dados celular dedicada administrada pelo operador do sistema de distribuição. Uma configuração que permitia comunicação direta entre diferentes dispositivos conectados ao APN possibilitou que os hackers avançassem de uma rede comprometida de um parque eólico até um controlador localizado na usina. Segundo o CERT Polska, esta é, até onde a organização tem conhecimento, a primeira vez que o acesso a uma rede de controle industrial por meio de um APN privado é observado em um ataque cibernético real. O parque eólico e a usina são instalações independentes e nenhuma das duas administra a infraestrutura celular que possibilitou a conexão entre elas. A investigação não identificou uma vulnerabilidade específica como causa do comprometimento. Também não foi possível determinar se alguma falha no roteador Teltonika foi explorada, o que significa que não existe uma única correção de software capaz de eliminar o vetor utilizado. Entre os problemas encontrados estavam um controlador WAGO acessível pelo APN ainda utilizando credenciais administrativas padrão e a ausência de isolamento entre clientes da rede celular privada. Por isso, a principal recomendação do CERT é revisar a configuração dos APNs e habilitar o isolamento entre dispositivos. A entidade também recomenda tratar o APN como uma rede não confiável do ponto de vista da tecnologia operacional (OT), segmentar e restringir o tráfego, remover serviços administrativos desnecessários das interfaces acessíveis pela rede celular e substituir credenciais padrão. Levantamentos do CERT indicam que organizações polonesas que utilizam APNs privados frequentemente permitem que qualquer dispositivo da rede se comunique com os demais. A entidade acredita que configurações semelhantes também sejam utilizadas em outros países. No incidente investigado, o serviço SSH do roteador, a interface web do controlador e a comunicação entre dispositivos do APN funcionavam conforme suas configurações. A cadeia de ataque começou em um parque eólico, onde um equipamento FortiGate atuava simultaneamente como firewall e concentrador VPN. A VPN estava exposta à internet e permitia contas sem autenticação multifator. O invasor obteve privilégios administrativos no equipamento e provavelmente utilizou esse acesso para conseguir credenciais VPN capazes de alcançar todos os segmentos da rede. O operador de distribuição exigia que a comunicação com a unidade terminal remota da subestação utilizasse o protocolo serial DNP3.0, requisito que havia sido atendido. Entretanto, não existiam exigências equivalentes para a interface administrativa do roteador celular, conectada por uma segunda interface Ethernet a uma VLAN localizada atrás do firewall comprometido. O roteador era um Teltonika RUTX50 cuja senha padrão havia sido alterada durante a implantação. Os investigadores encontraram registros de diversos logins SSH bem-sucedidos, mas não conseguiram determinar como a senha foi obtida. A análise das vulnerabilidades publicadas para o equipamento também não identificou uma falha conhecida capaz de entregar a senha a um invasor sem autenticação. As vulnerabilidades CVE-2023-32349 e CVE-2023-32350, citadas em um alerta da CISA de 2023 para equipamentos da linha RUT, exigem privilégios prévios. A investigação, porém, não descarta a possibilidade de uma vulnerabilidade ainda desconhecida ou não divulgada. Registros da operadora móvel levaram o CERT a avaliar que o atacante provavelmente utilizou tunelamento SSH através do roteador para alcançar o APN privado. A partir de 18 de dezembro, o invasor realizou varreduras na rede e encontrou um controlador WAGO PFC200 com sua interface web administrativa exposta e credenciais padrão. Atividades SSH posteriores indicam que o serviço provavelmente foi habilitado pela própria interface. Pela correlação dos registros, os investigadores avaliam que o atacante utilizou o WAGO como ponto intermediário para alcançar a rede OT da usina. Em 25 de dezembro, foram registradas conexões bem-sucedidas com três PLCs Siemens pelo protocolo S7. O CERT considera essa atividade provavelmente relacionada ao reconhecimento realizado antes das ações destrutivas. Em 29 de dezembro, a atividade maliciosa dentro da rede da usina ocorreu aproximadamente entre 5h30 e 10h10. Segundo funcionários da instalação, controladores Siemens S7-300, S7-1200 e S7-1500 foram colocados em modo STOP e protegidos com senha, provocando o desligamento da turbina e do sistema de tratamento de água e interrompendo temporariamente a cogeração. Sete servidores seriais Moxa e três switches também foram restaurados para as configurações de fábrica, tiveram suas senhas alteradas e receberam endereços IP inacessíveis, incluindo 127.0.0.1. O CERT avalia, com alto grau de confiança, que essas ações foram automatizadas. Nenhuma dessas operações exigiu malware. Todas as etapas destrutivas utilizaram funções legítimas dos próprios equipamentos, acionadas pelos protocolos empregados normalmente pela infraestrutura industrial. Depois das ações contra a usina, o invasor também comprometeu os próprios caminhos utilizados para o ataque. A tabela de partições do controlador WAGO foi corrompida, impedindo sua inicialização e eliminando registros úteis para a investigação. Cerca de 30 minutos após a última atividade observada na usina, o roteador Teltonika foi restaurado para as configurações de fábrica, recebeu uma nova senha administrativa e o endereço 127.0.0.1. Em seguida, o FortiGate também foi resetado, causando a perda de seus logs. Registros de login SSH do Teltonika sobreviveram porque versões do RutOS anteriores à 7.07 mantinham o banco de eventos após um reset de fábrica. Inicialmente, a usina não interpretou a interrupção como um ataque cibernético. Como trabalhos de manutenção estavam em andamento, o problema foi registrado como possível erro de um prestador de serviço. O CERT decidiu abrir um incidente porque já tinha conhecimento de ocorrências semelhantes. A investigação identificou atividades de reconhecimento entre 18 e 25 de dezembro, incluindo uma varredura de portas iniciada a partir do endereço do sistema SCADA. Nenhum grupo foi atribuído especificamente a este ataque. A campanha mais ampla observada na Polônia em dezembro recebeu análises separadas do governo polonês, CERT Polska, ESET e Dragos, mas essas avaliações abordaram outros aspectos da campanha e não estabelecem autoria para esta intrusão. O caso também evidencia uma limitação importante do uso de APNs privados como mecanismo de isolamento. Essas redes continuam aparecendo em orientações de segurança para conectar equipamentos OT por redes celulares, mas o incidente demonstra que sua proteção depende de controles adicionais, especialmente isolamento entre clientes, segmentação, autenticação adequada e restrição das interfaces administrativas.

Servidores maliciosos conectados a assistentes de programação por inteligência artificial podem induzir agentes a exfiltrar chaves SSH, segredos de ambiente, código-fonte e dados de clientes sem apresentar uma única instrução claramente maliciosa. A técnica, chamada GhostSplice, explora a capacidade dos agentes de combinar comandos aparentemente inofensivos distribuídos em diferentes interações. O ataque tem como alvo ferramentas de programação que utilizam o Model Context Protocol (MCP), padrão aberto que permite a assistentes de IA acessar ferramentas e serviços externos. Em vez de solicitar diretamente o acesso e envio de arquivos confidenciais — comportamento que pode ser bloqueado pelos mecanismos de segurança —, um servidor MCP malicioso divide a solicitação em fragmentos. Segundo o ASSET Research Group, um fragmento pode ser colocado na descrição de uma ferramenta e outro aparecer posteriormente no resultado de uma operação. Algumas implementações também permitem mecanismos adicionais iniciados pelo servidor. Embora o MCP mantenha separadas estruturalmente as chamadas e respostas das ferramentas, os testes indicam que agentes podem reunir instruções provenientes desses diferentes canais dentro do mesmo contexto de trabalho. Os pesquisadores demonstraram a técnica em ambientes isolados, utilizando projetos preparados com credenciais falsas. Não há indicação de exploração do GhostSplice em ataques reais. A divulgação também informa que eventuais identificadores CVE serão publicados após o processo de divulgação coordenada. Um dos principais resultados da pesquisa é que o comportamento não depende apenas do modelo de IA utilizado. O mesmo modelo pode recusar uma tentativa de exfiltração em um cliente de programação e aceitar a operação em outro, dependendo das proteções implementadas ao redor do modelo. A técnica também possui uma limitação importante: ela não permite comprometer arbitrariamente um agente de IA pela internet. O ataque pressupõe que o desenvolvedor já tenha conectado o servidor MCP controlado pelo invasor e que o agente possua permissão para acessar os arquivos que serão coletados. Na implementação de referência, o servidor apresenta uma ferramenta aparentemente legítima chamada “integrity_checker”, contendo quatro campos genéricos identificados como alpha, beta, gamma e delta, sem mencionar arquivos confidenciais. Posteriormente, o resultado de uma varredura do projeto fornece o mapeamento que associa esses campos ao conteúdo de arquivos como “.ssh/id_rsa”, código proprietário, “customers.csv” e “.env”, sob o pretexto de realizar uma “verificação de hash no servidor”. Separadamente, nenhuma das instruções contém todo o comando necessário para a exfiltração. Quando combinadas pelo agente, porém, elas orientam a coleta dos arquivos locais e o envio de seu conteúdo para a ferramenta controlada pelo atacante. O repositório público da pesquisa também apresenta uma variante com três canais, separando inventário do projeto, mapeamento dos arquivos e ferramenta de coleta em três interações. Nos testes com 11 modelos acessados por API, a taxa média de execução das solicitações subiu de 42% para 82% quando as instruções foram divididas em duas partes. GPT-4o, Gemini 2.0 Flash e Llama 3.3 70B passaram de 0% no teste com uma única instrução para 100% no cenário fragmentado. Os resultados também variaram conforme o ambiente. Claude Haiku 4.5 permaneceu em 0% nos testes via API, mas chegou a 100% em um teste com três fragmentos no Cursor. O GPT-5.4 registrou 90% no Cursor e 100% pelo Codex CLI, enquanto o repositório da pesquisa relata queda para 0% quando utilizado por meio do Claude Code. Os números, entretanto, representam exclusivamente os cenários testados pelos pesquisadores e não devem ser interpretados como taxas gerais de vulnerabilidade dos modelos. Claude Sonnet 4.6 e Opus 4.6, por exemplo, aparecem com 0% na tabela publicada, mas o ASSET afirma que, em um dos testes, o Sonnet enviou código proprietário contendo uma chave inserida diretamente no código enquanto ocultava outros segredos mais evidentes. A pesquisa também identificou que justificativas elaboradas envolvendo conformidade ou governança podiam despertar mais resistência do modelo. Uma abordagem simples, semelhante ao preenchimento de campos solicitados por uma ferramenta, mostrou-se mais difícil de distinguir de uma operação legítima. As medidas de proteção dependem principalmente dos clientes e das integrações MCP. A especificação recomenda manter o usuário no controle das chamadas de ferramentas e tratar informações provenientes de servidores não confiáveis como dados não confiáveis. O ASSET também recomenda impedir que resultados produzidos por uma ferramenta sejam utilizados automaticamente como argumentos de outra sem validação. O GhostSplice sucede o Ghostcommit, técnica divulgada pelo mesmo laboratório em junho. Nesse caso, uma instrução era escondida em uma imagem PNG referenciada por um arquivo de convenções do projeto, levando um agente de programação a codificar segredos de arquivos “.env” dentro do código-fonte. Apesar dos mecanismos diferentes, as pesquisas indicam que as proteções implementadas ao redor dos modelos são determinantes para limitar ataques contra agentes de IA.

O clube francês de rúgbi Stade Français Paris confirmou que sofreu um ataque cibernético que interrompeu parte de seus sistemas de informação. O ambiente de TI já foi restaurado a partir de backups considerados íntegros, permitindo que as operações voltassem a funcionar normalmente. Segundo o clube, a plataforma de venda de ingressos e a loja online não foram afetadas e permanecem totalmente operacionais. A organização, no entanto, reconheceu que uma amostra de dados supostamente roubados durante o ataque foi publicada na internet. O Stade Français informou que está investigando a extensão do possível vazamento e trabalhando para identificar pessoas cujas informações possam ter sido comprometidas. O clube também notificou as autoridades responsáveis e apresentou uma queixa criminal após descobrir o incidente. Em comunicado, a organização afirmou que não comentará mensagens dos invasores nem informações divulgadas por terceiros enquanto a investigação e as medidas de resposta estiverem em andamento. Até o momento, o Stade Français não atribuiu oficialmente o ataque a nenhum grupo, nem informou se recebeu pedido de resgate ou se mantém negociações com os responsáveis. No início desta semana, o grupo de ransomware Qilin reivindicou a autoria do ataque em seu site de vazamentos na dark web. Segundo a imprensa francesa, os hackers publicaram documentos pertencentes a 18 jogadores como suposta prova da invasão e ameaçaram divulgar arquivos adicionais caso um resgate não seja pago até o final da próxima semana. A autenticidade desses documentos não foi verificada de forma independente. O Qilin é uma das operações de ransomware-as-a-service (RaaS) mais ativas atualmente. Nesse modelo, os operadores disponibilizam o ransomware para afiliados que executam os ataques e, em troca, recebem uma parcela dos pagamentos obtidos. O grupo costuma empregar a estratégia de dupla extorsão, na qual dados são roubados antes da criptografia dos sistemas e posteriormente utilizados como instrumento de pressão, com ameaças de publicação caso a vítima não pague. Pesquisadores de segurança já associaram a operação a cibercriminosos de língua russa. Organizações esportivas têm sido alvo recorrente de ataques motivados financeiramente. No início deste ano, o clube holandês Ajax informou que hackers exploraram uma vulnerabilidade não corrigida para acessar sistemas internos, expondo endereços de e-mail de centenas de pessoas e dados pessoais limitados relacionados a indivíduos proibidos de entrar no estádio. O Bologna FC, da Itália, também sofreu um ataque de ransomware em 2024 que expôs documentos financeiros, registros médicos de jogadores e informações confidenciais de funcionários. Outras organizações esportivas atingidas nos últimos anos incluem o Paris Saint-Germain, que relatou em 2024 um ataque contra seu serviço de venda de ingressos online; o Manchester United, vítima de um incidente de ransomware em 2020; a Real Associação Holandesa de Futebol, em 2023; e a Federação Francesa de Futebol, em 2025.

Um juiz do Novo México determinou que a Meta pague US$ 567 milhões e faça mudanças na forma como crianças e adolescentes utilizam suas plataformas. A decisão é o mais recente desdobramento de um processo que discute os impactos negativos das redes sociais sobre menores. O dinheiro será destinado à criação de um fundo para reduzir danos associados às redes sociais. Desse total, US$ 420 milhões deverão financiar tratamentos para jovens do Novo México que tenham sido prejudicados nas plataformas. O restante será aplicado em campanhas de conscientização pública e iniciativas de prevenção. O processo é considerado um caso de referência por ser o primeiro entre dezenas de ações movidas por procuradores-gerais estaduais contra a Meta a chegar a esse estágio. Em março, um júri que analisou o mesmo caso aplicou separadamente uma penalidade de US$ 375 milhões, concluindo que a Meta enganou usuários sobre a segurança do Instagram e do Facebook e facilitou a exploração sexual de menores. Na nova decisão, o juiz Bryan Biedscheid, de Santa Fé, classificou a Meta como um “incômodo público” e afirmou que as evidências apresentadas no processo demonstraram que suas plataformas são um fator significativo para a atual crise de saúde mental entre jovens do Novo México, embora a empresa não seja a única responsável pelo problema. Além da indenização, a decisão estabelece restrições específicas para usuários jovens no estado. A Meta não poderá enviar notificações push entre 22h e 7h e deverá impedir que esses usuários permaneçam em suas plataformas por mais de 90 horas por mês. Facebook e Instagram também terão que apresentar telas de conscientização pública explicando seus recursos de proteção infantil e outras informações relevantes sobre segurança. A Meta afirmou discordar da decisão e informou que pretende recorrer. A empresa declarou que trabalha para manter os usuários seguros, que tem sido transparente sobre os desafios para identificar e remover agentes mal-intencionados e conteúdos prejudiciais e que continuará se defendendo de alegações que, segundo ela, distorcem os fatos. A decisão ocorre em meio a outros processos envolvendo os efeitos das redes sociais sobre jovens. Em março, um júri da Califórnia considerou Meta e YouTube responsáveis pelo vício de uma jovem em redes sociais, que teria afetado sua saúde mental. Na ocasião, a Meta foi condenada a pagar US$ 6 milhões. A companhia também enfrenta pelo menos 1.200 processos movidos por distritos escolares. Em maio, chegou a um acordo com um distrito do Kentucky que defendia que a empresa deveria contribuir financeiramente para intervenções de saúde mental e apoio acadêmico destinadas a crianças supostamente prejudicadas por suas plataformas.

A IEH Corporation, fabricante norte-americana de componentes especializados utilizados em sistemas militares, informou à Securities and Exchange Commission (SEC) dos Estados Unidos que sofreu um incidente cibernético após um funcionário ser vítima de phishing. A empresa identificou o ataque na terça-feira e iniciou imediatamente medidas para conter o comprometimento. Segundo um formulário 8-K apresentado à SEC, os invasores conseguiram acesso à caixa de e-mail do funcionário afetado. A conta continha mensagens, anexos, comunicações com clientes, pedidos de compra, documentação relacionada a projetos de engenharia e, potencialmente, informações técnicas sujeitas a controles de exportação. Até o momento, a IEH afirmou não ter evidências de que e-mails ou outros dados tenham sido efetivamente extraídos da conta comprometida. A companhia reconheceu, porém, que informações sensíveis ficaram acessíveis ao invasor durante o período em que a caixa de entrada esteve comprometida. A empresa está adotando medidas para proteger a conta afetada e preservar evidências que possam auxiliar na investigação. A apuração continua em andamento e, até sexta-feira, não havia indícios de impacto do incidente sobre as operações da companhia. A IEH Corporation fabrica conectores especializados utilizados em equipamentos de alta criticidade, incluindo satélites militares, caças, radares aerotransportados e terrestres, helicópteros, sistemas de rádio e torpedos. Alguns desses componentes também são empregados em programas de mísseis guiados de precisão, incluindo os sistemas THAAD e Patriot. Produtos da fabricante são ainda utilizados em caças operados por países europeus e pelo governo da Índia. Apesar da natureza sensível dos sistemas atendidos pela companhia, o documento apresentado à SEC não confirma que informações relacionadas especificamente a esses programas tenham sido acessadas ou comprometidas. A IEH Corporation registrou receita de quase US$ 30 milhões no ano fiscal de 2026. A empresa não respondeu aos pedidos de comentários adicionais sobre o incidente.