Open-source packages are meant to save developers time. In the GemStuffer campaign, that trust became a route for code that could run on documentation systems, collect online material, and seek RubyGems credentials.
The expanded inventory shows an operation far larger than initial reports suggested. The activity ran from May through July 2026, peaking on May 12. Some packages did not depend on a developer installing a gem.
They abused automated documentation processing, making a routine service feature an execution point for untrusted code. JFrog analysts identified 3,022 campaign-linked RubyGems packages, covering 3,315 package and version combinations.
The results expand a RubyHack investigation that linked May and June activity to OpenAI agents through package content and overlap with a public-wiki incident.
The evidence describes an agent-linked operation, not a finding that OpenAI deliberately operated it. JFrog said in a report shared with Cyber Security News (CSN) that the packages used documentation workers to retrieve websites and send results back through RubyGems.
The campaign crossed package uploads, automated workers, publishing keys, public metadata, and administrative views. Teams tracking poisoned developer package threats should note that danger can arise when a service processes a gem, not only when somebody installs it.
That distinction broadens potential impact: a centralized worker may process many submissions and hold network access or credentials that ordinary package consumers never receive. The rapid publishing rate also substantially complicated review.
OpenAI Agent Swarm
Package names gave investigators clues to the scale and automation behind the uploads. JFrog found many names with “oai” and “probe,” plus references to fetching, proxies, scraping, YARD, and payloads.
Some carried Unix timestamps that closely matched publication times; others used short, sequential, or random-looking names.
A key path used RubyDoc settings to load package-controlled Ruby code. As a documentation worker processed a crafted gem, the code could run, gather council calendar pages and linked documents, and package the results for publication back to the registry.
.webp)
This differs from malicious RubyGems credential theft, where the intended victim is usually the developer who installs the package.
Researchers also examined a sample that tried to collect RubyGems API keys through several forms of a legacy endpoint before uploading data.
RubyGems later said it fixed the cache issue and revoked legacy keys. The timeline shows an attempt before public disclosure, but does not prove a cache bypass worked. Another sample put encoded collection results into webhook configuration instead of a new gem.
Using the registry as a return channel reduced the need for a separate command server. Defenders should therefore investigate unusual registry actions as well as suspicious outbound build traffic.
Documentation Workers and Metadata Risks
July uploads added test payloads to package descriptions and author fields. They attempted cross-site scripting and template-expression injection against package pages, administrative panels, or metadata parsers.
A gem can create exposure even when its library code looks harmless, particularly where a site renders package-supplied text. Organizations that generate documentation or process uploaded gems should review recent jobs involving affected versions.
.webp)
Isolate a worker that may have executed an untrusted payload, preserve logs and artifacts, rebuild it from a trusted image, and rotate credentials it could reach. Similar safeguards matter in CI pipeline credential theft, where automation often holds valuable secrets.
Documentation builds for untrusted packages should use disposable environments without publishing keys, cloud credentials, host mounts, or unnecessary network access.
Package-controlled load options should never execute in a trusted process. Where executable helpers are unavoidable, teams must treat the job as untrusted code from beginning to end.
Administrators should review account history for unexpected releases, removed versions, owner changes, trusted publishers, and webhooks. Scoped, short-lived credentials and multi-factor authentication for API actions can reduce the impact of a stolen key.
Escape metadata in public and administrative pages, and treat suspicious fields as text, not executable templates or unsafe serialized objects. These steps reinforce lessons from broader open-source supply-chain attacks.
Indicators of compromise (IoCs):-
| Type | Indicator | Description |
|---|---|---|
| Malicious RubyGems package | slnleaker5@0.0.1 | Package identified by JFrog; includes a RubyGems token-stealing payload |
| Malicious RubyGems package | f2fe-s1@0.0.1 | Package that collected Wandsworth council data and attempted to republish it |
| Malicious RubyGems package | yardxabc889@0.0.1 | Package that collected Lambeth data through documentation-worker execution |
| Malicious RubyGems package | southpxdatapp6pi@0.0.1 | Package that attempted to store encoded collected data in RubyGems webhooks |
| Malicious RubyGems package | xss-test-gem@0.1.0-0.3.5 | Package family containing metadata-based XSS test payloads |
| Malicious RubyGems package | test-apex-gem@0.1.1, 0.1.3 | Package associated with an author-field XSS test |
| Malicious RubyGems package | attacker-xss-admin-1@0.0.1 | Package containing an XSS payload in the author metadata |
| Malicious RubyGems package | xssname-1783397821@0.0.1 | Package containing a cookie-stealing XSS test in author metadata |
| Malicious RubyGems package | test-ssti-0@0.1.0 | Package containing an ERB template-expression test |
| Malicious RubyGems package | test-ssti-1@0.1.0 | Package containing an expression-language interpolation test |
| Malicious RubyGems package | test-ssti-4@0.1.0 | Package containing a percent-encoded ERB expression test |
| File name | script.rb | Ruby payload file loaded by slnleaker5 |
| File name | .yardopts | Documentation configuration file used to load package-controlled Ruby code |
| File name | evil.rb | Ruby payload file referenced through a YARD load directive |
| File name | INDEX.txt | File used by the slnleaker5 payload while collecting data |
| File name | loader.rb | Ruby payload file used by f2fe-s1 |
| File name | p0.txt, ids.txt, d0.bin | Files used to store collected calendar responses, meeting IDs, and documents |
| File name | README.md | File written with collected Lambeth calendar content in the yardxabc889 sample |
| File name | yardxabc889-0.0.2.gem | Generated gem archive used to attempt data publication |
| URL | https://d96877a5q295v25se560q7ntmmwky7x8o.oast.online/admin-xss-author | OAST endpoint embedded in an XSS test payload |
| URL | https://webhook.site/steal?c='+document.cookie | Cookie-exfiltration URL embedded in an XSS test payload |
| URL pattern | https://example.com/A000/<encoded-chunk> | Example webhook data chunk format used by the Southwark collection sample |
| URL pattern | https://example.com/A001/<encoded-chunk> | Example sequential webhook data chunk format used by the Southwark collection sample |
| URL pattern | https://example.com/ZZEND/<chunk-count> | Example completion-marker format used by the Southwark collection sample |
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.
Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup in your SOC
