"Each malicious release is a loader," StepSecurity said in an analysis.
What researchers found: three malicious gems and a staged supply-chain plan
Cybersecurity researchers have identified a software supply chain attack, codenamed SleeperGem, that uses three malicious RubyGems packages to target developer machines by downloading follow-on payloads. The rogue packages and the versions flagged are:
- git_credential_manager — versions 2.8.0, 2.8.1, 2.8.2, 2.8.3 (published July 18, 2026)
- Dendreo — versions 1.1.3, 1.1.4 (published October 14, 2017)
- fastlane-plugin-run_tests_firebase_testlab — version 0.3.2 (published February 06, 2018)
StepSecurity reports that each release acts as a loader: it fetches a second-stage payload from an attacker-controlled Forgejo host and behaves differently when running on CI systems versus developer machines.
How the malicious loaders operate on developer machines
According to the analysis, the loaders check for roughly 30 environment variables related to CI and build systems — including variables tied to GitHub Actions, GitLab, CircleCI, Travis, Jenkins, and Vercel — and exit if any are present. That behavior is assessed as an intentional measure to skip ephemeral CI runners and ensure execution on a developer's local environment.
When the malignant code executes on a developer machine the payloads vary by package. In the case of git_credential_manager — which StepSecurity says impersonates the official Microsoft Git Credential Manager — the gem downloads two payloads from a public Forgejo instance at git.disroot[.]org/git-ecosystem: a shell script called "deploy.sh" and a native binary bearing the same name as the tool being mimicked. On Windows, the retrieved payload is executed via PowerShell.
StepSecurity noted a progression between git_credential_manager versions: version 2.8.2 stages the payloads, while version 2.8.3 uses the install script to launch the binary as a background daemon, establish persistence with a cron entry and a systemd user service, and query sudo and wheel groups. If the user can run sudo without a password, the script re-runs itself as root and, when running as root, plants a setuid root copy of the system shell at a path intended to mimic a networking utility.
Signs of account compromise and registry abuse
Investigators highlighted several operational details that pointed to hijacked or compromised accounts rather than an original, persistent attacker project. The malicious releases were published directly to RubyGems without any matching commit or tag in the source projects. The git_credential_manager package was added as a dependency to five packages — Dendreo, fastlane-plugin-run_tests_firebase_testlab, slackHtmlToMarkdown, seo_optimizer, and array_fast_methods — enabling the malicious payloads to propagate to existing users of those packages.
Most of those dependent packages are maintained by the same account ("LR-DEV"), while git_credential_manager belongs to a different maintainer ("pinkroom"). StepSecurity interprets that mismatch as evidence that more than one account was likely compromised to push the rogue versions to RubyGems.
RubyGems as a "dead drop" and recent registry abuse
SleeperGem arrives amid a string of recent RubyGems incidents. The disclosure follows a period when RubyGems briefly paused account sign-ups after bad actors pushed dozens of malicious packages as part of a coordinated spam-publishing campaign. Socket researchers also reported a parallel campaign that flooded the registry with 150 gems used as a data exfiltration channel.
Earlier this month Mend.io disclosed an undocumented supply-chain attack that used 14 RubyGems packages to store stolen credential data. In that campaign, a malicious browser extension harvested credentials through a locally accessible API, packaged the information into valid .gem files entirely in the browser using JavaScript and standard Web APIs, and uploaded those packages directly to RubyGems.org using a hard-coded RubyGems API key. Maciej Mensfeld described the haul as including "plaintext passwords, SSH private keys, AWS credentials, crypto wallet seed phrases, Social Security numbers, credit card numbers, and bank account details across 63 vault items," and observed that "RubyGems wasn't the delivery mechanism here. It was the dead drop."
What this means for developers, maintainers, and security teams
- Developers: If you installed any of the listed gems, treat the machine and associated secrets as compromised. StepSecurity recommends removing the dropped daemon at ~/.local/share/gcm/, erasing persistence methods, checking for a setuid shell at /usr/local/sbin/ping6, and rotating all credentials.
- Maintainers and repository owners: Dormant or long-quiet accounts are attractive takeover targets. Aikido Security researcher Charlie Eriksen noted that "a RubyGems account that has gone quiet for six or seven years doesn't look risky to anyone" and called this the origin of the SleeperGem name: hijacking ordinary, dormant accounts that appear harmless.
- Security teams and incident responders: The loader behavior — skipping CI, staging payloads, and then moving to persistent native daemons — signals an attacker focus on developer workstations and credential harvests. Responders should check for the specified files and persistence mechanisms and rotate any secrets that may have been exposed.
The SleeperGem activity combines account hijacking, registry trust, and staged native payloads to target the place where software gets built: developer machines. The specific artifacts — the Forgejo host at git.disroot[.]org/git-ecosystem, the git_credential_manager versions and behavior differences between 2.8.2 and 2.8.3, and the persistence footprints — give defenders concrete checks to run today. At the same time, recent, related campaigns that turned RubyGems into a "dead drop" for stolen credentials underscore that trusted package registries can be repurposed as covert storage if account controls and upload vetting are insufficient.
https://thehackernews.com/2026/07/sleepergem-uses-three-malicious.html
