This week Aikido Security disclosed SleeperGem, a supply chain attack targeting the Ruby ecosystem through RubyGems.org. Three packages were used as delivery vehicles, with the primary one being a trojanized version of git_credential_manager. The attack gets its name from the method: two of the three packages were published through legitimate maintainer accounts that had been dormant for six to seven years before being hijacked. The payloads target developer machines, not CI/CD pipelines, and install a persistent native daemon with a setuid shell.
How the hijack worked
RubyGems.org account takeovers targeting dormant accounts follow a consistent pattern. An account that was active years ago sits idle with no recent authentication activity. The original maintainer may no longer monitor it. Password reuse, credential stuffing from unrelated breaches, or abandoned recovery email addresses all create viable takeover paths. Once the account is hijacked, the attacker can publish a new version of any package the account maintains.
Aikido Security identified three packages in this campaign: git_credential_manager, with malicious versions 2.8.0 through 2.8.3 published July 18; Dendreo, updated through a hijacked dormant account; and fastlane-plugin-run_tests_firebase_testlab, following the same pattern. Aikido flagged all three before significant distribution occurred.
What each package does
Each package follows the same execution flow. On installation, the package fetches a second-stage payload from an attacker-controlled Forgejo instance. Before executing, the payload checks for CI/CD environment variables. If CI markers are present, execution terminates silently. This evasion is deliberate: the malicious behavior only triggers on developer machines, not automated pipelines.
On developer machines, the payload drops a native persistent daemon and installs system persistence. A setuid shell lands at /usr/local/sbin/ping6. On macOS, a launch daemon is installed. The malicious code targets locally stored credentials: SSH keys, Git authentication tokens, shell history, browser-stored passwords, and API keys found in dotenv files or shell profiles.
What to check now
Check your Gemfile.lock for any of the following: git_credential_manager versions 2.8.0 through 2.8.3; Dendreo or fastlane-plugin-run_tests_firebase_testlab at any version published after July 1, 2026. If you installed any of these packages on a developer machine, treat that machine as compromised.
Look for the setuid shell at /usr/local/sbin/ping6. On macOS, check ~/Library/LaunchAgents for unfamiliar plist files added in the past two weeks. Check ~/.local/share/gcm/ for the dropped daemon directory.
Rotate all credentials on any affected machine. Priority order: Git tokens and SSH keys, cloud CLI credentials in ~/.aws, ~/.gcloud, and ~/.azure, and any API keys stored in dotenv files or shell profiles. Notify your security team if the machine had access to production systems or shared secrets.
Why dormant accounts are a durable attack surface
RubyGems.org, along with npm, PyPI, and other registries, maintains a large inventory of packages associated with accounts that have had no recent authentication activity. Package registries rely on maintainer account integrity to establish trust in package contents, but they have limited mechanisms for detecting dormant account takeovers before malicious versions reach developers.
Version pinning is necessary but not sufficient as a defense. A developer who has pinned to a specific version in Gemfile.lock and subsequently runs bundle update without reviewing the changed versions is still exposed when a trojanized version is published under the same account. Monitoring package registry activity for your direct dependencies, verifying checksums against known-good values, and using private mirrors with manual approval workflows are more resilient controls.
Gigia Tsiklauri is a Security Architect and founder of Infosec.ge. Get in touch if you are building software supply chain controls and want a second opinion.