Pesquisadores identificaram 737 extensões gratuitas de VPN e proxy para Google Chrome envolvidas em uma operação que direcionava o tráfego de navegação dos usuários por uma infraestrutura de proxies. A campanha atingia principalmente usuários de língua russa interessados em acessar serviços bloqueados. As extensões foram distribuídas por pelo menos 40 contas de desenvolvedores na Chrome Web Store e acumularam 75.486 instalações, segundo uma investigação da Socket. Entre os complementos identificados, 274 imitavam 66 marcas conhecidas de VPN e privacidade, incluindo Proton VPN, NordVPN, Surfshark, AdGuard VPN, Browsec, ExpressVPN, CyberGhost, Windscribe, TunnelBear, Cloudflare 1.1.1.1 e Google Outline. A análise mostrou que grande parte das extensões direcionava toda a sessão do navegador por proxies SOCKS5 operados por um único provedor. Em um conjunto de 522 extensões analisadas em massa, 520 utilizavam a mesma infraestrutura SOCKS5. Para realizar o redirecionamento, os complementos modificavam a configuração chrome.proxy.settings, apontando o navegador para um servidor SOCKS5 fixo na porta 1082. Com isso, a infraestrutura responsável pelo proxy ficava em uma posição de adversary-in-the-middle (AitM), ou adversário no meio da comunicação. Essa posição possibilita observar informações como os destinos acessados pelo navegador, endereços IP de origem, valores TLS SNI e o conteúdo de requisições transmitidas por HTTP sem criptografia. As extensões que configuravam o proxy também possuíam uma lista de exceções limitada aos endereços de loopback, como localhost e 127.0.0.1. Na prática, quando o usuário ativava o suposto serviço de VPN, praticamente todas as demais solicitações do navegador eram encaminhadas pelo relay SOCKS5 na porta 1082. Até a análise, 221 extensões haviam sido removidas da Chrome Web Store, enquanto outras 516 ainda apareciam como ativas. Segundo os pesquisadores, o responsável pela infraestrutura aparentemente opera um serviço comercial de VPN por assinatura na Rússia. Entre os indícios estão um número de identificação fiscal de 12 dígitos e caminhos de compilação do Windows encontrados em alguns pacotes contendo diretórios escritos em russo. O funcionamento de encaminhar tráfego por proxies, isoladamente, não diferencia esses complementos de serviços legítimos de VPN. O principal problema identificado é a tentativa de se passar por marcas estabelecidas, em vez de oferecer o serviço sob uma identidade própria, além da falta de transparência sobre a infraestrutura utilizada. A investigação encontrou outros sinais suspeitos, incluindo ofertas de planos pagos ou localidades premium inexistentes, mecanismos para contornar listas de bloqueio via DNS-over-HTTPS e extensões que falhavam em todas as tentativas de conexão enquanto exibiam uma interface falsa completa, com animações e indicadores de status aparentemente funcionais. Também foi localizado um manual interno chamado “Prompt para funcionários”, que orientava desenvolvedores a não inserir diretamente domínios em chrome.proxy.settings, utilizando apenas o endereço IP resolvido. O documento ainda recomendava não reutilizar domínios empregados por outras extensões sem instruções específicas. Comentários presentes no código indicavam tentativas deliberadas de evitar políticas da Chrome Web Store. Os pesquisadores também identificaram a inclusão de uma camada de configuração remota após a aprovação das extensões e justificativas repetidas enviadas durante o processo de revisão, alegando que nenhum dado era transmitido a servidores externos e que não havia rastreamento ou registro de usuários. Segundo a Socket, enquanto uma extensão afetada permanece conectada, todas as requisições passam por um servidor controlado pela infraestrutura responsável pela operação. O código, entretanto, não permite determinar se os operadores possuem diretamente esses proxies ou revendem capacidade de outro provedor. A investigação estabelece evidências de falsificação de marcas, configuração não informada de proxies, servidores premium inexistentes, declarações falsas durante o processo de revisão da loja e alterações de código realizadas após a aprovação. Em um caso separado, a Netskope Threat Labs também identificou o retorno da extensão “AI Sidebar with Deepseek, ChatGPT, Claude, and more.”, removida anteriormente após ser associada a técnicas de Prompt Poaching. Depois de uma atualização considerada legítima que retirou o código responsável pelo roubo de dados, uma nova versão foi distribuída cerca de duas semanas depois. As versões 1.7.2.0 e 1.7.3.0 foram entregues pela infraestrutura CRX do Google em 31 de julho de 2026. O novo código não continha mais o mecanismo de exfiltração de conversas, mas adicionava uma função de monetização que abria um link de afiliado em uma nova aba sempre que a extensão era atualizada ou desinstalada. O código também impedia o redirecionamento de usuários do DeepSeek para o ChatGPT.

Pesquisadores descobriram uma vulnerabilidade na forma como APIs de inteligência artificial da OpenAI, Anthropic e Google transportavam blocos de raciocínio oculto entre chamadas. A técnica permitiu reconstruir conteúdo interno dos modelos e recuperar informações sensíveis presentes em logs públicos, incluindo chaves de API, senhas, tokens de acesso e chaves privadas. O problema afetava objetos de raciocínio criptografados utilizados pelas APIs para preservar o estado de processamento entre diferentes chamadas. Durante os testes, os pesquisadores descobriram que um bloco produzido em uma sessão poderia ser reutilizado em outra e, em determinadas condições, entregue até mesmo a um modelo mais fraco da mesma família para tentar revelar seu conteúdo. O estudo, intitulado “Stealing Reasoning Traces from Proprietary LLM APIs”, descreve quatro possíveis formas de abuso: obtenção de raciocínio proprietário para destilação de modelos, extração de dados privados presentes em traces publicados por outros usuários, recuperação de conteúdo nocivo oculto por trás de uma resposta visível considerada segura e armazenamento de prompt injections dentro dos próprios blocos opacos. Ao analisar 6.708 trajetórias públicas de agentes de IA, a equipe decodificou 315.320 blocos de raciocínio. Depois de remover dados relacionados a benchmarks, foram identificados 704 artefatos de privacidade distintos provenientes de sessões reais, incluindo 62 chaves de API, 33 senhas, 24 tokens de acesso e sete chaves privadas. O ataque entre usuários, entretanto, não fornecia acesso indiscriminado a conversas privadas. Para executá-lo, era necessário primeiro obter um bloco de raciocínio criptografado — por exemplo, publicado em um log de agente — e possuir acesso via API a um modelo compatível do mesmo provedor. A vulnerabilidade não envolvia quebra da criptografia nem obtenção das chaves utilizadas para proteger esses objetos. O ataque explorava o fato de que blocos opacos intactos continuavam sendo aceitos e processados pela infraestrutura do próprio provedor. Esses mecanismos existem para permitir que aplicações preservem o raciocínio entre chamadas quando o histórico da conversa é administrado manualmente ou de forma stateless. A OpenAI utiliza itens de raciocínio criptografados, a Anthropic transporta o raciocínio completo acompanhado de uma assinatura criptografada e o Google utiliza thought signatures criptografadas. Durante os experimentos, os pesquisadores descobriram que esses objetos podiam ser transportados entre sessões, usuários e modelos. Isso possibilitou utilizar modelos compatíveis menos avançados como uma espécie de decodificador aproximado — chamado pelos autores de “fuzzy decoder” — instruído a transcrever o raciocínio produzido por um modelo mais poderoso. Os testes utilizaram Claude Haiku 4.5 para traces da família Claude, GPT-5.6 Luna para traces GPT e Gemini Robotics ER-1.6 para traces Gemini. A possibilidade de reutilização entre usuários tornou logs públicos de agentes um dos principais riscos identificados pelo estudo. Dos 704 artefatos encontrados fora de benchmarks, 64 estavam exclusivamente no raciocínio oculto e não apareciam no conteúdo visível. Isso significa que remover informações sensíveis apenas do texto legível antes da publicação poderia não ser suficiente caso os blocos opacos fossem preservados. O risco demonstrado, porém, possui limites importantes. A pesquisa se concentra principalmente em desenvolvedores que publicaram logs brutos de agentes contendo os objetos de raciocínio intactos, e não demonstra comprometimento generalizado de todos os usuários dessas APIs. A portabilidade dos blocos também possibilitou uma prova de conceito de prompt injection invisível. Os pesquisadores criaram um objeto de raciocínio opaco contendo uma instrução maliciosa e posteriormente o reutilizaram em uma tarefa não relacionada. O modelo receptor acabou adicionando uma ação de upload controlada pelo atacante sem que a instrução maliciosa aparecesse no texto visível. Os autores alertam que não possuem acesso ao texto original dos raciocínios proprietários e, portanto, não podem garantir que todas as reconstruções sejam cópias exatas. A fidelidade foi avaliada por meio da quantidade de tokens de raciocínio e comparações qualitativas, com o tamanho dos conteúdos extraídos geralmente acompanhando as contagens de tokens informadas pelos provedores. As descobertas foram comunicadas à OpenAI, Anthropic, Google, Microsoft e Hugging Face. Segundo os pesquisadores, os ataques demonstrados deixaram de funcionar após a implementação de mitigações, e a principal técnica de extração já não era reproduzível em agosto de 2026. A documentação atual indica que os mecanismos de raciocínio criptografado continuam presentes nas APIs, mas seu tratamento foi alterado. A OpenAI ainda orienta desenvolvedores a reutilizar itens de raciocínio criptografados ao administrar manualmente históricos stateless. O Google afirma que sua infraestrutura gerencia a compatibilidade do raciocínio quando uma sessão muda de modelo. A Anthropic, por sua vez, informa atualmente que os blocos de thinking ficam vinculados ao modelo que os produziu e devem ser removidos durante uma troca de modelo, pois outros modelos os ignoram. Apesar das correções relatadas pelos pesquisadores, permanecem algumas questões em aberto. Até o momento descrito pelo estudo, não havia reconhecimento público da vulnerabilidade pelos três provedores nem confirmação independente de que as alterações atuais em suas APIs estão diretamente relacionadas à pesquisa. Também não está claro se os blocos de raciocínio que já haviam sido publicados em repositórios públicos continuam passíveis de decodificação. Essa questão é diferente de determinar se novos ataques ainda podem ser executados contra as APIs atuais. O trabalho amplia uma pesquisa publicada em maio pelo criptógrafo Matthew Green, da Johns Hopkins, que demonstrou que blocos de raciocínio criptografados poderiam ser reutilizados entre sessões e contas, mas não apresentou um método confiável para extração de segredos. O novo estudo transforma esse comportamento de replay em uma técnica mais ampla e demonstra suas possíveis consequências para privacidade. Não há evidências apresentadas no relatório de que a vulnerabilidade tenha sido explorada maliciosamente. Como medida preventiva, desenvolvedores devem remover blocos e campos opacos de raciocínio antes de compartilhar traces e evitar publicar transcrições brutas de APIs, mesmo quando o conteúdo textual visível já tiver sido sanitizado.

A Adobe lançou atualizações de segurança para corrigir diversas vulnerabilidades críticas no ColdFusion, Commerce e Campaign Classic. As falhas podem permitir execução arbitrária de código, escalonamento de privilégios e, em determinados casos, comprometimento de contas e acesso a dados de clientes. Três vulnerabilidades receberam a pontuação máxima de 10,0 no CVSS. No ColdFusion, a CVE-2026-48362 é uma falha de injeção de comandos do sistema operacional que pode permitir a execução arbitrária de código. O problema foi corrigido nas versões 2025.0.12 e 2023.0.23. O ColdFusion também recebeu correções para a CVE-2026-48273, classificada com CVSS 9,9, uma vulnerabilidade de eval injection capaz de levar à execução de código, e para a CVE-2026-71384, com CVSS 9,6, relacionada a autorização incorreta e que pode provocar negação de serviço na aplicação. No Adobe Commerce, a CVE-2026-71362, com pontuação CVSS 9,1, é uma vulnerabilidade de autorização incorreta capaz de resultar em escalonamento de privilégios. Após a divulgação inicial, a empresa de segurança Sansec identificou indícios de que essa falha está sendo explorada por invasores. Segundo a Sansec, a CVE-2026-71362 permite que um atacante altere uma sessão de cliente para a conta de outro usuário. Com isso, o invasor pode obter acesso à conta da vítima e a informações privadas armazenadas na plataforma. A vulnerabilidade também afeta o Magento Open Source. No Campaign Classic, duas falhas de autorização incorreta receberam a pontuação máxima: CVE-2026-71398 e CVE-2026-27302. Ambas podem permitir execução arbitrária de código e foram corrigidas no ACC v7 7.4.4 build 9400. A mesma atualização resolve a CVE-2026-48381, uma vulnerabilidade de SQL injection classificada com CVSS 9,0 que também pode resultar em execução arbitrária de código. As atualizações do ColdFusion e do Campaign Classic receberam da Adobe classificação Priority 1, reservada a vulnerabilidades consideradas de maior risco de serem utilizadas em ataques. No caso do Campaign Classic, as correções se aplicam apenas às instalações totalmente on-premise e aos componentes locais de ambientes híbridos. Instâncias hospedadas pela própria Adobe já foram corrigidas e não exigem nenhuma ação dos clientes. Inicialmente, não havia evidências de exploração das vulnerabilidades divulgadas. A recomendação era instalar as atualizações o mais rapidamente possível, preferencialmente em até 72 horas. Posteriormente, porém, surgiram indícios de exploração da CVE-2026-71362 contra Adobe Commerce e Magento Open Source. As novas correções chegam menos de duas semanas depois de a Adobe solucionar outra vulnerabilidade de severidade máxima no Campaign Classic. Identificada como CVE-2026-48449, com CVSS 10,0, a falha também poderia resultar em execução arbitrária de código.

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.