Three malicious RubyGems packages published in July 2026 evaded CI detection by targeting developer laptops directly, researchers say.
Security researchers at Aikido Security identified and named the campaign SleeperGem after tracing malicious releases of three RubyGems packages pushed to the public registry between July 18 and July 19, 2026.
StepSecurity subsequently ran each compromised version inside its Harden-Runner monitoring tool to reconstruct the attack chain, and the findings give DevSecOps teams a working case study in a problem most pipeline security tooling still handles poorly: malware built to recognise a CI environment and switch itself off.
The three packages involved are git_credential_manager, which impersonates the official Microsoft Git Credential Manager tool, alongside Dendreo and fastlane-plugin-run_tests_firebase_testlab. Two of the three had gone dormant for years, one since 2020, before shipping new versions within minutes of each other on RubyGems.org.
None of the new versions had a matching commit or tag in the corresponding source repository on GitHub, which is itself a detection signal any organisation tracking dependency provenance should be watching for.
A sandbox capture, not a confirmed field breach
What StepSecurity captured is a detonation inside a controlled GitHub Actions environment with CI environment variables deliberately stripped out so the malware would believe it was running on a developer machine. That’s a synthetic reconstruction of the kill chain, not a forensic report from an actual compromised laptop.
The behaviour StepSecurity observed is likely representative of what happens on real developer hardware, given the malware’s own logic is built around that assumption, but no organisation should treat a sandboxed replay as equivalent to incident response data pulled from an infected endpoint.
Real developer machines carry variables a lab environment doesn’t: partial patch levels, existing sudo configurations, browser-stored credentials, and SSH keys already loaded into agents. Those conditions change what the daemon can reach and what it can escalate into, and none of that gets tested by running a gem inside a hardened runner.
The loader’s first move – before executing any payload logic – is to check for around thirty environment variables that CI platforms set by default, including GITHUB_ACTIONS, GITLAB_CI, and CIRCLECI. If any are present, the process exits without doing anything further.
That check is the reason a routine pipeline install of these gems shows nothing suspicious. CI runners are ephemeral, monitored, and low value to an attacker chasing persistent access; developer laptops hold long-lived credentials, cloud tokens, and SSH keys that survive across sessions. The design choice tells you where the actual exposure sits, and it isn’t in the build system most security teams instrument first.
The loader, the daemon, and the path to root
For git_credential_manager version 2.8.2 and later, malicious code executes the moment the gem is required, not only at install time. The require call spawns a child Ruby process running a bundled install script, which reaches out to an attacker-controlled Forgejo instance and pulls down a shell script and a native binary carrying the same name as the tool it’s impersonating. The connection strips certificate verification and sets its User-Agent to the single word “Git,” a detail clearly aimed at blending into normal developer network traffic rather than tripping obvious alerts.
Comparing the two final versions shows the attackers iterating in the open. Version 2.8.2 downloads the payload but leaves the line that actually executes it commented out, staging the attack without triggering it. Version 2.8.3 removes that safeguard. On execution, the install script drops the downloaded binary into a hidden directory under the user’s home folder, marks it executable, and launches it as a background daemon.
Persistence gets installed twice, through a systemd user service and a cron entry, both labelled with the innocuous name git-credential-manager so removing one method leaves the other running. The script then checks whether the user belongs to the sudo or wheel groups; if passwordless sudo is available, it re-executes as root and plants a setuid copy of the system shell at a path made to resemble a networking utility.
On StepSecurity’s runner, passwordless sudo wasn’t configured – so that branch stopped after the group check – but the code path is present and functional in the release. Any developer machine configured with passwordless sudo, a common convenience setting on individual workstations, would proceed straight through it.
What Harden-Runner actually recorded
The process tree Harden-Runner captured shows the full sequence in order: the require call spawning the child install process, the download and execution of deploy.sh, the binary copy into a directory under ~/.local/share/gcm/, the daemon launch, the systemd and cron installation, and the group check against sudo.
That level of process visibility is what separates this from a static code review, which would flag suspicious patterns without confirming execution.
Network logs showed the runtime job’s Ruby process reaching git.disroot.org, the Forgejo host serving the payload, and StepSecurity notes the fastlane plugin gem contacted the same host, tying the three packages to one operation rather than three separate incidents. The daemon’s own outbound behaviour, including any credential exfiltration, sits outside what a gem-level sandbox test can observe and would require separate binary analysis to confirm.
Dependency scanning built around CI pipeline hooks catches malware that behaves the same way in a runner as it does on a workstation. SleeperGem doesn’t behave that way, and neither will the next campaign that copies its approach once the technique proves out. That leaves developer machines as the exposure surface security teams have historically instrumented least, given how much attention has gone into pipeline hardening over endpoint file monitoring.
See also: White House launches AI clearinghouse for vulnerability patching
Want to learn more about cybersecurity from industry leaders? Check out Cyber Security & Cloud Expo taking place in Amsterdam, California, and London. The comprehensive event is part of TechEx and is co-located with other leading technology events including the AI & Big Data Expo. Click here for more information.
Developer is powered by TechForge Media. Explore other upcoming enterprise technology events and webinars here.
