SleeperGem: Compromised git_credential_manager, Dendreo, and fastlane RubyGems Drop a Persistent Backdoor

What it is

Detailed detonation analysis of SleeperGem, the July 18–19, 2026 RubyGems supply-chain attack affecting git_credential_manager (impersonating Microsoft's Git Credential Manager), Dendreo, and fastlane-plugin-run_tests_firebase_testlab. The value here beyond the summary is version-level behavior and concrete signatures.

How it works

Each gem is a thin loader. For git_credential_manager, the malicious code runs on require, not just at install time — merely loading the library in a developer's process spawns a child Ruby process that runs the bundled install script, which executes the downloaded deploy.sh.

The download uses Ruby's built-in HTTP client with certificate verification disabled and a User-Agent: Git header to blend with legitimate Git traffic. It pulls two files — deploy.sh and a native binary named after the impersonated tool — from a public Forgejo instance at git.disroot.org, where the attacker registered a username mimicking an official ecosystem account.

deploy.sh copies the binary to $HOME/.local/share/gcm/, launches it as a daemon, and installs persistence twice under the name git-credential-manager (systemd user service + cron). It then probes sudo/wheel; with passwordless sudo it re-runs as root and plants a setuid-root system shell at a path mimicking a networking utility.

Preconditions / Affected

• A developer machine, not CI. The loader checks ~30 CI env vars (GITHUB_ACTIONS, GITLAB_CI, CIRCLECI, …) and exits silently if any are set. A normal pipeline install shows zero malicious behavior — do not treat a clean CI run as evidence of safety.
• Version matters: git_credential_manager 2.8.2 stages but does not detonate — the line launching deploy.sh is commented out, so it only downloads. 2.8.3 removes that safety and runs the full chain. Malicious behavior begins at 2.8.2+.
• Root escalation only fires where the user has passwordless sudo; otherwise the branch checks the group and stops (but the code is present).

What to do

The page gives no patch or command, but yields hunting signatures:

• Network: any outbound GET to git.disroot.org from a ruby process, especially with User-Agent: Git.
• Filesystem: binary under $HOME/.local/share/gcm/; a setuid-root shell at a network-utility-like path.
• Persistence: systemd user service and cron entries named git-credential-manager.
• Provenance: these releases have no matching source commit or tag; two gems shipped after years of dormancy (Dendreo two versions same day after ~6 years; the fastlane plugin's 0.3.2 has no GitHub tag). Verify RubyGems versions against upstream release tags.

Caveats

Findings come from StepSecurity detonating the gems in GitHub Actions with Harden-Runner audit mode, with CI env vars manually stripped to force developer-machine behavior. The root-escalation path was not observed completing — the test runner lacked passwordless sudo, so that branch stopped at the group check.