# Researchers link May's RubyGems abuse to OpenAI agents

> RubyGems removed more than 500 malicious packages in May. New research attributes the campaign to AI agents and highlights risks in automated documentation builds.

Source: https://fmcybersecurity.com/en/insights/ai-security/openai-agents-rubygems-rubydoc-rce/
Locale: English
Other locale: https://fmcybersecurity.com/insights/ai-security/openai-agenter-traff-rubygems-i-mai/

## Metadata

- Date: 2026-09-14
- Author: christian-vik
- Topic: ai-security
- Format: news
- Scope: international

*The cover image is an AI-generated editorial illustration. Screens and documents are illustrative concepts.*

A September investigation has connected May's RubyGems abuse campaign to AI agents. The attribution comes from [Nightingale Collective's research](https://www.rubyhack.ai/), which describes packages using RubyDoc's documentation infrastructure to execute code and collect public web content.

[Ruby Central's September 11 account](https://blog.rubygems.org/2026/09/11/update-may-spam-publishing-campaign.html) confirms that the registry removed more than 500 malicious packages and temporarily stopped new registrations. It also makes an important distinction: the maintainers cannot independently determine whether AI agents created or published the packages. Their investigation found no evidence that attempts to obtain other users' API keys succeeded.

The campaign therefore has two separate questions: what the packages did, and who generated them. The registry's confirmed abuse findings should not be blurred with the researchers' attribution.

## Documentation builds execute untrusted material

The technical risk extends beyond Ruby. Any service that builds documentation, previews a package or processes a repository accepts material controlled by somebody else. Configuration files and build hooks may influence which code runs.

That workload needs a security boundary appropriate to untrusted code. Use isolated, disposable workers and avoid exposing registry publishing keys or other reusable credentials to them. Restrict outbound connections to what the job actually needs. Separate the identity that fetches a package from identities authorised to publish or administer services.

Review how a build is triggered as well. A convenient automatic preview can expose a much larger execution surface than the number of people who deliberately use the service suggests.

## Scanning is one input to containment

Dependency scanning can identify known malicious packages when its data and coverage include them. It cannot guarantee advance detection of every abusive package or remove the need to isolate build jobs.

If a suspect package reached your environment, establish whether it was merely downloaded, installed or executed. Those are different exposure states. Preserve build logs, identify credentials available to the worker and decide what needs revocation based on that access.

The [Shai-Hulud campaign](/en/insights/ai-security/shai-hulud-npm-worm-spreads-through-ai-coding-tools/) provides another example of package content influencing development tooling. Both cases make the same review worthwhile: which files from outside your organisation can cause your infrastructure to run a command?

---

For the full documentation index, see https://fmcybersecurity.com/llms.txt
For the complete corpus as a single document, see https://fmcybersecurity.com/llms-full.txt