Software supply chain attacks have a well-worn playbook by now: publish a typosquatted package, or slip a malicious update into a popular one, and wait for developers or CI pipelines to pull it in. The attack security researchers disclosed this week under the name "SleeperGem" follows that playbook in the RubyGems ecosystem, but with a twist worth paying attention to — it deliberately avoids CI systems altogether and targets developer machines specifically, using dormant maintainer accounts that had been trusted, unremarkable, and untouched for years before being quietly hijacked and weaponized.
The attack: hijacked accounts, not new packages
SleeperGem doesn't rely on typosquatting or newly registered lookalike packages, which makes it harder to catch with the pattern-matching defenses many organizations have built up against that specific technique. Instead, the attackers compromised at least two dormant maintainer accounts on RubyGems and pushed malicious updates to existing, trusted packages under those legitimate identities. One package, "git_credential_manager," impersonates Microsoft's official Git Credential Manager — a name specifically chosen to look like infrastructure tooling a developer would trust without a second thought. The other two, "Dendreo" and "fastlane-plugin-run_tests_firebase_testlab," are packages that had gone dormant, receiving no meaningful updates for years, before suddenly shipping new malicious releases. The fastlane plugin alone carries 574,661 total downloads, and at least one of the three packages exceeds half a million downloads on its own — meaning the compromised accounts had built exactly the kind of quiet, long-standing trust and install base that makes a supply chain attack effective.
The account compromise itself appears to span more than one maintainer identity. Most of the malicious packages trace back to a single account, "LR-DEV," but the fastlane plugin belongs to a different maintainer, "pinkroom," indicating the attackers successfully compromised at least two separate dormant accounts rather than a single point of failure. That detail matters for anyone trying to assess how the compromise happened in the first place — a single leaked credential explains one account, but two independently compromised accounts suggests either a broader credential-stuffing campaign against inactive RubyGems maintainers, or a more systemic weakness in how dormant accounts are secured on the platform.
The payload: built specifically to avoid CI and hit developer machines
The technical design of SleeperGem's payload is the most distinctive part of the story, and it reflects a deliberate strategic choice by the attackers about where they wanted to land. Each malicious release functions as a loader: on execution, it fetches a second-stage payload from an attacker-controlled host, but only after checking whether it's running inside a build system. The malware scans for roughly 30 environment variables associated with major CI platforms — GitHub Actions, GitLab, CircleCI, Travis CI, Jenkins, and Vercel among them — and if any of those variables are present, it exits immediately without doing anything further.
That's the opposite of what most software supply chain attacks optimize for. CI pipelines are typically the highest-value target in this kind of attack, because they often hold deployment credentials, signing keys, and access to production infrastructure, and a compromise there can propagate silently into shipped software. SleeperGem instead specifically avoids CI environments and only proceeds when it detects it's running on what looks like a developer's own machine — dropping a native daemon and installing persistence once it confirms that context. The likely reasoning is straightforward: CI environments are ephemeral, heavily monitored, and increasingly instrumented with runtime security tooling that would catch anomalous outbound network activity quickly. A developer's own machine, by contrast, is longer-lived, less consistently monitored, and often holds a broader set of credentials, SSH keys, and access tokens accumulated over months or years of day-to-day work — a genuinely richer target once the attacker has decided speed of detection matters less than depth of access.
The infrastructure behind the second stage
The second-stage payload is hosted on a public Forgejo instance at git.disroot[.]org, under a repository registered to the username "git-ecosystem" — a name specifically chosen to look legitimate enough that a cursory glance at the download URL wouldn't raise immediate suspicion. Using a public, self-hostable Git platform rather than attacker-owned infrastructure is a reasonably effective way to blend malicious traffic in with what looks like ordinary open source package activity, and it's a technique likely to recur in future supply chain campaigns given how effective it appears to have been here at delaying detection.
Why dormant accounts are a structurally hard problem
SleeperGem is a useful case study in a specific category of supply chain risk that's easy to underweight: the accumulated trust built up by long-dormant but still-active maintainer accounts on public package registries. A package that hasn't shipped an update in years isn't necessarily abandoned in any way that shows up in a security review — it's still installable, still has its full historical download count, and in many dependency trees, it's still quietly present as a transitive dependency nobody's actively thinking about. That combination — real trust, real install base, minimal ongoing scrutiny — is exactly the profile an attacker wants when hijacking an account is easier than building a new one's reputation from scratch.
This isn't a Ruby-specific problem, either. The npm ecosystem has dealt with strikingly similar attacks: dormant maintainer accounts compromised, trusted packages poisoned, malicious updates pushed under a legitimate identity. What SleeperGem adds to that pattern is the CI-avoidance logic, which suggests attackers are getting more sophisticated about which victims are actually worth compromising, rather than treating every downstream install — human or automated — as an equally valuable target.
What Ruby shops and package maintainers should actually do
If your organization uses Ruby and Bundler in its stack, the first concrete step is to audit your Gemfile.lock for the three specifically named packages — "git_credential_manager," "Dendreo," and "fastlane-plugin-run_tests_firebase_testlab" — and check installed versions against the known-malicious release versions documented in the security advisories that broke this story. Given that the malware specifically targets developer workstations rather than CI, the priority scan should be developer machines first, not just your build pipeline, which inverts the usual triage order many security teams default to.
Beyond this specific incident, it's worth reviewing your dependency management practices for the broader risk pattern SleeperGem represents. Consider whether your organization pins gem versions and reviews diffs on updates to dependencies, even ones that haven't changed in years — a sudden update to a long-dormant package is itself a signal worth treating with more scrutiny than a routine update to an actively maintained one. If you maintain a public RubyGems package yourself, this is a good prompt to enable two-factor authentication if you haven't already, review your account's recent activity, and treat any prompt to re-authenticate or "verify your account" arriving via email with the same suspicion you'd apply to a phishing attempt targeting production credentials — because for a maintainer account with a large install base, that's functionally what it is.
How this compares to the npm ecosystem's own recent attacks
It's worth explicitly connecting SleeperGem to the broader 2026 pattern of software supply chain attacks that this blog has covered across multiple package ecosystems this year, including npm attacks that exploited GitHub Actions workflow permissions to compromise CI pipelines directly. The contrast is instructive: those npm-focused attacks generally targeted CI infrastructure as the primary objective, aiming to compromise build and deployment credentials at scale. SleeperGem's explicit avoidance of CI environments suggests either a different attacker with a different objective — perhaps more interested in developer-machine access for reconnaissance, credential harvesting from personal accounts, or establishing long-term persistence on individual engineers' machines rather than compromising a build pipeline in one shot — or a recognition that CI-focused attacks have become harder to execute successfully as CI providers have hardened their environments against exactly that threat model over the past year. Either explanation points to the same broader conclusion: as one category of supply chain attack becomes harder to pull off, attackers are visibly adapting their targeting rather than giving up on the technique entirely, and defenders need to extend monitoring coverage to developer endpoints rather than concentrating supply-chain defenses purely on CI/CD infrastructure.
Practical takeaways
Search your dependency trees — starting with developer machines, not just CI — for git_credential_manager, Dendreo, and fastlane-plugin-run_tests_firebase_testlab, and check installed versions against the malicious releases documented in current security advisories. Don't assume a package is safe because it's long-established and rarely updated; a dormant package with a large download count is precisely the profile SleeperGem exploited, and a sudden update after years of inactivity deserves scrutiny rather than a routine approval. Build detection logic — whether through EDR, host monitoring, or simple environment auditing — that can catch a package attempting to fingerprint whether it's running in a CI environment before deciding whether to execute a payload, since that specific evasion technique is likely to appear again in future supply chain campaigns. And if you maintain public packages yourself, enable strong authentication on your registry account today, regardless of how long it's been since you last shipped an update — dormant maintainer trust is exactly what attackers are learning to target.
SleeperGem is a reminder that supply chain security can't stop at scanning for known-malicious new packages. The bigger, harder problem is the enormous number of trusted, dormant, still-installable packages sitting quietly in dependency trees everywhere — waiting, as this attack's name suggests, for someone to wake them up.