SleeperGem abused three malicious RubyGems packages that delivered second-stage payloads through an attacker-controlled Forgejo host targeting developer workstations.
The malware checks for CI/CD environment variables, exits when they are detected, and instead executes on developer workstations.
Once executed, it downloads additional payloads, establishes persistence, probes privileged groups, and attempts root-level persistence when conditions allow.
Organizations should investigate affected endpoints, remove persistence, rotate exposed secrets, and strengthen developer endpoint security against supply chain attacks.
A newly discovered RubyGems malware campaign, dubbed SleeperGem, demonstrates how attackers can target developer workstations by deliberately avoiding CI/CD environments.
Researchers found three malicious RubyGems packages that skip execution in CI/CD environments and instead run on developer workstations, where source code, package registry tokens, SSH keys, and cloud credentials are commonly stored.
The campaign demonstrates that developer endpoint security is becoming just as important as securing the software delivery pipeline.
SleeperGem skips execution in CI environments and instead runs on developer workstations. According to StepSecurity, the malicious packages check for environment variables associated with GitHub Actions, GitLab CI, Jenkins, CircleCI, Travis CI, Vercel, and other build systems. If detected, the malware exits.
Developer systems often have access to source code, repositories, deployment environments, and enterprise resources. Although public reporting has not confirmed credential theft, StepSecurity recommends treating affected systems and accessible secrets as potentially compromised.
Top 10 Cybersecurity Challenges for Enterprises
Explore enterprise cybersecurity challenges and practical strategies to reduce security risks effectively.
Why CI security alone isn’t enough
SleeperGem skips execution in CI/CD environments, reducing the effectiveness of security controls focused solely on build pipelines. Instead, it executes on developer workstations, where source code, package registry tokens, deployment tools, SSH keys, and cloud credentials are often available.
This highlights the need to extend developer endpoint security beyond CI/CD infrastructure. Monitoring developer workstations alongside build systems provides broader visibility into software supply chain attacks that evade automated build pipelines.
According to StepSecurity, each package acts as a loader that retrieves a second-stage payload from an attacker-controlled Forgejo host. On Unix systems, the payload executes through /bin/sh.
Once active, the malware downloads additional scripts and binaries, installs persistence through cron jobs and systemd user services, checks membership in privileged groups, and attempts root-level persistence when passwordless sudo is available.
Attack Stage
Observed Behavior
Operational Impact
Package installation
Malicious RubyGem executes loader
Initiates malicious code execution on a developer workstation
Environment checks
Skips execution in CI/CD environments
Focuses on developer workstations
Second stage
Retrieves payloads from an attacker-controlled Forgejo host
Enables execution of second-stage payloads
Persistence
Creates cron jobs and systemd user services
Maintains persistence across sessions
Privilege checks
Checks privileged groups and passwordless sudo
Increases risk on misconfigured systems
StepSecurity also found that Dendreo and fastlane-plugin-run_tests_firebase_testlab published malicious releases after years of dormancy, increasing the likelihood that existing users would trust the updates.
This tactic demonstrates how attackers can exploit established package reputations as part of a software supply chain attack.
What security teams should verify
Organizations should identify whether affected package versions were installed on developer systems and check for persistence artifacts.
StepSecurity recommends treating affected machines as compromised, removing the dropped daemon and persistence mechanisms, checking for the setuid shell at /usr/local/sbin/ping6, and rotating credentials or secrets accessible from those devices.
Security teams should also:
Review newly published versions of dormant packages before deployment.
Validate package releases against upstream source repositories.
Maintain approved software baselines for developer endpoints.
SleeperGem reinforces the need to treat developer workstations as critical enterprise assets. While package validation and dependency management remain essential, endpoint management and visibility add another layer of defense.
The RubyGems malware campaign demonstrates how software supply chain attacks can target developer endpoints instead of build infrastructure alone. By avoiding CI environments and executing on developer workstations, SleeperGem shifts attention to systems that often provide privileged access across the enterprise.
Organizations should extend software supply chain defenses beyond dependency scanning by securing developer devices, investigating unexpected package activity, and responding quickly when compromised packages are identified.
Strengthen Your Developer Endpoint Security
Start your free Hexnode trial to improve endpoint visibility and compliance.
A storyteller for practical people. Breaks down complicated topics into steps, trade-offs, and clear next actions—without the buzzword fog. Known to replace fluff with facts, sharpen the message, and keep things readable—politely.
