The SleeperGem RubyGems Supply Chain Attack

What happened

On 18 July 2026, attackers published three malicious gem releases to RubyGems.org. Two of the gems were old developer libraries. A third gem, git_credential_manager, copied the name of a real Git tool.

Researchers at Corgea say the attackers took over dormant maintainer accounts. They added git_credential_manager as a dependency of trusted old gems. A user who installed or updated one of those gems then also received the loader. The Hacker News lists five gems that gained this dependency: Dendreo, fastlane-plugin-run_tests_firebase_testlab, slackHtmlToMarkdown, seo_optimizer and array_fast_methods. It reports that four of them belong to one account and the fastlane plugin belongs to another account. That points to more than one compromised account.

StepSecurity describes the loader. When Ruby requires the gem, the code starts a child Ruby process. That process downloads two files over HTTPS with certificate checks turned off. One file is a shell script named deploy.sh. The other is a native binary that uses the name of the tool.

The malware checks about 30 environment variables that CI systems set, such as GITHUB_ACTIONS, GITLAB_CI and CIRCLECI. If it finds one, it stops. It targets developer machines, not build runners.

The four git_credential_manager versions show the attackers testing their work. In 2.8.2 the line that starts the downloaded script is commented out, so that version only downloads the payload. Version 2.8.3 runs the full chain. Corgea says versions 2.8.2 and 2.8.3 moved the trigger from install time to the require() path. The code now runs when the library loads.

The persistence step installs the binary in $HOME/.local/share/gcm/. It adds a systemd user service and a cron entry. It then tries sudo. If sudo works, it plants a setuid root shell at /usr/local/sbin/ping6. Corgea says the packages were yanked on 19 July 2026.

Affected versions

• git_credential_manager 2.8.0, 2.8.1, 2.8.2 and 2.8.3.
• Dendreo 1.1.3 and 1.1.4. The last clean release is 1.1.2.
• fastlane-plugin-run_tests_firebase_testlab 0.3.2. The last clean release is 0.3.1.
• Other gems that gained git_credential_manager as a dependency: slackHtmlToMarkdown, seo_optimizer and array_fast_methods. The sources do not list their bad version numbers, so check any copy that depends on git_credential_manager.

StepSecurity documents the persistence steps for Linux. Corgea notes that the Windows path uses PowerShell with -ExecutionPolicy bypass.

Indicators of compromise

• Payload host: git.disroot.org, a public Forgejo instance. The path is under git-ecosystem. Traffic uses HTTPS with certificate checks off and the user agent Git.
• Files: deploy.sh and a native binary named like the tool.
• Dropped daemon: $HOME/.local/share/gcm/git-credential-manager.
• Daemon settings: $HOME/.local/share/gcm/.env.
• Setuid root shell with mode 6777, only if sudo worked: /usr/local/sbin/ping6.
• Systemd user unit named git-credential-manager, in ~/.config/systemd/user/.
• A cron entry that runs the dropped daemon.
• A Ruby process that starts a child Ruby process when a gem loads, followed by outbound HTTPS to git.disroot.org.

How to check

Search every lockfile for the bad versions, then look for the dropped files. The first command is from StepSecurity.

grep -RniE 'git_credential_manager \((2\.8\.[0-3])\)|Dendreo \(1\.1\.[34]\)|run_tests_firebase_testlab \(0\.3\.2\)' --include=Gemfile.lock .

Then check the machine for the persistence items.

gem list git_credential_manager
ls -l "$HOME/.local/share/gcm"
systemctl --user list-unit-files | grep git-credential-manager
crontab -l | grep git-credential-manager
ls -l /usr/local/sbin/ping6

A real ping6 may exist on some systems. Treat one with mode 6777 that you did not install as a finding. You can also search network logs for connections to git.disroot.org.

What to do now

1. Remove the bad gem versions. Set the gems to a known-good version and clear the gem cache.
2. Stop and disable the git-credential-manager systemd user service. Remove the cron entry. Delete ~/.local/share/gcm/.
3. Inspect /usr/local/sbin/ping6. Remove it if you did not install it.
4. Treat any machine that ran the code as compromised. Rotate SSH keys, cloud tokens, secrets in environment files and browser-stored credentials.
5. Review network logs for connections to git.disroot.org.
6. Before you update a dormant gem, compare the new release with the version you trust. Vigilance does this comparison and reports the file that gained a new capability. Here, the loader added code that downloads and runs a program, and the earlier releases had none.

What Vigilance showed

Vigilance compares the version you trust with the new one and names the file that gained a new capability. The block below is rebuilt from the public reports in the words Vigilance prints. It is not a captured scan, because the malicious release is not redistributed.

files scanned: 32 (1 Added)

HEADS UP  1 file can now do things the old version could not. The rest changed and gained nothing.

NEW FILE   extconf.rb
           It downloads from the internet, runs other programs and restarts itself after a reboot.

Sources

1. stepsecurity.io/blog/sleepergem-compromised-rubygems-drop-persistent-backdoor
2. corgea.com/research/sleepergem-rubygems-dormant-maintainer-backdoor-july-2026
3. thehackernews.com/2026/07/sleepergem-uses-three-malicious.html