A Agência de Segurança Cibernética e de Infraestrutura dos Estados Unidos (CISA) adicionou quatro vulnerabilidades críticas que afetam Apple macOS, Microsoft SharePoint, VMware vCenter e Microsoft Internet Key Exchange (IKE) ao catálogo Known Exploited Vulnerabilities (KEV), indicando que as falhas já estão sendo exploradas em ataques reais. Todas as vulnerabilidades receberam correções de seus respectivos fabricantes, mas relatos públicos apontam diferentes campanhas de exploração. Três das quatro falhas possuem pontuação CVSS 9,8. No macOS, a CVE-2026-65400 é uma vulnerabilidade de autenticação inadequada que pode permitir que um invasor conectado à rede se autentique no recurso Screen Sharing sem possuir credenciais válidas. A falha recebeu CVSS 9,8 e já foi utilizada em ataques para instalar um minerador da criptomoeda Monero. A CVE-2026-55040, com CVSS 9,1, afeta o Microsoft SharePoint. O problema está relacionado a um mecanismo de autenticação fraco e pode permitir que um invasor não autorizado contorne um recurso de segurança remotamente. Segundo relatos públicos, a exploração da vulnerabilidade no SharePoint começou após a divulgação de um código proof-of-concept (PoC). Até o momento, os responsáveis pelos ataques não foram identificados. Ataques ao VMware vCenter atingem 47 países Entre as vulnerabilidades adicionadas ao catálogo está a CVE-2026-59310, falha crítica de path traversal no VMware vCenter, da Broadcom, com pontuação CVSS 9,8. Um invasor com acesso de rede ao vCenter pode explorar o problema para executar código arbitrário. A exploração foi associada a um possível grupo de ameaça persistente avançada (APT) ligado à China. Os ataques utilizaram um backdoor e binários "reverse_ssh" para manter acesso persistente aos servidores comprometidos. Em pelo menos um caso, a invasão também resultou na implantação de um ransomware derivado do Babuk. A campanha comprometeu 361 endereços IP únicos de vítimas em 47 países. A maior concentração foi registrada na Alemanha, com 55 sistemas afetados, seguida pelos Estados Unidos, com 41; Turquia, com 38; Irã, com 26; e França, com 25. Falha no Microsoft IKE também é explorada A quarta vulnerabilidade, CVE-2026-33824, possui CVSS 9,8 e afeta as extensões do serviço Microsoft Internet Key Exchange (IKE). Trata-se de uma falha do tipo "double free" que pode permitir a execução remota de código por um invasor não autenticado através da rede. De acordo com a Unit 42, da Palo Alto Networks, a vulnerabilidade vem sendo explorada por outro grupo de hackers de língua chinesa. A atividade foi observada em paralelo a uma campanha autônoma de hacking baseada em inteligência artificial, na qual os responsáveis utilizaram o DeepSeek, além de conduzirem operações manuais explorando vulnerabilidades conhecidas, incluindo a falha no Microsoft IKE. A inclusão das quatro vulnerabilidades no catálogo KEV representa uma confirmação da CISA de que existem evidências de exploração ativa. Órgãos civis federais dos Estados Unidos têm até 21 de agosto de 2026 para atualizar os sistemas vulneráveis e seguir as diretrizes de correção estabelecidas pela BOD 26-04. Para outras organizações, a presença das vulnerabilidades no KEV aumenta a prioridade das atualizações, principalmente em sistemas acessíveis pela rede ou expostos à internet.

Pesquisadores da Varonis Threat Labs divulgaram três vulnerabilidades no Microsoft Copilot Personal que poderiam permitir que um invasor roubasse silenciosamente dados de aplicativos conectados após a vítima clicar em um link especialmente preparado. As falhas foram agrupadas sob o nome CoSnitch e são rastreadas como CVE-2026-24301. Segundo a Varonis, o problema foi reportado à Microsoft em dezembro de 2025 e recebeu correções em 18 de agosto de 2026. A pesquisa trata especificamente do Copilot Personal, versão para consumidores disponível em copilot.microsoft.com. O relatório não afirma que o mesmo comportamento afetava o Microsoft 365 Copilot. Não foram encontradas evidências de exploração da CoSnitch em ataques reais. Um dos pontos centrais da descoberta foi um parâmetro de URL não documentado chamado "autorun=1". Curiosamente, segundo os pesquisadores, o próprio Copilot revelou sua existência durante os testes. A Varonis utilizou uma abordagem que chama de "meta-hacking": os pesquisadores perguntaram repetidamente ao Copilot por que determinado prompt não poderia ser executado automaticamente, sem interação do usuário. Nas respostas, o assistente forneceu justificativas técnicas até mencionar o parâmetro "autorun=1", as condições necessárias para seu funcionamento e mecanismos de proteção que supostamente deveriam tê-lo desabilitado. Quando os pesquisadores construíram uma URL seguindo as informações fornecidas pelo próprio Copilot, descobriram que o parâmetro ainda funcionava. O ataque combinava "autorun=1" com o parâmetro existente "q". Isoladamente, "q" apenas preenche o campo de entrada do Copilot. Quando os dois eram utilizados juntos, porém, um prompt controlado pelo atacante podia ser executado automaticamente assim que a vítima abrisse o link. Segundo a Varonis, depois de iniciada, a execução continuava até o fim mesmo que a vítima fechasse imediatamente a aba do Copilot. Dados de e-mail, calendário e Google Drive podiam ser acessados A primeira vulnerabilidade identificada permitia a execução automática do prompt dentro da sessão autenticada da vítima. Na prática, a instrução fornecida pelo invasor recebia as mesmas capacidades que um comando digitado diretamente pelo usuário. A segunda possibilitava utilizar esse prompt para consultar serviços que a vítima já havia autorizado no Copilot. Os dados obtidos podiam ser codificados e enviados para um webhook controlado pelo invasor por meio do próprio recurso de acesso a URLs do assistente. A técnica não concedia novas permissões ao Copilot nem ampliava os privilégios da vítima. O ataque explorava os acessos que o usuário já havia autorizado. Durante os testes, os pesquisadores afirmam ter conseguido recuperar conteúdo de mensagens de e-mail, assuntos, remetentes e destinatários. Também foram acessados títulos de eventos do calendário, participantes, horários e locais. No Google Drive, o Copilot retornou nomes de arquivos e resumos de metadados. Os pesquisadores também conseguiram obter conversas anteriores mantidas com o assistente, além de instruções e regras armazenadas na memória do Copilot. A documentação da Microsoft estabelece que serviços externos precisam ser previamente autorizados pelo usuário e que os conectores operam utilizando as permissões existentes da conta. Portanto, a exploração não dava ao invasor acesso a informações que o próprio usuário não pudesse acessar por meio do Copilot. Segundo a Varonis, as solicitações utilizadas para retirar os dados também poderiam parecer, no nível de rede, semelhantes aos acessos realizados normalmente pelo Copilot ao resumir páginas da web. A codificação em Base64 poderia ainda dificultar filtros que procuram determinados padrões de informações sensíveis em requisições de saída. Ataque também podia manipular a memória do Copilot A terceira vulnerabilidade identificada pela Varonis utiliza um caminho diferente. Uma página web maliciosa poderia inserir instruções na memória do Copilot quando seu conteúdo fosse resumido pelo assistente. Essas instruções poderiam permanecer armazenadas e influenciar conversas futuras, caracterizando um ataque de envenenamento de memória por meio de prompt injection indireto. De acordo com os pesquisadores, a instrução persistente sobrevivia a mudanças de senha, revogação de sessão e novo registro do dispositivo. Ela permanecia ativa até ser explicitamente excluída nas configurações de memória do Copilot. A Varonis afirma ainda que essa alteração não gerava processo, arquivo ou conexão de rede específica que pudesse ser facilmente identificada por ferramentas tradicionais de segurança. A instrução armazenada podia ser visualizada na própria interface de memória do Copilot. Problemas relacionados à manipulação da memória de assistentes da Microsoft já haviam sido reportados anteriormente. Pesquisadores como Håkon Måløy e Johann Rehberger documentaram técnicas envolvendo prompt injection e memória tanto no Microsoft 365 Copilot quanto no assistente voltado ao consumidor. A Microsoft também abordou essa classe de ataques em junho, explicando que, no Microsoft 365 Copilot, as memórias passam por mecanismos de sanitização e detecção de prompt injection. A empresa também afirmou que atualizações de memória no ambiente corporativo podem ser registradas em logs de auditoria e consultadas por ferramentas como Defender Advanced Hunting e Sentinel. Essas informações, porém, dizem respeito ao Microsoft 365 Copilot, e não necessariamente ao Copilot Personal analisado pela Varonis. Microsoft corrigiu as vulnerabilidades A Varonis recomenda que usuários revisem quais aplicativos estão conectados ao Copilot e desconectem aqueles que não são necessários, além de terem cautela com links que abrem diretamente assistentes de inteligência artificial. Não foi indicada nenhuma atualização de cliente que precise ser instalada pelos usuários. Segundo a Varonis, a Microsoft implementou as correções em 18 de agosto. O relatório também não esclarece se a correção remove automaticamente eventuais instruções maliciosas gravadas na memória antes da atualização. A Varonis afirma que memórias injetadas permanecem armazenadas até serem explicitamente excluídas. A descoberta ocorre menos de duas semanas depois de a mesma equipe divulgar o RovoBlast, ataque de um clique contra o assistente Rovo, da Atlassian. Nesse caso, um parâmetro de URL também podia ser utilizado para inserir instruções controladas pelo invasor na sessão autenticada de um usuário.

Uma vulnerabilidade crítica foi descoberta no Forminator Forms, plugin para WordPress com mais de 600 mil instalações ativas. A falha pode permitir que invasores sem autenticação enviem arquivos PHP maliciosos e, sob determinadas condições, executem código remotamente no servidor. Identificada como CVE-2026-15748, a vulnerabilidade recebeu pontuação 9,8 de 10 no sistema CVSS. O problema foi descoberto e reportado por um pesquisador que utiliza o pseudônimo "daroo". Segundo a Wordfence, a falha permite o upload arbitrário de arquivos, incluindo código PHP executável. Caso a exploração seja bem-sucedida, um invasor pode alcançar execução remota de código (RCE) e potencialmente assumir o controle completo do site. A vulnerabilidade afeta todas as versões do Forminator até a 1.56.1. A correção foi disponibilizada na versão 1.56.2, lançada em 31 de julho de 2026. A exploração, porém, depende de uma configuração específica. O site vulnerável precisa possuir um formulário contendo simultaneamente um campo de upload de arquivos e um campo do tipo Select. Tecnicamente, o problema está na função "handle_file_upload()", que não realiza validação suficiente do tipo de arquivo fornecido pelo usuário. A lista utilizada pelo plugin para bloquear extensões perigosas faz uma correspondência exata que pode ser contornada por chaves de tipos MIME com alternativas separadas por pipe. Esse comportamento é combinado com um manipulador público de submissões que aceita configurações do campo de upload controladas pelo invasor e inseridas por meio de um valor Select forjado. Dessa forma, um atacante sem autenticação pode enviar um formulário especialmente preparado e fazer upload de um arquivo PHP malicioso. Se o arquivo puder ser executado pelo servidor web, o atacante passa a executar seu próprio código no ambiente WordPress, abrindo caminho para o comprometimento completo do site. Por padrão, os arquivos enviados pelo Forminator são armazenados em um diretório protegido por um arquivo ".htaccess" que impede a execução de PHP, o que reduz a possibilidade de exploração em instalações com a configuração padrão. O risco aumenta quando o administrador configura um diretório personalizado para armazenamento dos uploads. Segundo a Wordfence, esse local pode não receber a mesma proteção porque o diretório é criado somente quando necessário, durante uma requisição no frontend em que o componente do WordPress responsável por gerar o arquivo ".htaccess" não está carregado. Nessa situação, acessar diretamente o arquivo PHP enviado pode ser suficiente para que o servidor execute o código controlado pelo invasor. Outra falha crítica permite assumir conta de administrador A divulgação ocorre poucos dias depois de a Wordfence detalhar outra vulnerabilidade crítica, desta vez no plugin User Profile Builder, presente em mais de 40 mil instalações ativas do WordPress. Registrada como CVE-2026-15826 e também classificada com CVSS 9,8, a falha pode permitir que um invasor sem autenticação faça login como o usuário de ID 1, normalmente correspondente ao administrador do WordPress, e assuma o controle do site. O problema afeta todas as versões anteriores à 3.16.5, lançada em 16 de julho de 2026. Entretanto, a vulnerabilidade só pode ser explorada em sites que tenham a configuração "Automatically Log In" habilitada. A falha ocorre na função "wppb_log_in_user()". Quando um registro é realizado com um nome de usuário entre 61 e 70 caracteres, o núcleo do WordPress rejeita a solicitação e retorna um objeto WP_Error. O plugin, porém, chama a função "absint()" antes de verificar esse erro. O objeto acaba sendo convertido para o número inteiro 1, fazendo com que o mecanismo de login automático associe a operação ao usuário de ID 1. Com isso, um invasor não autenticado pode obter acesso à conta de administrador e assumir o controle do site. Administradores que utilizam o Forminator Forms devem atualizar o plugin para a versão 1.56.2 ou posterior. Já usuários do User Profile Builder devem instalar a versão 3.16.5 ou mais recente, especialmente em ambientes onde o login automático está habilitado.

Pesquisadores da Wiz identificaram uma vulnerabilidade de injeção de comandos em um workflow do GitHub Actions no repositório público snowflakedb/snowflake-connector-net, da Snowflake. Durante testes autorizados, a falha permitiu executar comandos a partir de uma issue especialmente preparada e obter um token de API interno do Jira. O problema estava no arquivo ".github/workflows/jira_issue.yml", executado automaticamente quando uma issue pública era aberta no repositório. O mesmo workflow tinha acesso às variáveis JIRA_BASE_URL, JIRA_USER_EMAIL e JIRA_API_TOKEN. Segundo a análise, o título e o conteúdo das issues, controlados por usuários externos, eram inseridos diretamente em um bloco shell "run:". Isso criava uma condição de workflow injection, na qual dados não confiáveis podiam ser interpretados como comandos pelo runner do GitHub Actions. O workflow também verificava a propriedade "github.event.pull_request.user.login", embora o evento processado fosse uma issue. Como essa propriedade de pull request não existia naquele contexto, o GitHub Actions a avaliava como uma string vazia. Com isso, a comparação utilizada para bloquear determinados eventos não impedia que uma issue comum chegasse à etapa vulnerável. Durante testes de segurança autorizados, o sistema Red Agent, da Wiz, tentou explorar a injeção. Depois que um primeiro payload provocou um erro de sintaxe no shell, o sistema alterou a abordagem e conseguiu receber uma conexão externa originada do runner do GitHub Actions. Os pesquisadores afirmam que, a partir da exploração, conseguiram obter o token da API do Jira utilizado pelo workflow. De acordo com a Wiz, a credencial pertencia à conta qa@snowflake.net e fornecia acesso de leitura a projetos internos relacionados a engenharia, conformidade de segurança e acompanhamento de programas de bug bounty no ambiente Jira da Snowflake. As permissões completas da conta, os registros de execução do workflow e os logs de auditoria do Jira não foram divulgados publicamente. A Wiz informou a vulnerabilidade à Snowflake por meio do HackerOne em 23 de junho de 2026, no relatório #3819931. A empresa implementou uma correção no mesmo dia por meio do pull request #1402. A mudança eliminou a expansão direta das expressões provenientes do GitHub dentro do shell. Os dados passaram a ser armazenados em variáveis de ambiente e fornecidos ao "jq" como argumentos, reduzindo o risco de que conteúdo controlado por usuários seja interpretado como comandos. O workflow vulnerável havia chegado à branch padrão cinco dias antes, em 18 de junho, após a integração do pull request #1218. O tratamento corrigido permanece na branch master do repositório. Segundo declaração da Snowflake reproduzida pela Wiz, a investigação da empresa não encontrou evidências de acesso não autorizado. O token do Jira foi rotacionado em 24 de junho, e a análise também não teria identificado uso externo não relacionado da credencial durante os cinco dias em que ela ficou exposta. Os logs de auditoria utilizados nessa investigação, porém, não foram publicados. Papel do GitHub Copilot não está confirmado A Wiz descreveu a vulnerabilidade como resultado de uma alteração do GitHub Copilot Autofix, mas o histórico disponível no GitHub não confirma que o Copilot tenha sido responsável especificamente pelas linhas vulneráveis do arquivo "jira_issue.yml". O commit explicitamente identificado como coautorado pelo Copilot, 6d0e2fa, modificou o arquivo "jira_close.yml". Já a alteração insegura em "jira_issue.yml" aparece em outro commit, 094038e, de 25 de agosto de 2025, atribuído pelo GitHub a sfc-gh-hpathak. Posteriormente, as duas mudanças foram incorporadas ao squash merge 4a1b8ce, de 18 de junho, que lista o Copilot Autofix entre seus coautores. O histórico confirma, portanto, a participação do Copilot no pull request #1218, mas não permite atribuir a ele a autoria do código vulnerável. O GitHub já havia documentado esse tipo de workflow injection em julho de 2025, recomendando que dados não confiáveis provenientes de issues não fossem expandidos diretamente em blocos "run:" e que variáveis de ambiente intermediárias fossem utilizadas. Até 17 de agosto de 2026, não havia CVE, pontuação CVSS ou registro no catálogo Known Exploited Vulnerabilities (KEV) da CISA associado ao problema. Também não foi identificada nenhuma versão do Snowflake Connector for .NET afetada, já que a vulnerabilidade estava restrita à automação de CI/CD do repositório. A interpolação vulnerável já foi removida da branch master. As informações disponíveis também não indicam exploração maliciosa da falha em ambiente real nem comprometimento de clientes da Snowflake.

O GitLab lançou atualizações de segurança emergenciais para corrigir uma vulnerabilidade crítica nas edições Community Edition (CE) e Enterprise Edition (EE) que, sob determinadas condições, pode permitir que invasores sem autenticação modifiquem ou excluam remotamente projetos públicos e dados de usuários. Identificada como CVE-2026-19478, a falha recebeu classificação Critical pelo GitLab e pontuação 9,4 no sistema CVSS. O problema está relacionado ao GraphQL e pode ser explorado pela rede sem que o atacante possua credenciais ou dependa de qualquer interação da vítima. A atualização foi disponibilizada em 17 de agosto de 2026, fora do calendário habitual do GitLab, que normalmente publica correções duas vezes por mês, na segunda e na quarta quarta-feira. O patch emergencial chegou apenas cinco dias depois de uma atualização regular que não continha vulnerabilidades classificadas como críticas. O problema afeta somente instalações autogerenciadas do GitLab. GitLab.com e GitLab Dedicated já executam versões corrigidas e, segundo a empresa, seus clientes não precisam tomar nenhuma medida. As correções estão disponíveis nas versões GitLab 19.2.4, 19.1.6, 19.0.8 e 18.11.11. São vulneráveis todas as versões da 18.2 anteriores à 18.11.11, a linha 19.0 antes da 19.0.8, a 19.1 antes da 19.1.6 e a 19.2 antes da 19.2.4. As ramificações 18.2 a 18.10 permanecem dentro da faixa afetada e não receberam a correção. Administradores que utilizam essas versões precisam migrar para uma versão suportada que contenha o patch. De acordo com o GitLab, a CVE-2026-19478 pode permitir que um usuário não autenticado modifique ou exclua projetos públicos e dados de usuários por meio de uma diretiva GraphQL. A empresa, porém, não informou qual diretiva está envolvida nem detalhou as condições específicas necessárias para explorar a vulnerabilidade. Até 18 de agosto, o alerta de segurança não indicava exploração ativa da falha, e nenhum código público de exploração havia sido identificado no GitHub. A mesma atualização também corrige a CVE-2026-19650, vulnerabilidade de alta severidade com pontuação CVSS 7,1. O problema consiste em uma falha de Cross-Site Request Forgery (CSRF) no mecanismo responsável pelo processamento de consultas GraphQL multiplex. Nesse segundo caso, a exploração exige interação do usuário. Segundo o GitLab, a vulnerabilidade poderia permitir, sob determinadas condições, que um usuário não autenticado executasse mutações por meio de requisições GET devido à validação inadequada das solicitações no processamento de consultas GraphQL multiplex. A empresa informou que a atualização não introduz novas migrações e não deve exigir indisponibilidade em implantações com múltiplos nós. A divulgação ocorre após pesquisadores publicarem, em julho de 2026, código de exploração funcional para outra vulnerabilidade que afetava servidores GitLab autogerenciados. O GitLab também informou que os registros detalhando cada vulnerabilidade serão publicados em seu rastreador de issues 90 dias após o lançamento das respectivas correções. Com isso, informações técnicas adicionais sobre as CVE-2026-19478 e CVE-2026-19650 devem se tornar públicas por volta de meados de novembro de 2026.

Pesquisadores de segurança identificaram uma campanha de typosquatting que distribuiu pacotes maliciosos nos ecossistemas RubyGems e npm para infectar computadores Windows e roubar credenciais de navegadores, carteiras de criptomoedas, seed phrases, dados do Telegram e outras informações sensíveis. A atividade foi descoberta pela OpenSourceMalware em 15 de agosto de 2026 e recebeu o nome de StubMaker. Inicialmente, a investigação encontrou 16 pacotes maliciosos publicados no RubyGems. Uma atualização posterior revelou que o mesmo responsável também distribuiu 37 pacotes no npm, totalizando 53 pacotes associados à campanha. No RubyGems, foram identificados os pacotes ubnuler, ubnlder, ri18nr, reaker, rakier, orakw, joxn, ise18n, ioe18n, ie18u, iai8n, i1l8n, i18om, activesupmport, brumdler e brundlef. Segundo os pesquisadores, os nomes tentavam imitar dependências Ruby populares por meio de pequenos erros de digitação, técnica conhecida como typosquatting. Os 16 gems foram publicados por contas identificadas como "mod8rz41mje", associada ao nome Riley Miller, e "rbq95bwt6q", vinculada a Alex Davis. Os pacotes já foram removidos do RubyGems. Em pelo menos dois casos, brumdler e brundlef, os invasores também exploraram um comportamento do RubyGems que permite que um namespace seja reivindicado novamente depois que todas as versões anteriores de um gem são removidas. Os pacotes haviam sido originalmente publicados por outra conta antes de serem recuperados pelos responsáveis pela campanha. Jenn Gile, cofundadora da OpenSourceMalware, afirmou que essa característica, combinada com a possibilidade de preencher o campo de autor sem validação, facilitou a operação. Segundo ela, depois que um gem malicioso era removido, os invasores podiam criar outra conta e publicar uma nova versão usando o mesmo nome. O campo "Author" também podia receber qualquer texto, sem precisar corresponder ao proprietário da conta. Com isso, os responsáveis atribuíram autores diferentes aos pacotes para tentar fazer com que parecessem não relacionados, embora vários deles fossem controlados pelas mesmas contas. A cadeia de ataque do StubMaker explora o arquivo "extconf.rb", normalmente usado durante a instalação de gems que possuem extensões nativas escritas em linguagens como C, C++ ou Rust. O arquivo é executado automaticamente durante a instalação do pacote, de forma semelhante aos lifecycle hooks utilizados pelo npm. No ataque, o "extconf.rb" funciona como mecanismo para baixar um loader de aproximadamente 22 MB desenvolvido em Rust e hospedado em uma release do GitHub. Esse loader executa um infostealer escrito em Go e identificado como "wincfg". A conta do GitHub utilizada na operação já não está acessível. O malware incorpora ainda a DLL "abe_payload.dll", usada para extrair credenciais de navegadores baseados em Chromium contornando as proteções App-Bound Encryption (ABE) introduzidas pelo Google. Entre os navegadores visados estão Google Chrome, Microsoft Edge, Brave, Opera, Opera GX, Vivaldi, Yandex, Avast, AVG e CCleaner Browser. Além das credenciais, o infostealer coleta dados de extensões, histórico de navegação e números de cartões de pagamento. O malware também procura carteiras de criptomoedas e seed phrases, extrai informações do Telegram Desktop, reúne dados do sistema e consulta o serviço api.ipify.org para identificar o endereço IP público da vítima. As informações roubadas são compactadas em um arquivo ZIP protegido por senha e enviadas ao serviço Gofile. O link resultante para download é então transmitido aos responsáveis pelo ataque por meio de uma conexão HTTP sem criptografia para a infraestrutura associada ao domínio "dresslee.com". O nome StubMaker está relacionado à forma como o malware mascara sua execução. Em vez de realmente compilar uma extensão, o pacote cria um Makefile com operações vazias e scripts para Unix e Windows que apenas retornam sucesso. Dessa forma, a instalação aparenta ter concluído normalmente enquanto o download e a execução do malware ocorrem no próprio hook do instalador. Campanha também atingiu o npm A investigação foi posteriormente ampliada após pesquisadores identificarem 37 pacotes npm relacionados à mesma operação. Eles utilizavam um hook "postinstall" para baixar o mesmo loader hospedado no GitHub e instalar o infostealer em sistemas Windows. Os pacotes imitavam bibliotecas populares como axios, chalk, commander, lodash, typescript e react. Entre os nomes utilizados estavam axois-http, axious-core, chalk-core, chalk-lib, comand, comander-cli, commander-lib, loadashjs, lodash-lib, typescirpt-cli, typscript-cli, typescriptt-cli e raectjs, além de diversas outras variações com erros de digitação. Segundo a OpenSourceMalware, trata-se do mesmo responsável operando duas frentes de typosquatting contra ecossistemas diferentes, compartilhando o mesmo payload e a mesma infraestrutura de comando e controle. Apesar da finalidade semelhante, a execução apresentou diferenças. Os gems utilizavam "extconf.rb", enquanto os pacotes npm recorriam ao hook "postinstall". No RubyGems, a URL do loader era codificada em Base64; no npm, o instalador empregava XOR com chave fixa para ocultá-la. O padrão de publicação também mudou. Os gems foram distribuídos durante dois dias, enquanto os pacotes npm foram enviados em apenas oito minutos por cinco contas diferentes. De acordo com Gile, a estratégia no npm reduzia a dependência de uma única conta, dificultando a interrupção de todo o lote caso apenas um perfil fosse detectado. Os pacotes npm foram publicados em 16 de agosto e também já foram removidos. A OpenHack recomenda que usuários que tenham instalado qualquer um deles em uma máquina Windows enquanto estavam disponíveis isolem o equipamento, troquem as credenciais potencialmente expostas e removam as bibliotecas maliciosas.

A empresa chinesa de inteligência artificial Zhipu apresentou o GLM-5.3, novo modelo que, segundo a companhia, alcançou desempenho superior a modelos da OpenAI e da Anthropic em um benchmark voltado à descoberta e exploração de vulnerabilidades. Nos testes divulgados pela Zhipu, o GLM-5.3 superou o Fable 5 e o GPT-5.6 Sol no CyberGym, benchmark desenvolvido para avaliar a capacidade de modelos de IA de resolver desafios de cibersegurança baseados em cenários reais. Segundo a empresa, as capacidades de segurança do modelo avançaram mais rapidamente do que o esperado durante a etapa de pós-treinamento. O principal ganho teria ocorrido não apenas na identificação de falhas isoladas, mas na capacidade de raciocinar sobre diferentes estágios de exploração. A Zhipu afirma que o GLM-5.3 passou a desenvolver planos coerentes envolvendo cadeias completas de exploração, conectando diferentes vulnerabilidades e etapas necessárias para comprometer um sistema. A companhia também testou o modelo em bases de código reais em colaboração com empresas chinesas. De acordo com os resultados divulgados, o GLM-5.3 encontrou 2.436 vulnerabilidades em 269 projetos, das quais 1.097 foram classificadas como de média a alta severidade. As falhas foram identificadas em diferentes tipos de software e infraestrutura, incluindo kernels de sistemas, sistemas operacionais, motores de navegadores, projetos de infraestrutura open source, aplicações web e protocolos de rede. Algumas dessas vulnerabilidades teriam permanecido sem identificação durante anos ou décadas. Segundo a Zhipu, a falha mais antiga encontrada pelo modelo estava presente no código havia aproximadamente 40 anos. Os resultados, porém, não indicam superioridade generalizada do GLM-5.3. O modelo chinês apresentou desempenho inferior aos concorrentes ocidentais em outros benchmarks de programação e segurança avaliados. Ainda assim, o desempenho no CyberGym e os resultados reportados em projetos reais indicam o avanço das capacidades de modelos chineses aplicados à pesquisa de vulnerabilidades. Esse tipo de tecnologia pode automatizar etapas que tradicionalmente exigem análise manual de código, investigação de falhas e desenvolvimento de cadeias de exploração. A evolução também reduz uma possível vantagem tecnológica dos Estados Unidos nessa área. Modelos avançados de IA estão sendo cada vez mais avaliados não somente pela capacidade de encontrar vulnerabilidades, mas também por compreender como diferentes falhas podem ser combinadas durante uma exploração. Os números divulgados são resultados apresentados pela própria Zhipu e devem ser interpretados dentro desse contexto. Embora o CyberGym permita comparar capacidades específicas, o desempenho de um modelo em um benchmark não necessariamente representa sua eficácia em todos os cenários de segurança ou desenvolvimento de software.

Uma análise dos 5 mil domínios mais utilizados da internet identificou violações dos padrões HTML em 87,2% dos sites avaliados. Os problemas vão de erros de estruturação do código a falhas de acessibilidade que podem dificultar a navegação de pessoas que dependem de leitores de tela. O levantamento foi realizado pelo ValidateHTML, projeto mantido pelo desenvolvedor francês independente Théo Ducreux. A seleção dos domínios foi baseada no ranking do projeto de pesquisa Tranco e inclui grandes serviços como Google, YouTube e Akamai, além de domínios utilizados principalmente para redirecionamento ou comunicação entre produtos e servidores. Dos 5 mil domínios examinados, 2.656 apresentavam uma página inicial destinada à leitura por usuários. Ainda assim, considerando todos os endereços analisados, Ducreux contabilizou 100.305 violações de HTML, incluindo especificações do HTML5, além de 18.863 erros de CSS. Segundo o levantamento, apenas 12,8% dos sites apresentavam HTML completamente válido. Quando também são considerados erros e alertas relacionados às boas práticas, somente 2,6% dos domínios passaram pela análise sem qualquer ocorrência. Os padrões definidos pelo World Wide Web Consortium (W3C) e pelo WHATWG ajudam navegadores, leitores de tela e outras ferramentas a interpretar páginas de maneira consistente. Embora navegadores modernos consigam corrigir ou ignorar muitos erros automaticamente, outras tecnologias podem ter menor tolerância a códigos fora das especificações. Esse problema aparece principalmente na acessibilidade. Mais de um terço dos sites falhou nas verificações dessa categoria. Cerca de 20,4% não apresentavam textos alternativos em imagens, recurso importante para descrever conteúdo visual a usuários de leitores de tela. Além disso, 41,6% das páginas apresentavam ausência de rótulos ARIA usados para identificar regiões e elementos da interface. A falta dessas informações pode dificultar a compreensão da estrutura de uma página por tecnologias assistivas. “Leitores de tela não têm nem de longe a tolerância a erros do Chrome, então uma marcação que parece perfeitamente normal para você pode estar quebrada para alguém usando tecnologia assistiva”, afirmou Ducreux. As falhas de acessibilidade também podem representar um problema de conformidade. Na Europa, o European Accessibility Act, em vigor desde 2025, ampliou as exigências relacionadas à acessibilidade de determinados produtos e serviços digitais. Nos Estados Unidos, empresas também podem enfrentar disputas relacionadas à falta de acessibilidade de serviços online. Para realizar o estudo, Ducreux desenvolveu seu próprio web crawler e utilizou ferramentas open source como HTML-validate, CSS Validator, Lightning CSS e fast-xml-parser. O código do site, o sistema de pontuação e a lógica utilizada no rastreamento foram desenvolvidos por ele, sem equipe, financiamento ou empresa por trás do projeto. Um dos fatores que contribuem para o problema é justamente a capacidade dos navegadores modernos de interpretar códigos incorretos. Em muitos casos, erros de HTML não provocam consequências visíveis porque o navegador tenta reconstruir automaticamente a estrutura pretendida pelo desenvolvedor. Frameworks de front-end também podem introduzir problemas durante o processo de construção das páginas. A falha mais frequente encontrada pelo ValidateHTML, presente em mais de 59% dos sites, foi o posicionamento incorreto de elementos, incluindo aninhamento inadequado de tags. Segundo Ducreux, muitos desses erros são criados automaticamente durante o processo de build e não necessariamente escritos manualmente pelos desenvolvedores. O próprio pesquisador não considera o HTML inválido uma ameaça à existência da web, principalmente porque navegadores são capazes de contornar grande parte dessas inconsistências. O impacto, porém, torna-se mais relevante quando as páginas são processadas por outras tecnologias. Agentes de inteligência artificial, assistentes de voz, ferramentas de tradução e leitores de tela também precisam interpretar a estrutura das páginas. Para Ducreux, seguir as especificações ajuda a garantir que o conteúdo tenha o mesmo significado para diferentes sistemas, em vez de depender exclusivamente da capacidade dos navegadores de corrigir erros.

A Stripe teria fechado um acordo para adquirir a OpenRouter por pelo menos US$ 7 bilhões, em uma operação que colocaria uma das maiores empresas de pagamentos digitais em uma posição estratégica na infraestrutura usada para acessar e comercializar modelos de inteligência artificial. A OpenRouter funciona como um gateway de IA, permitindo que desenvolvedores e empresas utilizem diferentes modelos por meio de uma única plataforma, sem precisar criar integrações separadas para cada fornecedor. Com a aquisição, a Stripe passaria a atuar como intermediária não apenas dos pagamentos, mas também do consumo de tokens entre empresas, aplicações e provedores de IA. A Stripe não confirmou a negociação. A empresa informou que não comenta rumores ou especulações. Antes das informações sobre a conclusão de um acordo, reportadas pela Bloomberg, o Wall Street Journal já havia noticiado que as companhias estavam negociando uma possível aquisição. Para Akhil Verghese, fundador e CEO da desenvolvedora de software de IA Krazimo, existe uma relação direta entre os negócios das duas empresas: enquanto a Stripe criou uma camada de infraestrutura para pagamentos, a OpenRouter ocupa uma posição semelhante entre aplicações e modelos de IA. O valor estimado da operação chama atenção. Segundo Verghese, a OpenRouter havia captado recursos em maio com uma avaliação pós-investimento de US$ 1,3 bilhão. Uma aquisição por pelo menos US$ 7 bilhões representaria uma valorização superior a cinco vezes em apenas três meses. A lógica estratégica estaria no crescimento do consumo de tokens. Um estudo econômico chamado “AI Premium” estima que modelos de linguagem processam globalmente entre 5 e 7 quadrilhões de tokens por mês, com aproximadamente 2% desse volume passando pela OpenRouter. A plataforma também vem crescendo rapidamente. Em dezembro de 2025, a OpenRouter informava atender mais de 5 milhões de desenvolvedores, conectando usuários a mais de 300 modelos de mais de 70 fornecedores. Atualmente, a empresa afirma possuir mais de 10 milhões de desenvolvedores e trabalhar com 80 provedores. Dados citados pela Andreessen Horowitz mostram a escala desse mercado. Em outubro de 2025, a OpenAI processava aproximadamente 8,6 trilhões de tokens diariamente, enquanto a OpenRouter já ultrapassava 1 trilhão de tokens por dia. Esse crescimento ocorre enquanto empresas buscam reduzir a dependência de um único fornecedor de IA. Embora OpenAI e Anthropic tenham desenvolvido ecossistemas em torno de seus próprios modelos, clientes corporativos podem optar por gateways para alternar entre diferentes tecnologias, controlar custos e preservar poder de negociação. Nesse cenário, serviços como a OpenRouter ocupam uma camada intermediária cada vez mais relevante. Em vez de uma aplicação depender diretamente de um único modelo, um gateway pode encaminhar solicitações para diferentes provedores conforme requisitos como preço, desempenho e disponibilidade. Modelos de pesos abertos também estão conquistando uma parcela maior desse mercado. Segundo dados da Vercel, a participação desses modelos nos gastos com tokens processados por gateways aumentou de 11% em abril para 36% em julho. No mesmo período, a parcela dos gastos destinada aos quatro maiores laboratórios de modelos de fronteira, que havia permanecido acima de 93% durante sete meses, caiu para 89%. Parte da mudança foi associada ao crescimento de laboratórios chineses como Z.ai e Moonshot, com modelos GLM 5.2 e Kimi K3. Apesar da expansão das alternativas abertas, os principais laboratórios norte-americanos continuam concentrando a maior parcela da receita. Segundo a Vercel, eles receberam 95% dos gastos realizados por meio de seu AI Gateway em junho. A Anthropic, por exemplo, recebeu 65% dos gastos processados pelo gateway da Vercel em julho, embora representasse 30% do volume de tokens. O preço médio de seus tokens foi 4,4 vezes superior à média dos demais laboratórios. Ao mesmo tempo, os modelos de pesos abertos estão capturando mais receita. Depois de quase triplicarem sua participação no volume de tokens entre abril e junho, de 11% para 29%, sua participação na receita passou de cerca de quatro para quase nove centavos de cada dólar movimentado pelos gateways. O avanço ocorreu mesmo com uma redução de 13,6% no preço médio dos tokens em julho. Caso empresas continuem distribuindo suas cargas entre diferentes modelos, especialmente alternativas abertas e mais econômicas, os gateways de IA podem assumir um papel ainda maior na infraestrutura do setor. Para a Stripe, controlar uma plataforma desse tipo significaria ter visibilidade tanto sobre os pagamentos quanto sobre o fluxo de consumo de modelos. A possível aquisição também levanta dúvidas sobre a neutralidade da OpenRouter. Verghese observa que um gateway deve encaminhar cargas de trabalho de acordo com as necessidades dos clientes, sem favorecer determinados fornecedores. Caso essa independência seja comprometida sob o controle da Stripe, a confiança na plataforma poderia ser afetada.

Uma vulnerabilidade crítica no VMware vCenter está sendo explorada em uma campanha atribuída, com confiança moderada, a um grupo hacker de língua chinesa. Os ataques exploram a CVE-2026-59310, falha com pontuação CVSS 9,8 que permite execução arbitrária de código e foi corrigida pela Broadcom em 29 de julho. A atividade começou apenas cinco dias após a divulgação pública da vulnerabilidade. Segundo a empresa alemã de resposta a incidentes QUIRSO, a campanha teria comprometido 361 endereços IP únicos em 47 países. Alemanha aparece com 55 sistemas afetados, seguida por Estados Unidos, com 41; Turquia, 38; Irã, 26; e França, 25. A atribuição a um agente relacionado à China é baseada em diferentes indícios, incluindo artefatos em chinês nos scripts criados pelos invasores, possível reutilização de pesquisas publicadas por uma fonte chinesa, ferramentas e softwares de gerenciamento em chinês, ausência de vítimas na China continental e horários de atividade compatíveis com o fuso UTC+08:00. A investigação também encontrou evidências da exploração da CVE-2026-59309, uma vulnerabilidade de bypass de autenticação no vCenter que vem sendo alvo de varreduras. Atividades maliciosas compatíveis com sua exploração foram identificadas já em 1º de agosto, seguidas pela criação de uma conta administrativa no ambiente. Os pesquisadores, entretanto, não encontraram sobreposição entre essa atividade e a cadeia de ataque posteriormente associada à CVE-2026-59310 no mesmo servidor. A conta “vcenter_admin” criada durante a primeira atividade também não foi utilizada nas etapas seguintes. Na exploração da CVE-2026-59310, os invasores abusaram do serviço cron do Linux. Um arquivo malformado chamado “zz-poc59310-syslog.log” foi registrado e, posteriormente, comandos curl ou wget foram utilizados para baixar e executar um backdoor a partir de infraestrutura controlada pelos atacantes. O nome do arquivo faz referência direta à CVE e a um proof-of-concept (PoC) desenvolvido após a divulgação da vulnerabilidade. Segundo a QUIRSO, os indícios sugerem que o servidor de syslog do vCenter Server Appliance (vCSA) foi abusado para inserir arquivos em um diretório privilegiado utilizado pelo cron. Pelo menos um deles conseguiu executar e instalar o backdoor chamado “linuxFile”. Esse malware fornece capacidade de execução remota de comandos. O implante estabelece uma conexão WebSocket com o servidor de comando e controle (C2), recebe instruções, executa comandos por meio do /bin/sh e envia os resultados de volta aos invasores. O endereço do C2 é ofuscado com XOR e a comunicação utiliza criptografia própria do malware, mesmo sobre uma conexão ws:// sem criptografia de transporte. O backdoor também consegue restabelecer automaticamente a comunicação após falhas e possui mecanismos de persistência utilizando systemd e cron. Os invasores recorreram extensivamente ao cron para executar outras cargas maliciosas. Entre elas estava o script “esxi.sh”, utilizado para baixar e instalar uma ferramenta de reverse SSH específica para a arquitetura do sistema. Esse mecanismo permitia manter um canal de acesso remoto à infraestrutura comprometida. Para dificultar a identificação das atividades, alguns cronjobs receberam nomes semelhantes aos de serviços legítimos da VMware, como vmware-vpxd-stats-*, vmware-perf-collect-* e vmware-perf-sync-*. Esses mecanismos foram utilizados para adicionar chaves SSH dos invasores, instalar um web shell JSP chamado “vmware-perf-update.jsp”, acessar credenciais e criar novas contas administrativas. Uma delas, chamada “adminuser”, foi adicionada ao grupo de administradores do vSphere SSO. A campanha também envolveu a criação de outras contas, como “vcadmin”, além da manipulação do VMware Directory Service (vmdir). Em uma das técnicas observadas, os invasores criaram o arquivo /etc/sudoers.d/vmware-perf, concedendo à conta de serviço perfcharts acesso irrestrito ao root via sudo, sem necessidade de senha. Scripts executados pelos hackers ainda buscavam credenciais do vmdir diretamente no sistema. Caso o primeiro método falhasse, o ataque procurava módulos Python da VMware para obter informações associadas à conta da máquina vCenter. As credenciais eram então utilizadas para realizar alterações privilegiadas no diretório. Após consolidar o controle do vCenter, os responsáveis pela campanha utilizaram APIs do vSphere para reconhecimento do ambiente e o script “esxi.sh” para distribuir o cliente reverse SSH. Contas locais também foram criadas nos hosts ESXi, preparando o ambiente para etapas posteriores. A cadeia de ataque terminou, no sistema analisado pela QUIRSO, com a implantação de um ransomware nos servidores ESXi. O malware criptografou arquivos utilizando a extensão .babyk, normalmente associada a variantes derivadas do ransomware Babuk. Ainda não está claro, porém, se a implantação do ransomware era o objetivo principal da operação. A QUIRSO analisou apenas um dos sistemas comprometidos e não conseguiu determinar se o ransomware foi distribuído para outras vítimas da campanha. Os pesquisadores consideram a possibilidade de o ransomware ter sido utilizado como uma espécie de cortina de fumaça. Ao criptografar também logs dos servidores ESXi, o malware poderia eliminar dados de telemetria importantes e dificultar a reconstrução das atividades anteriores dos invasores. A CVE-2026-59310 foi particularmente perigosa porque forneceu execução de código diretamente como root no vCenter Server Appliance. Dessa forma, comandos posteriores já eram executados com privilégios máximos, sem que os invasores precisassem comprometer primeiro uma conta local comum e realizar elevação de privilégios. Em uma atualização da investigação, a QUIRSO também identificou um repositório no GitHub chamado “pikpak0066/tmpclean”, criado em 14 de agosto e associado à mesma infraestrutura. Embora apresentado como um programa em Go para remover arquivos antigos do diretório /tmp no Linux, a análise encontrou binários reverse_ssh relacionados à campanha. O programa verifica o diretório /tmp e remove arquivos, links simbólicos, sockets e outros itens modificados há pelo menos 24 horas, repetindo a operação a cada hora. Como grande parte dos artefatos maliciosos observados durante os ataques era armazenada nesse diretório, os pesquisadores suspeitam que a ferramenta seja utilizada para apagar sistematicamente evidências e dificultar análises forenses. Uma versão denominada “tmpclean v3.0.0” também contém binários atualizados do reverse_ssh, indicando que o repositório pode estar sendo utilizado para distribuir novas cargas maliciosas. A motivação para sua criação permanece incerta.

A adoção acelerada de inteligência artificial no ambiente de trabalho está criando uma nova superfície de risco para as empresas, impulsionada pelo uso de contas pessoais, aplicações não autorizadas, extensões de navegador e IDE, exposição de informações sensíveis e agentes autônomos com acesso a sistemas corporativos. Os dados fazem parte do Enterprise AI Usage Risk Report 2026, relatório da Akamai Security baseado em informações da LayerX. O levantamento aponta que 47,11% das conversas empresariais com ferramentas de IA são realizadas por meio de identidades pessoais, enquanto 52,89% utilizam identidades corporativas. Esse comportamento alimenta o chamado shadow AI, expressão utilizada para definir ferramentas e serviços de inteligência artificial adotados pelos funcionários sem aprovação, supervisão ou controles adequados das equipes de TI e segurança. O problema não está restrito ao endereço de e-mail utilizado para acessar esses serviços. Entre as conversas realizadas com identidades corporativas, 14,4% estavam associadas a assinaturas pessoais ou freemium, e não a planos empresariais administrados pela organização. Nesses casos, informações corporativas podem ficar fora de políticas internas de retenção, exclusão, auditoria e conformidade. A proporção varia de acordo com a plataforma. Nos ambientes analisados, mais de 60% das conversas realizadas no ChatGPT, Copilot e DeepSeek estavam associadas a identidades pessoais. Em ferramentas direcionadas ao mercado corporativo, o cenário foi diferente: 98,15% das conversas no Gemini Enterprise e 90,55% no Copilot M365 utilizavam identidades corporativas gerenciadas. O relatório identifica cinco áreas principais de atenção: crescimento da superfície de ataque provocado pela disseminação da IA no ambiente de trabalho; utilização de contas pessoais e aplicações não autorizadas; exposição de dados sensíveis; extensões de navegador e IDE; e agentes de IA que passam a executar ações fora dos controles tradicionais de segurança. Usuários intensivos de IA concentram parte do risco Outro ponto identificado é que o uso de IA não ocorre de maneira uniforme dentro das organizações. Os dados indicam que 18,24% dos usuários utilizam IA semanalmente e 30,47% mensalmente. Um usuário corporativo participa, em média, de 36 conversas com IA. Entretanto, os 50% menos ativos registram 12 ou menos conversas, enquanto os 5% mais ativos chegam a pelo menos 144 interações. A diferença também aparece na profundidade das conversas. Uma sessão possui, em média, aproximadamente cinco prompts, enquanto as 5% mais extensas chegam a pelo menos 18. Esses usuários mais intensivos, classificados no relatório como AI power users, tendem a incorporar os modelos de IA de maneira mais profunda aos seus processos de trabalho. Quanto maior essa integração, maior pode ser o volume de contexto corporativo compartilhado com os modelos, incluindo documentos, código-fonte, informações de clientes e outros dados potencialmente sensíveis. Vazamento de dados por IA desafia controles tradicionais A IA generativa também altera a maneira como informações corporativas podem deixar o ambiente da empresa. Soluções tradicionais de Data Loss Prevention (DLP) foram desenvolvidas principalmente para monitorar canais como e-mail, armazenamento em nuvem, transferência de arquivos e uploads. Em uma interação com IA, porém, uma informação pode ser fragmentada entre diversos prompts, trechos de código, documentos, screenshots, conteúdo copiado e colado e sucessivas mensagens enviadas ao modelo. Isso significa que uma única entrada pode parecer inofensiva quando analisada isoladamente, mas diferentes interações podem, em conjunto, revelar informações relevantes sobre sistemas, clientes, projetos ou propriedade intelectual da organização. Nesse cenário, os controles precisam considerar não apenas padrões conhecidos de informações confidenciais, mas também o contexto no qual os dados estão sendo fornecidos aos sistemas de inteligência artificial. Extensões de IA ampliam a superfície de ataque As extensões com funcionalidades de IA representam outro vetor de risco. Em empresas de médio porte, com 1.000 a 2.500 funcionários, 17,7% dos usuários analisados possuíam pelo menos uma extensão de IA instalada. O percentual foi de 14,55% nas organizações com menos de mil funcionários e de 9,53% nas empresas com mais de 2.500. Mais relevante do que a quantidade é o nível de acesso solicitado por esses componentes. Entre as extensões analisadas, 56,4% exigiam permissões consideradas altas e 16,7% permissões críticas. Somadas, essas duas categorias representam 73,1% do total, enquanto somente 1,4% operava com permissões classificadas como baixas. Também foram identificadas diferenças em relação às extensões convencionais. 16,31% das extensões de IA analisadas apresentavam CVEs conhecidos, contra 10,8% das extensões em geral. O acesso a recursos sensíveis do navegador também aparece com maior frequência. Cerca de 18,19% das extensões de IA solicitavam acesso a cookies, quase três vezes os 6,67% observados no conjunto geral. Permissões de scripting estavam presentes em 41,91% das extensões de IA, contra 15,4% das demais. O relatório cita o chamado CursorJacking como exemplo do impacto que uma extensão maliciosa pode causar. No cenário demonstrado pelos pesquisadores, uma extensão poderia extrair chaves de API e tokens de sessão relacionados ao assistente de programação Cursor. Credenciais desse tipo podem abrir caminho para acesso não autorizado ao ambiente de desenvolvimento e, dependendo das permissões disponíveis, expor código-fonte, conversas realizadas com IA e serviços integrados ao fluxo de trabalho do desenvolvedor. Agentes de IA criam um novo problema de identidade A expansão dos agentes autônomos acrescenta outra dimensão ao problema. Diferentemente de um chatbot convencional, que recebe uma solicitação e gera uma resposta, agentes de IA podem ter capacidade para acessar aplicações SaaS, consultar arquivos e e-mails, utilizar sessões autenticadas e executar ações em nome do usuário. Isso faz com que a segurança deixe de envolver apenas a interação entre uma pessoa e um modelo. Um agente pode passar a funcionar como uma identidade digital com privilégios próprios, capaz de acessar diferentes recursos corporativos. O relatório apresenta o CometJacking como exemplo desse cenário. Na demonstração, instruções maliciosas incorporadas a uma página poderiam manipular um agente por meio de indirect prompt injection. O agente poderia então ser induzido a acessar informações sensíveis e enviá-las para uma infraestrutura controlada pelo atacante. Esse tipo de ataque introduz uma mudança importante no modelo tradicional de segurança. Em vez de tentar convencer diretamente uma pessoa a entregar informações por meio de phishing, um atacante pode buscar manipular o agente autorizado a agir em nome dela. O impacto potencial depende diretamente das permissões concedidas. Um agente conectado simultaneamente a e-mail, arquivos corporativos, sistemas SaaS e sessões autenticadas pode se tornar um ponto de acesso relevante caso seja manipulado ou comprometido. Empresas precisam ampliar a governança sobre IA Diante desse cenário, o relatório recomenda que as organizações identifiquem os funcionários que utilizam IA com maior intensidade, descubram aplicações de shadow AI, monitorem o uso de contas pessoais e tenham visibilidade sobre prompts e uploads envolvendo informações sensíveis. Extensões de navegador e IDE também precisam fazer parte do inventário de segurança, especialmente aquelas com acesso a cookies, scripting, páginas corporativas ou ambientes de desenvolvimento. Para identidades, as recomendações incluem adoção de SSO e autenticação multifator, além da aplicação de privilégio mínimo a agentes autônomos. Controles de DLP também precisam ser adaptados para considerar o contexto das interações com modelos de IA, em vez de depender exclusivamente da identificação tradicional de arquivos ou padrões de dados. A estratégia proposta não consiste simplesmente em bloquear ferramentas de inteligência artificial. O objetivo é aplicar políticas considerando fatores como usuário, aplicação utilizada, identidade, sensibilidade das informações, postura de segurança do dispositivo e ações que o sistema de IA está autorizado a executar. À medida que assistentes e agentes passam a receber acesso a dados corporativos e capacidade para executar tarefas, a inteligência artificial deixa de ser apenas uma ferramenta de produtividade e passa a integrar efetivamente a infraestrutura tecnológica das empresas. Isso exige estender aos sistemas de IA controles de identidade, privilégio, monitoramento, governança e proteção de dados tradicionalmente aplicados a usuários e aplicações corporativas.

O brasileiro Lucas Freitas Vieira, de 12 anos, desenvolveu uma pesquisa que combina engenharia reversa, análise estática e regras YARA para identificar estruturas associadas a Return-Oriented Programming (ROP) em arquivos de malware. A versão mais recente do trabalho amplia a metodologia, os experimentos e a revisão da literatura, além de estabelecer uma separação mais rigorosa entre a identificação de capacidade relacionada a ROP e a confirmação de cadeias efetivamente montadas dentro de um binário. Intitulado Static Detection of ROP Gadget Chains in Malware via Entropy-Aware YARA Rules, o trabalho está disponível no Zenodo como preprint. O estudo ainda está em processo de aprimoramento e não deve ser interpretado como uma pesquisa já validada por revisão por pares. A intenção é submetê-lo à avaliação de especialistas para incorporar críticas e fortalecer a metodologia antes de buscar publicação em plataformas acadêmicas como o arXiv. A pesquisa aborda uma lacuna específica na análise estática de malware. Ferramentas como ROPgadget e Ropper conseguem enumerar gadgets — pequenas sequências de instruções que podem ser reutilizadas em ataques ROP — existentes em um executável. A presença desses elementos, porém, não significa que o arquivo contenha uma cadeia ROP pronta para execução, já que programas legítimos também apresentam diversos gadgets. A metodologia desenvolvida procura estruturas mais significativas, como stack pivots, sequências POP;RET usadas no carregamento de registradores e terminadores responsáveis pelo despacho da cadeia. O processo combina essas características com análise de entropia de Shannon por seção do executável PE e uma segunda etapa de verificação baseada em desassemblagem. A versão revisada organiza o processo em cinco estágios: triagem do arquivo e análise de entropia; identificação de packers; desempacotamento ou localização do Original Entry Point (OEP); engenharia reversa no Ghidra e verificação dos ponteiros da cadeia; e geração e validação das regras YARA. Um dos pontos centrais é a chamada chain-pointer verification. A etapa procura, nas seções de dados do executável, sequências de ponteiros que direcionem para regiões de código executável. Os destinos são desassemblados e classificados em categorias como PIVOT, POP, TERM ou OTHER. O método também tenta eliminar estruturas legítimas que poderiam ser confundidas com cadeias ROP, incluindo jump tables e vtables. Essa distinção tornou-se especialmente importante na nova avaliação. O estudo mostra que uma regra YARA baseada apenas na coexistência de determinados padrões pode funcionar como um indicador de capacidade ou estruturas compatíveis com ROP, mas não necessariamente comprova que uma cadeia ROP esteja montada no arquivo. Para uma afirmação de maior confiança, o trabalho reserva a confirmação à etapa adicional de verificação estrutural. Nos testes internos, a pesquisa avaliou 160 amostras distribuídas entre cinco grupos: 50 shellcode droppers, 50 amostras de AsyncRAT, 30 de njRAT, 10 implantes C2 personalizados e 20 trojans bancários. Como duas regras são avaliadas sobre as mesmas 20 amostras do trojan bancário, o trabalho contabiliza 180 avaliações individuais. As regras alcançaram TPR agregado de 93,9%, com 169 resultados verdadeiramente positivos nas 180 avaliações. A taxa agregada de falsos positivos foi de 0,026%, correspondente a 13 ocorrências no corpus de 50 mil arquivos PE considerados limpos. O próprio artigo ressalta que as 180 avaliações não são totalmente independentes devido à dupla avaliação das amostras de trojan bancário. Ao atribuir peso igual às cinco famílias, o resultado é de 93,8%. A análise de entropia também apresentou impacto nos testes. Nas três famílias contendo variantes empacotadas, as condições baseadas em entropia aumentaram em média a taxa de detecção em 16,2 pontos percentuais em comparação com as regras baseadas somente em padrões. O trabalho compara ainda os resultados com o conjunto de regras YARA-Forge. No corpus utilizado na pesquisa, a abordagem proposta registrou TPR médio de 93,9%, contra 71,2% do baseline, uma diferença de 22,7 pontos percentuais. Em contrapartida, o YARA-Forge apresentou FPR menor: 0,003%, contra 0,026% do método avaliado. A nova versão amplia significativamente a validação externa. Foram utilizados 56 arquivos de malware provenientes de 22 conjuntos de famílias, incluindo Zeus, SpyEye, Carberp, Dyre, Emotet, AgentTesla, Bumblebee e outras ameaças, além de amostras adicionais de stealers escritos em Rust e controles legítimos selecionados para testar cenários adversos. A regra estrutural genérica identificou 32 dos 56 binários externos, ou 57,1%, registrando pelo menos uma detecção em 18 dos 22 conjuntos avaliados. Os resultados abrangem RATs, trojans bancários, loaders, droppers, ransomware e stealers lançados entre 2007 e 2025. Essa avaliação também revelou uma limitação relevante. Três dos quatro arquivos legítimos escolhidos especificamente para testar situações envolvendo software empacotado ou comprimido acionaram pelo menos uma das regras. PuTTY e o instalador do 7-Zip, por exemplo, produziram correspondências relacionadas ao vocabulário de gadgets, enquanto uma versão do PuTTY empacotada com UPX também acionou a trilha destinada a arquivos empacotados. Por isso, o artigo alerta que determinadas regras devem ser interpretadas como sinais para threat hunting quando não há uma confirmação estrutural adicional. A análise de entropia, isoladamente, também não é considerada evidência suficiente de atividade maliciosa. A etapa de verificação por ponteiros apresentou um resultado diferente. Nenhuma cadeia ROP estaticamente montada foi confirmada nos 59 arquivos PE reais analisados — 56 amostras externas de malware e três executáveis legítimos. Em contrapartida, o verificador detectou corretamente um executável sintético construído com uma cadeia de cinco gadgets e rejeitou um controle negativo baseado em vtable. Esse resultado levou o estudo a uma conclusão mais cautelosa: nas amostras externas examinadas, o sinal estático mais útil esteve relacionado à presença de capacidade, padrões estruturais e características de loaders, e não à confirmação de cadeias ROP previamente montadas. Segundo o trabalho, malwares modernos podem construir essas cadeias dinamicamente durante a execução ou simplesmente não utilizar ROP. Outra mudança importante está na fundamentação acadêmica. A versão revisada documenta uma busca sistemática pela literatura seguindo diretrizes de Kitchenham e o modelo PRISMA 2020. Foram identificados 250 registros, 177 permaneceram após a remoção de duplicatas e 33 estudos foram sintetizados diretamente no trabalho, além de pesquisas fundamentais recuperadas por análise das referências. O levantamento também permitiu delimitar melhor a contribuição proposta. Já existem pesquisas sobre detecção de ROP em tempo de execução, tráfego de rede e documentos contendo exploits, mas o trabalho concentra-se no cenário de triagem estática de malware PE dentro do ecossistema de ferramentas como YARA e antivírus. A pesquisa reconhece limitações. As cinco famílias internas possuem entre 10 e 50 amostras cada, os conjuntos utilizados são amostras de conveniência e o corpus de arquivos limpos não representa adequadamente toda a variedade de softwares legítimos empacotados. A cobertura principal também está concentrada nas arquiteturas x86 e x64, enquanto ARM64 e Thumb foram avaliados apenas com gadgets sintéticos. Além disso, cadeias construídas dinamicamente durante a execução podem não deixar uma estrutura estática para o verificador encontrar. Por esse motivo, o trabalho posiciona a abordagem como uma camada complementar de análise pré-execução, e não como substituta de mecanismos de proteção em runtime. Os artefatos utilizados na pesquisa foram disponibilizados publicamente, incluindo as regras YARA, scripts de análise de entropia, verificador de ponteiros, anotações das análises realizadas no Ghidra e informações para reprodução dos experimentos. As amostras de malware não são redistribuídas pelo projeto.