SleeperGem: The RubyGems Attack That Skips CI and Goes for Developer Laptops

If you or your team pulled git_credential_manager, Dendreo, or fastlane-plugin-run_tests_firebase_testlab between July 18 and 19, 2026, stop and check your dependency lock files now. A campaign researchers are calling SleeperGem pushed malicious versions of all three through a hijacked RubyGems maintainer account, and the payload is specifically built to avoid detonating in CI, which means the usual “our pipeline would have caught it” assumption doesn’t hold here.

What actually happened

An attacker gained control of a RubyGems account that had been dormant for six or seven years. Not a fresh, suspicious account, not a typosquat of a popular gem, an ordinary maintainer identity that had simply gone quiet long enough to look harmless. Between July 18 and 19, 2026, that account pushed new, malicious releases of three packages: git_credential_manager, Dendreo, and fastlane-plugin-run_tests_firebase_testlab.

The third one is where the exposure gets real. It’s a plugin for fastlane, the release automation tool a large share of iOS and Android teams use to ship builds, and it has more than 574,000 downloads across its history. A dormant account taking over an obscure gem is a minor incident. A dormant account taking over a plugin that sits in mobile CI configs across the industry is a different kind of problem, even if only a fraction of historical installs pulled the poisoned version.

The part that should change how you think about this

Most supply chain malware tries to run everywhere, as fast as possible, before anyone notices. SleeperGem does the opposite on purpose. It checks the environment for variables associated with CI/CD platforms, GitHub Actions and GitLab CI specifically, and if it finds them, it stays dormant. No payload, no persistence, nothing for a build log to flag.

That’s a deliberate targeting decision, not a technical limitation. CI runners are short-lived, heavily logged, and usually destroyed right after a job completes: a bad place to set up shop and a good place to get caught fast. A developer’s own laptop is the opposite on every axis. It stays powered on for weeks, it holds SSH keys and cloud credentials, it has direct access to private repositories, and almost nobody is watching its process list the way a security team watches CI logs. SleeperGem skips the environment most teams have actually instrumented and lands in the one most teams haven’t.

Once it confirms it’s on a real developer machine, it installs a native daemon and sets up persistence through cron jobs and systemd services, the standard playbook for staying resident across reboots while it waits for further instructions or drops additional payloads.

Why “we scan in CI” isn’t enough anymore

A lot of dependency security programs are built around exactly one checkpoint: the CI pipeline. SBOM generation, npm audit or bundle audit runs, image scanning, all of it typically fires when code hits a build server. That’s necessary, but SleeperGem is a direct demonstration that it isn’t sufficient. If the malware is specifically engineered to stay quiet where your scanning already happens, your CI-only posture has a blind spot exactly where this attack lives.

The practical fix isn’t exotic: it’s extending the same discipline you apply in CI to local developer environments. Lock files pinned and reviewed, not just trusted by default. Package installs on laptops going through the same registry-verification checks as a pipeline would apply. And treating “dormant maintainer account suddenly pushes a release” as a signal worth watching for, since that pattern, not a brand-new suspicious package name, is what both SleeperGem and the May 2026 RubyGems and Go module campaign have in common.

Detail	Value
Campaign name	SleeperGem
Affected gems	git_credential_manager, Dendreo, fastlane-plugin-run_tests_firebase_testlab
Malicious releases published	July 18-19, 2026
Attack vector	Hijacked maintainer account, dormant 6-7 years
Evasion technique	Checks for CI/CD environment variables, stays dormant if found
Persistence	Native daemon via cron jobs and systemd services
Largest affected package’s download count	574,661+ (fastlane-plugin-run_tests_firebase_testlab)

What to do this week

1. Diff your Gemfile.lock against known-good hashes for the three named gems if your team uses any of them, and check whether any developer machine installed or updated one between July 18 and 19.
2. Treat any match as a developer-machine incident, not a CI incident. Look for unfamiliar cron entries, unrecognized systemd services, and daemon processes that don’t map to anything your team installed intentionally.
3. Rotate credentials that lived on any machine that pulled the compromised version, including SSH keys and any cloud or registry tokens, since persistence-focused malware on a dev laptop is usually there to harvest exactly those.
4. Extend scanning past the pipeline. If your dependency and supply chain review process only runs at CI time, this is the incident that justifies pushing some of that discipline onto local developer setups too, not just build servers.

This is the same broader pattern we’ve been tracking across the ecosystem all year: attackers increasingly go after the account, not the code, because a legitimate maintainer identity with years of history is far more trustworthy-looking than any typosquat could ever be. Reviewing who actually holds publish access to your critical dependencies, and how long it’s been since they last used it, is a cheap check against exactly this kind of takeover.