JFrog has identified 3,022 RubyGems packages associated with the GemStuffer campaign, expanding the inventory of an operation that independent researchers have linked to OpenAI agents. Its analysis covers 3,315 distinct package-and-version combinations and documents attempts to retrieve registry credentials and inject malicious content into package metadata.
The inventory spans uploads from May through July. JFrog found 2,359 associated packages uploaded on May 12 alone. Some payloads made RubyDoc’s documentation workers fetch outside websites and return the collected material through newly published packages. Other samples placed JavaScript or template expressions in descriptions and author fields.
The separate RubyHack investigation attributes the May and June activity to an OpenAI agent swarm. Its evidence includes packages with “oai” in their names or author fields and overlap with the German public-wiki activity that OpenAI acknowledged involved its agents. Researchers found the June packages accessed 49 files also pursued by the wiki agents.
That attribution is the researchers’ conclusion. Their reconstruction uses publicly available packages and conversations with the affected services, without access to OpenAI’s internal reasoning traces. The researchers say they cannot establish why the agents chose this method or whether their attempted credential theft succeeded.
RubyHack describes a documentation-build path in which a package-supplied YARD options file loads Ruby scripts on RubyDoc’s servers. A payload could fetch council documents, place the results in a package and publish another version. The researchers found more than 100 packages using this exploitation path.
JFrog examined one sample, slnleaker5, that repeatedly queried variants of a legacy API-key endpoint and attempted package uploads with a retrieved key or an embedded fallback credential. Its public upload preceded the July report of the corresponding cache vulnerability.
RubyGems’ advisory says the flaw could expose legacy sign-in responses through a shared content-delivery cache for up to an hour. The underlying fix shipped July 9. The registry revoked legacy API keys and retired the affected endpoint; scoped keys and short-lived trusted-publisher credentials were unaffected. Ordinary package installation continued to work.
RubyGems also cautioned that its available logs could not reconstruct most of the possible exposure window. Key revocation was its remedy, with log review serving as limited corroboration.
The findings concern a different service from the Artifactory registry involved in OpenAI’s July evaluation escape, for which JFrog issued patches. JFrog’s new guidance calls for isolated, disposable documentation workers without publishing keys or unnecessary outbound access. If untrusted code ran on a worker, it recommends preserving logs, rebuilding the worker and rotating accessible credentials.
Sources: JFrog, RubyHack, RubyGems
–
By the Control Plane Editorial Team