SleeperGem — dormant RubyGems maintainer takeover drops persistent developer-laptop backdoor via `git.disroot.org` Forgejo second-stage (git_credential_manager, Dendreo, fastlane-plugin-run_tests_firebase_testlab)

What happened

On 2026-07-18 → 07-19 an actor reactivated two long-dormant RubyGems maintainer accounts and published a brand-new impersonator gem in a 24-hour window that Aikido named SleeperGem — the first known at-scale RubyGems dormant-maintainer takeover of the shape that has hit npm and PyPI repeatedly since 2024. Three gems were compromised across seven releases; every release has been yanked from rubygems.org and every affected version is listed in the packages map below.

The three compromised gems

| Gem | Malicious versions | Publish (UTC) | Dormancy before compromise | Yanked? | |---|---|---|---|---| | git_credential_manager | 2.8.0, 2.8.1 | 2026-07-18 | N/A (brand-new gem) | Yes | | git_credential_manager | 2.8.2, 2.8.3 | 2026-07-19 (17 min apart) | N/A | Yes | | Dendreo | 1.1.3, 1.1.4 | 2026-07-18 | ~6 years (last release 2020-10-24) | Yes | | fastlane-plugin-run_tests_firebase_testlab | 0.3.2 | 2026-07-19 | ~7 years (last release 2019-03-04) | Yes |

git_credential_manager — the impersonator

A brand-new gem published under a fresh account, named to impersonate Microsoft's git-ecosystem/git-credential-manager CLI. The real Microsoft tool is distributed as a native binary through Homebrew / apt / a Microsoft installer and has never been shipped as a Ruby gem — so the mere existence of a RubyGems package by that name is itself the deception. Version numbers 2.8.x were chosen to sit slightly ahead of the real project's 2.6.x release train, giving the fake plausible "latest" placement in gem search results.

The operator shipped four versions in rapid succession. The first two (2.8.0, 2.8.1 on 2026-07-18) contained a downloader-only installer. After an eight-hour pause (presumably an overnight break in the operator's time zone), 2.8.2 and 2.8.3 landed on 2026-07-19 seventeen minutes apart — 2.8.2 wired the installer into the gem's Ruby load path (so require "git_credential_manager" fires the chain, not just gem install), and 2.8.3 uncommented the single line that actually executes the downloaded binary. This staged-uncomment pattern suggests the operator was watching install telemetry in real time and iterating quickly to activate the payload once install volume looked convincing.

Dendreo — the dormant-account takeover

Dendreo had shipped 1.0.1 → 1.1.2 between 2017-10-14 and 2020-10-24, then went silent for ~6 years. On 2026-07-18 the account pushed 1.1.3 and 1.1.4 back-to-back on the same day. Both were yanked; 1.1.0 from the historical release train was also yanked as part of the cleanup, so the current known-good version on RubyGems is 1.1.2 (2020-10-24).

fastlane-plugin-run_tests_firebase_testlab — dormant + no upstream Git tag

This fastlane plugin last shipped 0.3.1 on 2019-03-04 and went silent for ~7 years. On 2026-07-19 a 0.3.2 release appeared on RubyGems. Two independent takeover tells confirm the compromise:

1. Dormancy gap: seven years with no publish, then a single release out of the blue.
2. No matching Git tag in the upstream source repository. Legitimate fastlane plugins are always tagged in Git as part of the release workflow, so a RubyGems release with no corresponding Git tag never came from the real project.

Install-time payload chain

1. gem install / bundle install triggers the gem's installer hook (or, for git_credential_manager 2.8.2+, the load-path require).
2. The installer runs a skip_install check — it scans the process environment for ~30 CI-platform environment variables (GITHUB_ACTIONS, GITLAB_CI, CIRCLECI, TRAVIS, JENKINS_URL, VERCEL, BUILDKITE, DRONE, TEAMCITY_VERSION, etc.) and returns immediately if any are set. This is a deliberate choice to fly under automated malware scanners (Socket / Aikido / OpenSSF Package Analysis all run in CI-shaped environments) while still landing on human developer laptops.
3. On a laptop (no CI vars), the installer fetches a native binary from https://git.disroot.org/git-ecosystem/* — a public Forgejo instance where anyone can register. The git-ecosystem username on that instance was registered by the attacker specifically to visually mimic the real github.com/git-ecosystem organization on GitHub that publishes the Microsoft Git Credential Manager. SSL verification is disabled on the download call.
4. The binary is executed via system() (Linux/macOS) or PowerShell (Windows) and, per StepSecurity's analysis, establishes persistence and beacons to attacker infrastructure.

Why "SleeperGem"

Aikido coined the name to capture the core novelty: the compromise vector is not a fresh account or a typosquat, but real, ordinary accounts that had simply gone dormant and looked harmless enough to hijack without anyone noticing. The pattern is well-established on npm (node-ipc 2026-05-14, dbmux 2026-06-09) and on PyPI, but RubyGems had until now been largely spared — SleeperGem marks the first time the same playbook has been executed at scale against Ruby maintainers.

Registry state (2026-07-19)

All seven malicious releases have been yanked from rubygems.org — the versions are no longer resolvable via bundle install against the public registry. However, gems that were pulled into a lockfile between 2026-07-18 and the yank window will remain pinned to the malicious versions on any host where the Gemfile.lock was frozen. Internal RubyGems mirrors (Bundler-Inc, Artifactory RubyGems, Gemfury) that cached the tarballs during the publish window will continue to serve them after the public yank — any lockfile hit against the versions in the packages map below must be treated as active malware regardless of what rubygems.org currently returns.

Affected packages (3)

Impact

• Any developer laptop that ran gem install or bundle install and resolved one of the seven malicious releases below during 2026-07-18 → 07-19 should be treated as fully compromised — the payload deliberately skips CI/build servers and targets interactive developer machines, so exposure surface is workstations that actively ran bundle install in that window
• Attack shape (SleeperGem — Aikido, 2026-07-19): two previously dormant RubyGems maintainer accounts were reactivated within hours of each other to push the same malicious dependency into gems people already trusted — the first known RubyGems dormant-maintainer takeover of the scale npm and PyPI have dealt with for over a year. Combined with the brand-new git_credential_manager gem impersonating Microsoft's official Git Credential Manager CLI, three gems were compromised in a 24-hour window
• Compromised account 1 — Dendreo (dormant since 2020-10-24): two malicious versions 1.1.3 and 1.1.4 pushed on 2026-07-18 after ~6 years of dormancy. Both yanked; the account had previously shipped 1.0.1 → 1.1.2 between 2017 and 2020
• Compromised account 2 — fastlane-plugin-run_tests_firebase_testlab (dormant since 2019-03-04): malicious 0.3.2 released on 2026-07-19 after ~7 years of dormancy. Yanked. Has no matching Git tag in the upstream source repository — the smoking gun that the release never came from the real project
• Brand-new impersonator gem — git_credential_manager (never previously existed): four malicious releases in rapid succession — 2.8.0 and 2.8.1 on 2026-07-18, then 2.8.2 and 2.8.3 on 2026-07-19 seventeen minutes apart. The 2.8.x version alignment mimics the real git-ecosystem/git-credential-manager release train (the Microsoft-maintained CLI is at 2.6.x in mid-2026); the naming and versioning is designed to be picked up by anyone searching for the Microsoft tool via gem install
• git_credential_manager escalation chain: 2.8.0 and 2.8.1 shipped a downloader-only installer. After an eight-hour gap (presumably the operator's sleep window), 2.8.2 wired the downloader directly into the gem's Ruby load path so merely require "git_credential_manager" triggers the whole chain — no explicit installer invocation needed. The line that actually invokes the downloaded binary was commented out in 2.8.2 and uncommented seventeen minutes later in 2.8.3 — an unusually fast operator-visible iteration cycle that suggests the actor was watching install telemetry in real time
• Second-stage delivery — git.disroot.org Forgejo abuse: the installer fetches a native binary from https://git.disroot.org/git-ecosystem/* (a public Forgejo instance where anyone can register). The git-ecosystem username on that instance was registered by the attacker to visually mimic the real github.com/git-ecosystem organization that publishes the Microsoft Git Credential Manager — a namespace-collision technique that also works because the Forgejo instance federates to git.disroot.org and appears as a legitimate-looking URL. SSL verification is disabled on the download call, so any TLS-inspecting proxy that would have flagged the certificate mismatch is bypassed
• CI evasion — skip_install check on ~30 environment variables: the installer scans the environment for any of a curated list of ~30 CI-platform env vars (GITHUB_ACTIONS, GITLAB_CI, CIRCLECI, TRAVIS, JENKINS_URL, VERCEL, BUILDKITE, etc.) and does nothing if any are present. This is a deliberate choice to fly under the radar of automated malware scanners (Socket / Aikido / OpenSSF Package Analysis all run in ephemeral CI-shaped environments) while still landing on human developer laptops where an initial infection can pivot to source-code access, SSH keys, browser credentials, and cloud CLI tokens
• Persistent daemon: on a developer laptop (no CI env vars present) the installer downloads a native binary and executes it via system() on Linux/macOS or PowerShell on Windows. StepSecurity's analysis confirms the binary establishes persistence and beacons back to attacker infrastructure — the exact C2 shape has not been publicly disclosed as of 2026-07-19

What to do

1. 1Grep every Gemfile.lock for the exact gem-name + version pairs in the packages map below. Any match on a developer laptop (not a CI runner — the malware deliberately skipped CI) is a full compromise: re-image the laptop, rotate every credential the developer had touched (git tokens, cloud CLI, SSH keys, browser-saved passwords, IDE Copilot/AI provider tokens, RubyGems API keys)
2. 2If you had git_credential_manager in a Gemfile.lock: this gem never had a legitimate parent — it was created solely to impersonate the github.com/git-ecosystem/git-credential-manager CLI, which is distributed as a native binary (not a gem) and is normally installed via Homebrew, apt, or the Microsoft installer. There is no legitimate reason to have git_credential_manager as a gem dependency — the presence of it in a lockfile is by itself a supply-chain incident
3. 3If you had Dendreo in a Gemfile.lock at 1.1.3 or 1.1.4: downgrade to 1.1.2 (2020-10-24 — the last known-good release before the maintainer went dormant) or replace with an alternative. Contact the original maintainer through a channel other than the compromised RubyGems account to confirm any future release
4. 4If you had fastlane-plugin-run_tests_firebase_testlab at 0.3.2: pin back to 0.3.1 (2019-03-04) or migrate off the plugin — Firebase Test Lab is now typically driven directly via gcloud firebase test rather than through this dormant fastlane plugin
5. 5Audit outbound traffic from developer laptops for HTTPS calls to git.disroot.org from a Ruby / gem installer process — legitimate Ruby developer workflows almost never hit that Forgejo instance, so any hit during the 2026-07-18 → 07-19 window (or later, if the operator republishes) is a strong SleeperGem indicator. The download call disables SSL verification, so any TLS-inspecting proxy will have seen the cleartext HTTP-CONNECT to git.disroot.org:443 even if it could not decrypt the response
6. 6Search EDR / process telemetry for ruby or bundler invoking system() / sh -c / powershell.exe during a gem install or bundle install operation, with a payload that fetches a binary from a non-rubygems.org host. This is the SleeperGem-family install-time behaviour signature
7. 7For RubyGems-security defenders: this is the first at-scale dormant-maintainer takeover of RubyGems. Consider requiring 2FA and forced-reset on any RubyGems account that has been inactive for >1 year, and treat any new release from a >5-year-dormant account as suspicious by default. Any gem published from a dormant account without a matching Git tag in the upstream repo is a strong takeover signal

References

• SleeperGem: RubyGems supply chain attack targets dormant maintainer accounts

  aikido.dev
  Aikido
• SleeperGem: Compromised git_credential_manager, Dendreo, and fastlane RubyGems Drop a Persistent Backdoor

  stepsecurity.io
  StepSecurity
• git_credential_manager on RubyGems (yanked versions listing)

  rubygems.org
  RubyGems
• Dendreo on RubyGems (yanked versions listing)

  rubygems.org
  RubyGems
• fastlane-plugin-run_tests_firebase_testlab on RubyGems (yanked versions listing)

  rubygems.org
  RubyGems
• git-ecosystem/git-credential-manager — the real Microsoft-maintained CLI the impersonator gem mimics

  github.com
  GitHub