SleeperGem: hijacked dormant RubyGems accounts pulled a fake git_credential_manager into Dendreo and a fastlane plugin

What happened

On 19 July 2026, Aikido reported SleeperGem: an attacker took over RubyGems maintainer accounts that had been dormant for years and used them to push a malicious dependency into existing projects (Aikido). Wiz counts at least two accounts dormant since 2019 (Wiz).

• git_credential_manager 2.8.0 to 2.8.3, a new gem impersonating Microsoft’s Git Credential Manager (StepSecurity).
• Dendreo 1.1.3 and 1.1.4, published 18 July 2026 after no release since 2020. These added git_credential_manager as a dependency.
• fastlane-plugin-run_tests_firebase_testlab 0.3.2, published 19 July 2026 with no matching GitHub tag; upstream tags stop at v0.3.1.

The Hacker News reports that git_credential_manager was also added as a dependency of slackHtmlToMarkdown, seo_optimizer and array_fast_methods, and that Dendreo is maintained by the account LR-DEV. Releases were pushed straight to the registry with no matching commit or tag (The Hacker News). Versions for those three extra gems were not published.

Four versions in about nine hours (Aikido):

• 2.8.0: a working dropper that downloads from a hardcoded Forgejo host with TLS verification off and runs the payload with /bin/sh or PowerShell.
• 2.8.1, 24 minutes later: sends Unix output to /dev/null.
• 2.8.2, about eight hours later: wires the installer into the load path so require triggers it, with the launch line commented out.
• 2.8.3, 17 minutes later: the launch line is live.

As of 2 November 2026, git_credential_manager and array_fast_methods are gone from RubyGems, and the newest Dendreo and fastlane plugin versions listed are 1.1.2 (October 2020) and 0.3.1 (March 2019) (RubyGems: Dendreo).

How the payload works

Details from StepSecurity unless stated:

1. CI check. It looks for about 30 CI environment variables, including GITHUB_ACTIONS, GITLAB_CI and CIRCLECI, and exits if any is set. The target is developer laptops, not build servers.
2. Download. It fetches deploy.sh and a native git-credential-manager binary from git.disroot.org/git-ecosystem/... with the User-Agent Git. The base URL in the code is https://git.disroot.org/git-ecosystem/#{product}/raw/branch/main (Aikido).
3. Daemon. The binary is copied to $HOME/.local/share/gcm/git-credential-manager and started with --daemon. A config file is written to $HOME/.local/share/gcm/.env. StepSecurity says credential harvesting and exfiltration live in this daemon but did not analyse it.
4. Persistence. A systemd user service named git-credential-manager and a cron entry with the same name.
5. Root backdoor. If the user has passwordless sudo, the script reruns as root and drops a setuid root copy of the shell at /usr/local/sbin/ping6, mode 6777.

Am I affected?

# Lockfiles in your projects
grep -nE '^ +(git_credential_manager|Dendreo \(1\.1\.[34]\)|fastlane-plugin-run_tests_firebase_testlab \(0\.3\.2\)|slackHtmlToMarkdown|seo_optimizer|array_fast_methods)' Gemfile.lock 2>/dev/null

# Installed gems
gem list 2>/dev/null | grep -E '^(git_credential_manager|Dendreo|fastlane-plugin-run_tests_firebase_testlab) '

# Dropped daemon and config
ls -la ~/.local/share/gcm/ 2>/dev/null

# Persistence
systemctl --user status git-credential-manager 2>/dev/null
crontab -l 2>/dev/null | grep -i 'git-credential-manager'

# Root backdoor: ping6 should not be a setuid shell
ls -la /usr/local/sbin/ping6 2>/dev/null

Remember that the real Git Credential Manager from Microsoft is also called git-credential-manager. The malicious daemon lives under ~/.local/share/gcm/ and runs with --daemon; check the path before you delete anything. In DNS and proxy logs, any connection to git.disroot.org with User-Agent Git means the loader ran (StepSecurity).

What to do now

1. Remove the gems and pin Dendreo to 1.1.2 or earlier and the fastlane plugin to 0.3.1 or earlier, then bundle install from the corrected lockfile. Drop git_credential_manager entirely.
2. Remove persistence: systemctl --user disable --now git-credential-manager, delete the matching cron line and ~/.local/share/gcm/.
3. Remove the setuid shell at /usr/local/sbin/ping6 if present. Its presence means the attacker had root, so rebuild the machine.
4. Rotate SSH keys, cloud credentials, tokens in environment files and browser-stored secrets on the machine (StepSecurity). The daemon’s exact collection list is not disclosed, so assume everything on disk was read.
5. Do not rely on CI to catch this. The loader deliberately exits on CI runners, so a clean CI scan says nothing about developer laptops. Run the checks above on workstations.

Why this matters

The attacker did not need a popular gem. Old gems with few updates still sit in many lockfiles, and a patch release from a long-silent maintainer is accepted by any loose version constraint. A sudden release after years of silence, with no matching tag, was the signal here.

Sources

• Aikido: SleeperGem RubyGems supply chain attack
• StepSecurity: SleeperGem compromised RubyGems drop persistent backdoor
• The Hacker News: SleeperGem uses three malicious gems
• Wiz threat center: SleeperGem
• RubyGems: Dendreo versions