SleeperGem: The Day RubyGems Became an npm-Style Target

Three malicious RubyGems packages compromised developer workstations through require-time execution and CI evasion. The campaign marks RubyGems' entry into the same supply-chain threat club as npm and PyPI.

Between July 18 and 19, 2026, three RubyGems packages published by maintainer accounts dormant for years executed malicious code at library load time, not during installation. The attack, dubbed SleeperGem, bypassed CI-based security controls and established persistent backdoors on developer machines, demonstrating that RubyGems now faces the same problems as npm and PyPI.

Key Takeaways

Malicious versions 2.8.0-2.8.3 of git_credential_manager were published over roughly nine hours on July 18, with execution triggered at require starting in version 2.8.2 and made fully operational in 2.8.3 after 17 minutes
The malware checked for roughly 30 CI environment variables (GitHub Actions, GitLab CI, CircleCI, Travis, Jenkins, Vercel) and terminated execution if a build environment was detected, thereby evading pipeline controls
StepSecurity confirmed via Harden-Runner the runtime chain: child Ruby process, download of deploy.sh from git.disroot.org with SSL verification disabled, persistence installation via systemd and cron, attempted setuid root shell in /usr/local/sbin/ping6
The two confirmed compromised accounts — LR-DEV (Dendreo) and pinkroom (fastlane plugin) — had been dormant since October 2020 and March 2019 respectively; the Fastlane plugin had 574,661 total downloads before compromise

Require-Time Execution: The Moment AppSec Ignores

In most software security pipelines, danger is localized to the installation moment: post-install hooks, pre-compilation scripts, build actions. RubyGems, like npm and PyPI, permits code execution at install time, and that is what security tools monitor.

Version 2.8.2 of git_credential_manager inverted this logic. The installer was hooked directly into the gem's load path, according to Aikido Security's analysis. A simple require 'git_credential_manager' — a routine, invisible operation for millions of Ruby developers — triggered the entire chain.

This is particularly insidious in interpreted languages. In Ruby, require is a daily, automatic gesture, often hidden inside Bundler or frameworks like Rails. No one checks what happens when a library enters memory. The boundary between "safe installation" and "dangerous runtime" dissolves.

Dormancy as an Attack Vector

"A RubyGems account that has been inactive for six or seven years doesn't look risky to anyone. It's exactly the profile worth targeting." — Charlie Eriksen, Aikido Security

The LR-DEV account last published a version of Dendreo in October 2020. The pinkroom account had been inactive since March 2019. This history has two effects: it eliminates vigilance — no one flags anomalies on an account that doesn't publish — and preserves legitimacy: the gems accumulated downloads, stars, and transitive dependencies over time.

Dendreo 1.1.3 and 1.1.4 were published on July 18. fastlane-plugin-run_tests_firebase_testlab 0.3.2 arrived on July 19. None of these releases had corresponding GitHub commits or tags, according to StepSecurity. The missing signature was evident, but detectable only if someone checked — and no one checks dormant accounts.

The Runtime Chain Documented by Harden-Runner

StepSecurity performed a controlled detonation of the gem via Harden-Runner, capturing the process tree and network events. The result: a child Ruby process spawning sh, then cp, chmod, and finally a native daemon. The daemon is installed in $HOME/.local/share/gcm/git-credential-manager and configured for persistence via user systemd service and cron entry.

The network event logged at 14:04:57 on July 19, 2026 shows two API calls to git.disroot.org, a Forgejo instance controlled by the attacker. The download occurs with OpenSSL::SSL::VERIFY_NONE: TLS certificate verification is explicitly disabled in the code, as reported by Aikido Security with a source excerpt.

StepSecurity also documented the attempt to install a setuid copy of the system shell in /usr/local/sbin/ping6, a path chosen to masquerade as a network utility. The operation was observed but blocked by the lack of passwordless sudo in the test environment. It remains documented as intent, not guaranteed success.

What to Do Now

Workstations that loaded any of the three gems must be considered fully compromised. This implies rotation of all credentials — not just RubyGems credentials, but SSH keys, API tokens, cloud access, password managers — stored or accessible from the machine.

Organizations using Ruby, Bundler, or Fastlane must check lockfiles for the presence of git_credential_manager versions 2.8.x, dendreo 1.1.3-1.1.4, or fastlane-plugin-run_tests_firebase_testlab 0.3.2. RubyGems has removed the malicious versions, but anyone who already had them in local cache remains exposed.

Developer machines require manual inspection for persistence mechanisms: user-level systemd services, cron entries, files in ~/.local/share/gcm/, and suspicious binaries in system paths like /usr/local/sbin/. The malware specifically avoided the CI environment: a passing build test is no security guarantee.

Security teams must extend monitoring to dormant dependencies. Gems without updates for years but with substantial downloads should be flagged for periodic verification, as already happens for npm and PyPI. The risk profile is identical: abandoned account, reused, exploited for its veneer of legitimacy.

Why RubyGems, Why Now

The attack does not exploit a vulnerability in RubyGems.org as a platform, but a vulnerability in the trust model: the lack of revocation or verification mechanisms for accounts that become active again after years of silence. npm faced similar campaigns in 2022-2024; PyPI introduced mandatory checks for inactive accounts. RubyGems, until SleeperGem, had remained relatively unscathed — not due to robustness, but due to lower ecosystem attractiveness.

That assumption is now dead. The value of a supply-chain attack lies not only in immediate download numbers, but in target quality: developers with access to source code, release infrastructure, production secrets. A Fastlane gem with 574,661 total downloads is a direct bridge to mobile CI/CD pipelines, distributed test environments, and — through developer machines — to segmented corporate networks.

Questions and Answers

Why did the malware explicitly avoid CI?

Because CI environments are monitored: verbose logs, anomaly detection tools, sandboxing. Developer machines are more opaque, less controlled, and often have privileged access to repositories and infrastructure. The malware inverted the classic threat model: not the build server, but the developer's laptop.

Are the malicious versions still available?

No. The RubyGems security team has removed the compromised versions from the repository. However, removal from the central registry does not eliminate local cached copies, lockfiles, or already-built Docker images.

How many accounts were compromised in total?

Two are confirmed with certainty: LR-DEV and pinkroom. The dossier does not rule out additional accounts, but documents neither numbers nor names beyond these two. The assertive statement stops here.

Sources

Information verified against cited sources and current as of publication.

Sources

Sources and references