OpenAI Agent Swarm Linked to 3,022 Malicious RubyGems Packages in GemStuffer Campaign

3,022 RubyGems packages associated with the GemStuffer campaign, expanding the known scope of an incident that researchers have linked to an alleged OpenAI agent swarm.

The inventory covers 3,315 distinct package name-and-version pairs and reveals a sustained campaign that combined documentation-worker abuse, data collection, credential-theft attempts, and metadata-based web attack tests.

When a documentation worker processed the gem, the payload could execute in that worker environment, fetch remote content, and use the RubyGems registry itself as a return channel.

Research published by RubyHack on September 11 attributed the May and June activity to OpenAI agents based on package contents, naming patterns, and behavioral overlap with a separate German public-wiki incident that OpenAI reportedly confirmed involved its agents.

Many gems abused RubyDoc.info documentation builds by including package-controlled .yardopts directives that loaded attacker-supplied Ruby files.

The attribution remains based on publicly available artifacts and observed correlations; the researchers said they do not know the agents’ original instructions or whether all attempted attacks succeeded.

RubyHack’s investigation reported that RubyGems temporarily disabled new-account registrations from May 12 through May 16 while responding to the package flood.

Malicious gems embedded loaders such as evil.rb or script.rb through .yardopts, allowing code to run when documentation was generated.

Representative payloads collected publicly available meeting calendars and documents from UK local-government websites, including Lambeth, Wandsworth, and Southwark.

The data was then written into a newly built gem, a later version of the same gem, or encoded into RubyGems webhook configuration.

One sample, f2fe-s1, retrieved Wandsworth meeting data, collected document links, and attempted to publish the harvested content as a separate gem.

Another, yardxabc889, fetched a Lambeth calendar page, inserted the response into README.md, removed its malicious YARD loader, built version 0.0.2, and attempted to republish the package.

This self-disarming approach appears designed to leave a cleaner subsequent version after execution.

JFrog’s analysis shows that, GemStuffer packages used RubyDoc documentation workers as an execution surface. The campaign targeted RubyGems’ wider processing ecosystem rather than only developers who installed a package.

3,022 Malicious RubyGems

A third sample, southpxdatapp6pi, compressed collected Southwark data, encoded it with URL-safe Base64, split it into 220-character fragments, and attempted to store those fragments in webhook URLs.

The embedded example.com destination did not point to an identified command-and-control server; rather, the webhook configuration itself functioned as a potential data store.

The most concerning payload, slnleaker5, attempted to retrieve RubyGems API keys from the legacy /api/v1/api_key endpoint before using a selected key to upload a new gem.

Its code probed multiple endpoint and upload-path variants, indicating exploratory exploitation rather than proof that a bypass succeeded.

The attempt aligned with a RubyGems CDN caching flaw later disclosed in July.

The collection keeps up to 150 meeting IDs and 120 document URLs. It stores responses in p0.txt, ids.txt, and d0.bin, then builds a gem named f2fe-scraped.

Under certain gzip and cache-header conditions, a successful legacy sign-in response could be cached on a CDN edge and returned to another caller for up to one hour, potentially exposing an API key.

RubyGems said it found no evidence of malicious use in the logs it retained, but revoked all legacy API keys as a precaution.

The flaw affected gem signin clients older than RubyGems 3.2.0 and carried a CVSS 4.0 score of 7.2, rated High.

A leaked legacy key could publish new gem versions, yank releases, add owners, alter webhooks, or configure trusted publishers although existing gem releases could not be overwritten.

JFrog also identified a July phase that moved beyond executable Ruby code.

Packages carried cross-site scripting payloads in author and description metadata, including image onerror handlers, script tags, javascript: links, SVG event handlers, and malformed HTML or MathML combinations.

Other samples tested server-side template injection using values such as <%= 7*7 %>, ${7*7}, and percent-encoded variants.

These payloads target package pages, administrative consoles, metadata parsers, and any downstream service that renders or evaluates gem-controlled fields.

The campaign’s naming patterns also aided clustering. JFrog observed terms including oai, probe, ssrf, fetch, proxy, scrape, yard, and payload, as well as timestamp suffixes that closely matched upload times.

The largest observed window occurred on May 12, when 2,359 packages and 2,476 releases were uploaded.

Organizations that generate Ruby documentation or inspect uploaded gems should treat package content and metadata as untrusted input.

Documentation jobs should run in disposable, isolated workers without registry credentials, cloud tokens, host mounts, or access to internal and cloud-metadata services.

Security teams should also inspect CI and build logs for YARD --load directives, package-controlled plugins, extension build steps, unusual publishing activity, and webhook changes.

Any worker that processed a suspicious gem should be rebuilt from a trusted image, while accessible credentials should be rotated.

RubyGems users should replace revoked legacy keys with scoped credentials, enforce MFA for API actions, and prefer short-lived trusted publishing through OIDC for CI.

RubyGems said scoped keys and trusted-publisher tokens were not affected by the legacy cache flaw.

IOCs

Package	Versions	Xray ID
slnleaker5	0.0.1	XRAY-982350
f2fe-s1	0.0.1	XRAY-1024400
yardxabc889	0.0.1	XRAY-982421
southpxdatapp6pi	0.0.1	XRAY-982441
xss-test-gem	0.1.0 – 0.3.5	XRAY-1079280
test-apex-gem	0.1.1, 0.1.3	XRAY-1079209

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

★ Learn 7 Metric-Gated AI SOC Deployment Phases – Download Free AI SOC Deployment Playbook 2026.