GemStuffer turns RubyGems into a covert exfiltration channel

At a glance

What this is: GemStuffer is a RubyGems registry-abuse campaign that used package artifacts and hardcoded API keys to turn the registry into a covert exfiltration channel.

Why it matters: It matters because IAM, secrets, and software supply chain teams need to govern publishing rights, API token scope, and registry egress, not just package installation.

👉 Read Corgea's analysis of the GemStuffer RubyGems registry-abuse campaign

Context

RubyGems package publishing is an identity and trust problem as much as a supply chain problem. If a process can authenticate to a registry, write packages, and reuse those publishing rights outside approved release workflows, the registry becomes a channel for exfiltration as well as distribution. GemStuffer shows how registry abuse can hide inside normal developer and CI traffic while still carrying controlled data out of an environment.

The article’s core finding is not that a dependency was malicious in the usual sense, but that attacker code treated RubyGems as storage, transport, and retrieval infrastructure. That makes publishing rights, API key handling, and egress controls part of the security boundary. For identity teams, the lesson is that registry access is a privileged capability that needs lifecycle governance, not a convenience permission.

This pattern is consistent with broader NHI and secrets-management failures: a credential exists, a process can use it, and the publishing path is not sufficiently constrained. That combination is common in build systems and rare in tightly governed release pipelines.

Key questions

Q: What breaks when package publishing is not separated from build and runtime identities?

A: When publishing is not separated from build and runtime identities, any process that reaches the registry can turn into an exfiltration path. Attackers can package collected data inside valid archives, publish them with a reusable token, and retrieve them later. The control failure is not the package format, but the absence of lifecycle-scoped publishing privilege.

Q: Why do AI provider keys need the same governance as other NHI secrets?

A: Because they authenticate automated access to external services, often with spend authority and operational reach. If a plugin or build tool steals the key, the attacker inherits that identity until the key is revoked. Treating it as a managed NHI keeps rotation, ownership, and revocation in scope.

Q: What do security teams get wrong about package registry monitoring?

A: Teams often watch dependency installation while ignoring registry writes. That misses the outbound side of supply chain abuse, where a registry can be used as a data drop or staging layer. Monitoring must include publish intent, source host, and process context, not only package consumption and signature checks.

Q: How should organisations respond when a build or scraper process publishes to a registry?

A: Treat it as a security event until proven otherwise. Preserve the host context, review the package contents, revoke any publishing credentials used by that process, and confirm whether the archive carries scraped data or other sensitive material. Then separate publish rights from all non-release workloads.

Technical breakdown

How RubyGems registry abuse turns publishing into exfiltration

GemStuffer uses RubyGems in a way that inverts normal package behaviour. The scripts fetch public web content, store the responses inside a valid .gem archive, and then publish the archive to RubyGems. That means the registry is not just distributing software, it is also carrying attacker-selected payloads and stolen or scraped data. Because the archive is structurally valid, simple file handling and package inspection may not reveal the abuse unless defenders look at publishing intent, not just package format.

Practical implication: monitor who can publish to registries, not only what can be installed from them.

Hardcoded API keys and local credential files are the access control failure

The samples create or override RubyGems credentials in unexpected locations such as /tmp/gemhome/.gem/credentials, then push packages with a hardcoded API token or direct HTTP authorisation header. That is an identity governance issue, because the registry token becomes a portable NHI with no clear lifecycle boundary. When a token can be written to disk, reused by any process, and pushed outside release tooling, the registry trust model is already broken.

Practical implication: treat registry API keys like privileged NHI secrets and constrain where they can be created, stored, and used.

Why package registries need bidirectional trust controls

Many supply chain controls focus on inbound dependency consumption, but GemStuffer shows the outbound side is equally important. Publishing to a public registry from a scraper, build container, or non-release host should be unusual and highly controlled. In practice, this means registry APIs need allowlisting, process-context logging, and separation between build, publish, and runtime identities. Without that separation, an application process can become an exfiltration client.

Practical implication: separate build and publish identities, and alert on registry writes from non-release workloads.

Threat narrative

Attacker objective: The attacker objective is to move collected data through a trusted package registry while masking the activity as normal publishing.

1. Entry occurs when a script or process acquires a RubyGems API token or credentials file that can authenticate to the registry.
2. Escalation happens when the process uses that privilege to build and push valid .gem archives outside approved release workflows.
3. Impact is achieved when the attacker stores scraped data inside published gems and later retrieves it from RubyGems as a covert exfiltration layer.

Breaches seen in the wild

• JetBrains Marketplace AI Plugin Campaign — 15 malicious JetBrains Marketplace plugins steal AI API keys from 70,000+ developers via supply chain attack.
• Hard-Coded Secrets in VSCode Extensions — 500+ VSCode extensions expose hardcoded tokens and credentials creating massive developer supply chain risk.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Registry publishing is now a privileged identity path, not a low-risk developer convenience. GemStuffer shows that package registries can be repurposed as covert storage and transport for data exfiltration. That changes the control objective from simple package hygiene to lifecycle governance for publishing identities, API tokens, and release workflows. The relevant lesson for practitioners is that registry write access should be treated as a high-value privilege with constrained issuance and auditability.

Hardcoded credentials in build or scraping workflows create a non-human identity trust gap. The samples demonstrate how a token can be written into a temporary credential file and then used by any process that reaches the publish path. That is exactly the kind of credential mobility OWASP-NHI is meant to address, because the secret exists outside a governed lifecycle and can be reused outside intent. Practitioners should treat this as a failure of identity containment, not just poor secret storage.

Supply chain governance has to cover outbound publishing channels as well as inbound dependencies. Most organisations monitor what they install more closely than what they publish. GemStuffer flips that assumption by using a trusted registry as a data drop. The broader implication is that software supply chain controls need registry egress policy, process context, and release identity separation. Teams that only inspect dependency intake are missing the abuse path that attackers can exploit next.

Bidirectional trust surfaces are the new package ecosystem boundary. A registry is both an intake system and an output system, and attackers increasingly look for the weaker direction. That creates a governance gap where developer tooling, CI runners, and app runtimes inherit privileges they do not need. Practitioners should respond by mapping who can write to which registries, from which hosts, under which identities, then enforcing that map as a policy boundary.

GemStuffer is a named example of registry-as-exfiltration abuse. The specific failure mode is publishing privilege without lifecycle scoping. Once a process can authenticate to a registry and push arbitrary archives, the registry can carry stolen or scraped content as easily as it can carry legitimate releases. The practitioner takeaway is simple: if publishing is not tightly bound to release identity, the registry itself becomes an attack surface.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.
• From our research: Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control.
• Forward look: 52 NHI Breaches Analysis shows how unmanaged credentials repeatedly expand breach impact across identity and supply chain paths.

What this signals

Registry abuse is becoming an identity governance problem, not just a malware or package hygiene problem. When a process can authenticate to a registry and publish artifacts, that publishing identity needs the same lifecycle controls as any other privileged non-human identity. The practical change for programmes is to map every registry-write capability to a named owner, a release boundary, and an audit trail.

Publishing path governance is the missing concept here: organisations often govern package intake more tightly than package output. That gap matters because a registry can function as an exfiltration channel even when dependency controls are strong. Security teams should treat publish permissions, API token scope, and CI host context as first-class controls in supply chain governance.

The operational signal to watch is simple: if a workload that should only consume software starts writing to a public registry, the trust boundary has already moved. In broader identity terms, that is a non-human identity using a higher privilege path than its function requires. Aligning that activity with least privilege and release-only trust boundaries should now be part of supply chain policy.

For practitioners

• Restrict registry publishing to approved release identities Allow gem push and RubyGems API writes only from signed release workflows, not from general CI jobs, app runtimes, or scraping hosts. Separate publish permissions from build permissions so a compromised runtime cannot turn registry access into exfiltration.
• Audit and rotate RubyGems API tokens as privileged secrets Inventory where RubyGems credentials exist, including temporary home directories and build images. Rotate tokens that can publish packages, scope them to the minimum package set, and revoke any token that can be used outside controlled pipelines.
• Detect abnormal package creation and upload behaviour Alert on unexpected POSTs to https://rubygems.org/api/v1/gems, gem build activity from non-release hosts, and processes that set HOME to a /tmp path before pushing packages. Those combinations are strong indicators of registry abuse or covert staging.
• Inspect packages for embedded data and staging artifacts Look for files such as lib/result.txt, README content, and unusual script names inside newly published gems, especially when packages are low-download or newly registered. Compare publish timing, host context, and archive contents to identify hidden exfiltration payloads.

Key takeaways

• GemStuffer demonstrates that a public package registry can be abused as a covert exfiltration channel, not just a distribution mechanism.
• Hardcoded publishing tokens and temporary credential files turn registry access into an unmanaged non-human identity problem.
• Security teams should govern registry write paths, token scope, and release identity separation as part of supply chain control, not treat them as developer convenience issues.

Key terms

• Registry Exfiltration: Registry exfiltration is the abuse of a software package registry as a storage or transport channel for stolen or scraped data. Instead of only delivering code, the registry carries attacker-controlled content inside valid artifacts, making the traffic look like normal publishing activity while hiding the real payload.
• Publishing Identity: The account, token, or credential set that authorises changes to a software package distribution channel. It is a privileged non-human identity because it can affect many downstream systems at once, so compromise of this identity can become an ecosystem-wide security event.
• Bidirectional Trust Surface: A bidirectional trust surface is a system that must be trusted both for incoming consumption and outgoing publication. Package registries fit this model because they receive dependencies and also accept uploads, which means defenders must govern read and write paths with different controls and monitoring signals.

What's in the full analysis

Corgea's full analysis covers the operational detail this post intentionally leaves for the source:

• Package-level indicators and filenames tied to the GemStuffer campaign, including representative artifacts and registry-abuse patterns.
• The exact Ruby execution and packaging sequence used to fetch public council pages, stage content, and publish .gem archives.
• Detection guidance for Ruby processes that override HOME, create credentials in temporary directories, or push to RubyGems from non-release contexts.
• Remediation actions for registry governance, including release workflow restrictions and API token rotation.

👉 Corgea's full analysis covers the Ruby execution chain, registry indicators, and remediation steps.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity. It helps security and identity practitioners connect identity lifecycle controls to real-world misuse of privileged automation.