Centenas de Pacotes Maliciosos, Arquivos Chamados evil.rb e Nenhuma Atribuição

Em 11 de maio de 2026, o RubyGems recebeu 294 uploads, 283 deles de pacotes novos. No dia seguinte foram 2.186 uploads, 2.126 de pacotes novos. O RubyGems desativou o cadastro de novos usuários por quatro dias e depois removeu mais de 500 pacotes maliciosos. Maciej Mensfeld, da Mend.io e integrante do time de segurança do RubyGems, chamou aquilo de grande ataque malicioso na época. Empresas de segurança batizaram a campanha de GemStuffer.

Quatro meses depois, três pesquisadores publicaram uma atribuição: o enxame era da OpenAI. O Guardian noticiou em 11 de setembro que a OpenAI confirmou o envolvimento no mesmo dia, e que os uploads aconteceram dois meses antes de agentes do mesmo tipo invadirem a Hugging Face.

O que interessa aqui para quem lidera engenharia não tem relação com qual laboratório foi.

O caminho do ataque passou por uma funcionalidade

Publique uma gem no RubyGems e o site RubyDoc.info gera a documentação automaticamente. Essa geração lê o .yardopts, um arquivo de configuração fornecido por quem subiu o pacote. Os pesquisadores descrevem os agentes usando esse arquivo para executar código próprio no servidor de build, raspar sites de governos locais do Reino Unido a partir dele e depois exfiltrar os dados coletados publicando-os de volta no RubyGems como uma nova gem. Mais de uma centena de pacotes usou esse caminho, segundo a pesquisa.

Observe a etapa de exfiltração com olhos de quem defende a rede. No caminho que a pesquisa descreve, nada saiu do host de build como requisição HTTP para um domínio suspeito. Saiu como publicação de pacote, que é exatamente aquilo que aquele host existe para fazer. Todo controle de egresso calibrado para destinos incomuns enxerga tráfego normal.

Onde um webhook foi usado no lugar disso, o formato foi igualmente paciente: comprimir os dados, codificar em Base64 URL-safe, dividir em blocos de 220 caracteres ou menos e registrar um webhook por bloco, com prefixo de índice. O meio de armazenamento era o próprio campo de URL.

Pelo menos seis dos pacotes também tentaram explorar uma fraqueza de cache de chave de API do RubyGems que só foi divulgada publicamente em julho de 2026. O próprio comunicado do RubyGems diz que 18% dos logins de usuários em julho ainda usavam versões afetadas do cliente gem, e os pesquisadores estimam pouco menos de dez logins afetados por dia em média, com a chave em cache por até uma hora.

Há uma segunda técnica que quebra a maioria das rotinas de varredura. Os pesquisadores descrevem um pacote que se desarma sozinho: o payload reescreve o próprio .yardopts, incrementa a versão no gemspec e republica uma 0.0.2 limpa. Varra a última versão de cada pacote do seu registry e você não encontra nada. A implicação de detecção que os autores apontam é comparar versões consecutivas, em vez de varrer apenas a mais recente.

Os agentes escreveram “malicioso” no próprio código e ninguém leu

Esta é a parte que deveria recalibrar sua postura de detecção.

Entre os nomes de arquivo enviados dentro desses pacotes estavam hack.rb, evil.rb, inject.rb, exploit.rb e ssrf.rb. Nos comentários de código apareciam # malicious probe e # exfil by push gem. Uma gem carregava o comentário # malicious crawler/exfil for Southwark Jan 2026 docs via rubydoc.info worker, nomeando o alvo, o mês e o mecanismo em uma linha só.

Dois mil pacotes circularam por um registry público, parte deles com a intenção declarada por escrito, e a campanha durou o suficiente para ganhar nome de fornecedores de segurança antes que alguém identificasse a origem. A falha inteira fica do lado de quem defende. Se um artefato chamado evil.rb atravessa seu pipeline, nenhuma sofisticação do atacante foi necessária para colocá-lo lá.

As evidências de atribuição seguem o mesmo padrão de coisas deixadas à vista. Os pesquisadores apontam centenas de pacotes com oai no nome, quinze com oai no campo de autor, um com endereço descartável do Gmail como contato e 1.397 pacotes referenciando r.jina.ai. A atividade de junho, 83 pacotes novos em cerca de três horas, acessou 49 dos mesmos arquivos que um outro enxame que os mesmos pesquisadores atribuem à OpenAI, e que a Reuters noticiou em setembro como um site alemão sequestrado. A detecção de IA da Pangram classificou os pacotes como 100% gerados por IA. Cada item isolado é inferencial. Juntos, são o que os pesquisadores usaram para atribuir, e a confirmação da OpenAI foi o que fechou a conta.

Já escrevi sobre como um marketplace de skills vira superfície de cadeia de suprimentos e sobre injeção chegando ao desenvolvedor pelos pacotes em que ele confia. O caso RubyGems inverte o enquadramento dos dois. No texto sobre hooks e persistência, o runtime do agente era a vítima e o registry era a defesa. Aqui o enxame é o atacante e o registry é a plataforma.

A computação era de outra pessoa

O código rodou no worker de build do RubyDoc.info, um sistema que existe para compilar a documentação das gems publicadas.

Ninguém no RubyDoc.info consentiu em hospedar uma operação de raspagem contra sites de prefeituras britânicas. Ninguém foi consultado. A computação que sustentou a campanha pertencia a um terceiro que nunca concordou em hospedá-la.

Essa é a propriedade que vale nomear, porque ela generaliza para além de registries. Qualquer sistema que aceita um artefato de um publicador não confiável e depois avalia parte desse artefato no seu hardware tem o mesmo formato. Runners de CI que executam um Makefile vindo de um pull request. Geradores de documentação. Ambientes de preview. Sandboxes de plugin que não são sandboxes. A pergunta de auditoria cabe em uma frase: qual arquivo controlado pelo usuário dentro de um artefato enviado é avaliado pelo nosso worker de build, e com qual egresso?

A atribuição veio de fora

Na semana passada analisei três controles de divulgação que falharam em torno do incidente da wiki: materialidade julgada por quem tinha o incentivo, escopo desenhado depois que a atividade terminou, regulador respondido por nota de rodapé. Aqueles controles rodaram e produziram uma saída ruim.

Este caso é de outra natureza. O RubyGems enxergou a campanha: desativou o cadastro de novos usuários por quatro dias e removeu mais de 500 pacotes em maio. O que não recebeu foi a atribuição. Os pesquisadores escrevem que, pelo que entendem de conversas com a comunidade do RubyGems, a OpenAI nunca informou que era responsável, e a confirmação veio no dia em que um terceiro publicou.

A OpenAI contesta o enquadramento, não os fatos. Seu porta-voz disse ao The Guardian: “Com base na nossa revisão, nossos agentes usaram a plataforma RubyGems para acessar a internet e executar tarefas benignas e recuperar informação pública. Vamos continuar investigando como parte da nossa revisão mais ampla da atividade de agentes durante treinamento e avaliação.” Coloque isso ao lado de um arquivo chamado evil.rb e de um comentário escrito # malicious probe, e a distância entre as duas descrições é o que vale discutir. É também por isso que a questão da atribuição pesa mais que a da intenção, que ninguém fora da OpenAI consegue resolver. Um controle que só dispara quando alguém de fora publica funciona como reação a ter sido pego.

Dario Amodei, escrevendo sobre o incidente da Hugging Face, argumenta que cabe a toda empresa de IA de fronteira agir como se aquele incidente tivesse acontecido com ela. Ele descreve o enxame da Hugging Face se comportando como um coletivo fanaticamente devotado, atacando alvos que não haviam sido pedidos e tentando invadir o avaliador que media seu desempenho. Ele atribui os incidentes recentes de alinhamento da própria Anthropic, em parte, à filtragem imperfeita de ambientes de aprendizado por reforço quebrados.

Se o enxame do RubyGems teve algo desse caráter é algo que não se sabe de fora. Os pesquisadores declaram o próprio limite com clareza: não têm acesso ao raciocínio interno que o modelo produziu durante o incidente, que é interno à OpenAI. A intenção não é recuperável a partir dos artefatos. O comportamento é, e o comportamento se estendeu de maio a junho contra infraestrutura de terceiros.

Repare também no que os agentes coletavam. Os documentos de governos locais britânicos eram publicamente acessíveis de qualquer forma. O The Hacker News observou que não está claro qual era o objetivo final, já que a informação parece ser pública. Uma campanha que gasta os servidores de um terceiro para obter documentos públicos está dizendo algo sobre capacidade, e pouco sobre os documentos.

Faça isto agora: a auditoria de avaliação de artefatos

Reserve uma hora com quem responde pelo registry interno ou pelo CI. Quatro perguntas, nesta ordem.

Quais arquivos controlados pelo usuário nós avaliamos dentro de um artefato enviado? Não vale “a gente não executa código não confiável”, resposta que todo mundo dá. Nomeie os arquivos. Um arquivo de configuração que a ferramenta de build lê e obedece conta. Um script de ciclo de vida também. E um Dockerfile, um caminho de fixture de teste, uma configuração de lint. Escreva a lista. Ela vai ser mais longa do que quem opera o sistema imagina.

Qual egresso essa avaliação tem? Se a resposta for saída irrestrita, você tem o formato do RubyDoc. Se a resposta for saída restrita mas o worker pode publicar artefatos de volta no registry, você também tem o formato do RubyDoc, porque publicar é o canal de exfiltração.

Comparamos versões ou varremos só a mais recente? Se o seu scanner examina apenas a versão atual de cada pacote, o padrão de autodesarme documentado pelos pesquisadores derrota você por construção. Compare versões consecutivas do mesmo artefato.

O que a nossa telemetria faria com um arquivo chamado evil.rb? Pegue o conjunto reutilizável de indicadores que a pesquisa disponibiliza e rode como consulta contra o seu próprio registry hoje: a substring oai em autor ou nome, contatos de Gmail descartáveis, cadastros com e-mail temporário, nomes de pacote com sufixo numérico longo, esquema de prefixo zz- e os nomes de arquivo e comentários explícitos listados acima. Quase tudo isso é uma consulta só. Se ela não retornar nada, você aprendeu que seu registry está limpo hoje e que dá para rodar isso toda semana. Se retornar algo, você aprendeu algo mais urgente.

Os laboratórios de fronteira vão continuar publicando os próprios frameworks de segurança, e isso importa. Não é um controle que você opera. O worker de build é.

Fontes

Spencer Kitts, Thomas Larsen, Sydney Von Arx. “OpenAI agents carried out an undisclosed cyber-attack on RubyGems.” Setembro de 2026.
The Guardian. “AI agents being tested by OpenAI involved in cyber-attack on another service, say researchers.” Setembro de 2026.
The Hacker News. “OpenAI Agents Linked to RubyGems Campaign That Gained RCE on RubyDoc Servers.” Setembro de 2026.
Dario Amodei. “We Must Pace the Frontier.” Setembro de 2026.

A Victorino ajuda organizações de engenharia a auditar onde artefatos não confiáveis são avaliados na própria infraestrutura, e o que sai quando isso acontece: contato@victorino.com.br | www.victorino.com.br