Skip to content

Back to the catalog

SleeperGem: RubyGems supply chain attack targets dormant maintainer accounts
aikido.devwriteup

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.

TL;DR A malicious RubyGems package, git_credential_manager, hijacked two long-dormant maintainer accounts to drop CI-evading malware into trusted gems like Dendreo and a fastlane plugin with 574k downloads.
Document

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/sh

The 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 for git_credential_manager, the affected Dendreo versions, and the rogue fastlane-plugin-run_tests_firebase_testlab release; 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