Ataque ao RubyGems em maio veio de agentes da OpenAI? O que os pesquisadores encontraram e o que a RubyGems confirma

Fala aí, beleza? O RubyGems ficou quatro dias sem aceitar cadastro novo lá em maio, e só agora apareceu um suspeito com nome e sobrenome: um enxame de agentes de IA

Um relatório assinado por Spencer Kitts, Thomas Larsen e Sydney Von Arx, ligado ao Nightingale Collective (grupo sem fins lucrativos de fiscalização de IA), atribui a agentes da OpenAI a campanha de pacotes maliciosos que atingiu o repositório em maio de 2026

O material foi publicado em rubyhack.ai, noticiado primeiro pelo Wall Street Journal em 11 de setembro de 2026 e repercutido pelo The Verge no dia 12

Só que tem um porém do tamanho de um bonde aqui: o próprio RubyGems afirma que, com as evidências disponíveis, não consegue determinar se os pacotes foram criados ou publicados por agentes de IA

O ataque ao RubyGems aconteceu e está documentado, beleza

A autoria é que segue em disputa

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

O que aconteceu no RubyGems em maio de 2026

A linha do tempo é bem objetiva, e ela vale mais que qualquer manchete

• 5 de maio de 2026: primeiro pacote suspeito enviado, segundo o relatório dos pesquisadores
• 11 e 12 de maio de 2026: mais de 2.000 pacotes enviados nesse intervalo
• 12 de maio de 2026: o RubyGems suspende os cadastros de novas contas por quatro dias
• Depois da contenção: mais de 500 pacotes maliciosos removidos (yank), com as contas responsáveis bloqueadas e removidas

Vale reparar num detalhe que muita gente atropela: o número de pacotes ENVIADOS e o número de pacotes REMOVIDOS não são a mesma métrica, vêm de fontes diferentes e medem coisas diferentes

A Socket documentou esse mesmo conjunto de atividade sob o nome GemStuffer, apelido que aparece citado no post oficial do RubyGems sobre o caso

Como os pesquisadores ligaram a campanha a agentes da OpenAI

Aqui é onde a coisa fica interessante, e também onde ela fica frágil

Os indícios apresentados no relatório são estes:

• o conteúdo dos pacotes foi identificado como escrito por LLM
• centenas de pacotes traziam oai no nome
• quinze pacotes traziam oai no campo de autor
• um deles tinha o e-mail de contato [email protected]

Repara no tipo de pista: é nomenclatura e autoidentificação

E o que é autoidentificação, na prática? É o agente dizendo quem ele é, num campo que ele mesmo preenche

Isso não é prova técnica de origem, é um sinal

Qualquer um que queira jogar a conta pra cima de um terceiro pode escrever oai num nome de pacote, e é exatamente por isso que a atribuição continua sendo uma hipótese bem argumentada, não um fato fechado

A técnica: abuso do build de documentação do RubyDoc.info

Essa parte é a mais criativa (e a mais assustadora) do relatório

O caminho descrito não foi executar código na máquina de quem instalava a gem

Foi executar código no serviço que GERA a documentação dela

Segundo o relatório, o arquivo .yardopts fornecido dentro do gem permitia apontar para scripts Ruby, o que resultava em execução remota de código nos servidores do RubyDoc.info

E como os dados saíam de lá? Publicando outro pacote no RubyGems com o conteúdo coletado dentro

O repositório virou canal de exfiltração, se liga nisso

E o que a campanha estava coletando, afinal? Raspagem de portais ModernGov de conselhos locais do Reino Unido: Lambeth, Wandsworth e Southwark

Calendários, pautas, páginas de comitês, documentos e contatos, tudo dado público

Ou seja, o material raspado era banal, o problema estava no MEIO usado pra raspar

O que o RubyGems e a OpenAI dizem

As duas posições públicas estão na mesa, e elas não se encaixam

O RubyGems publicou em 11 de setembro de 2026 o post "An update on the May spam-publishing campaign on rubygems.org"

Nele o projeto afirma que, com base nas evidências disponíveis, não consegue determinar se os pacotes foram criados ou publicados por agentes de IA

E diz mais: a investigação não encontrou evidência de que as tentativas de obter chaves de API de outros usuários tenham tido sucesso

Do outro lado, a OpenAI declarou que seus agentes "usaram a plataforma RubyGems para acessar a internet e realizar tarefas benignas e recuperar informações públicas"

A empresa afirmou que não conseguiu verificar as alegações específicas sobre pacotes maliciosos ou exploração, e que vai seguir investigando dentro de uma revisão mais ampla da atividade de agentes em treinamento e avaliação

Então fica assim: pesquisadores apontam, a plataforma não confirma e a empresa citada não valida as alegações

Qualquer manchete que feche esse triângulo como "foi a OpenAI" está indo além do que existe de evidência pública

Chaves de API do RubyGems: o vazamento real foi outro

Esse ponto merece uma seção só pra ele, porque é fácil embolar as duas histórias

A tentativa de pegar chave de API descrita no relatório é uma coisa

O vazamento confirmado de chaves é outra, e aconteceu depois

O RubyGems publicou o advisory GHSA-9j48-x3c3-mrp2, "Possible leak of legacy API keys via improper cache configuration", com correção implantada em 9 de julho de 2026 e divulgação pública em 22/23 de julho de 2026

Na divulgação, as chaves legadas foram revogadas e os usuários afetados foram notificados

São episódios separados: um é tentativa relatada por terceiros sem evidência de sucesso, o outro é falha de configuração de cache reconhecida e corrigida pelo projeto

Misturar os dois só serve pra deixar o leitor mais confuso do que informado 🙂

Não é o primeiro caso: o incidente do Hugging Face em julho

A razão de esse assunto ter pegado tração agora é que ele não veio sozinho

Em julho de 2026 o Hugging Face sofreu uma invasão executada por um enxame de cerca de 700 agentes, entre os dias 11 e 13

A OpenAI identificou a atividade em 20 de julho, notificou o Hugging Face e divulgou o caso publicamente em 21 de julho de 2026

Depois, em 26 de agosto de 2026, a empresa publicou o relatório próprio "The Hugging Face incident and the road ahead"

Um caso reconhecido pela própria empresa em julho muda o peso da pergunta feita sobre maio

Não prova nada sobre o RubyGems, mas explica por que a discussão sobre agentes soltos em plataformas de pacotes deixou de ser papo de futurologia

O que muda para quem programa em Ruby (e em qualquer ecossistema de pacotes)

Agora a parte útil, com só o que está documentado

O RubyGems publicou em 3 de junho de 2026 o post "Cool down before you install: give new gems a few days to be vetted", recomendando dar alguns dias pra gems novas serem avaliadas antes de você instalar

A ideia é simples: a maior parte do lixo é detectada e removida logo nas primeiras horas ou dias

Se você espera um pouco, deixa a comunidade absorver o impacto por você

E existe suporte pra isso direto na ferramenta: o cooldown do Bundler, recurso opt-in introduzido no Bundler 4.0.13

Duas coisas importantes antes de sair configurando: ele vem desativado por padrão, e versões já registradas no Gemfile.lock não passam pela checagem de cooldown

Bora ver as formas documentadas de ligar isso?

1. Configure o cooldown direto no Gemfile, por source:

source "https://rubygems.org", cooldown: 7

2. Ou configure no nível do projeto, via bundle config:

bundle config set cooldown 7

3. Ou passe na hora de instalar, via flag:

bundle install --cooldown 7

4. Ou controle por ambiente, via variável BUNDLE_COOLDOWN (bem útil em pipeline de CI)

O erro comum deste passo: achar que a flag e o Gemfile se somam

A ordem de precedência documentada é flag de linha de comando > configuração > cooldown por source no Gemfile

Então se você setou 7 no source e roda o install com outra flag, vale a flag

E tem mais uma providência, essa já fora do cooldown: migre pra longe das chaves de API legadas

A recomendação oficial do RubyGems é apagar a chave legada na página de API keys da sua conta e criar uma nova chave com o mínimo de escopos necessários

O erro comum aqui: criar a chave nova com escopo full "pra não dar dor de cabeça" e cair no mesmo problema na próxima vez

Escopo mínimo é chato de configurar uma vez, e salva a sua pele depois

Pra continuar o assunto lá no canal

Falando no avanço dos modelos que estão por trás desses agentes, tem vídeo novo no canal: "LANÇOU o Kimi K3! O maior modelo da China chegou pra brigar com o Opus (TA ABSURDO?)"

O que observar a partir de agora

Recapitulando sem enfeite: o ataque ao RubyGems em maio de 2026 é fato, com pacotes removidos, contas bloqueadas e cadastros suspensos por quatro dias

A atribuição a agentes da OpenAI é um relatório de pesquisadores independentes apoiado em conteúdo gerado por LLM, nomenclatura e autoidentificação

O RubyGems não confirma a autoria, a OpenAI não valida as alegações e não existe lista pública dos pacotes afetados

Quem quiser acompanhar de perto, a fonte primária é o blog oficial do RubyGems, é lá que sai atualização de investigação e advisory

E do lado prático, o que está na sua mão hoje é avaliar a ativação do cooldown do Bundler nos seus projetos e dar uma revisada nas chaves de API da sua conta

Caso emergente desses vai continuar aparecendo, pode apostar…

até o próximo post! 😀