A sophisticated software supply chain attack has compromised multiple RubyGems packages, quietly targeting developers rather than automated build systems.

Security researchers at StepSecurity have uncovered what they call SleeperGem, a coordinated campaign that weaponized seemingly legitimate Ruby packages to install a persistent backdoor capable of surviving reboots, maintaining long-term access, and potentially escalating privileges on infected systems.

Unlike many supply chain attacks that focus on CI/CD infrastructure, SleeperGem was deliberately engineered to avoid detection inside build pipelines. Instead, it activates on developers’ laptops—the very systems where source code, credentials, cloud tokens, SSH keys, and intellectual property reside.

The discovery highlights a worrying evolution in software supply chain threats, where attackers increasingly understand modern DevOps workflows and design malware specifically to evade conventional security monitoring.

What Happened?

Between July 18 and July 19, 2026, malicious versions of three RubyGems packages were uploaded to RubyGems.org.

The compromised packages include:

Researchers determined the releases were not associated with legitimate source code repositories, as no corresponding Git tags or commits existed.

Even more suspicious, two of the projects had remained inactive for several years before suddenly publishing new releases within minutes of one another a classic indicator of a coordinated software supply chain compromise.

How SleeperGem Works

Rather than embedding a large malware payload inside the Ruby package itself, the attackers designed each gem as a lightweight loader.

Once imported into an application, the package silently launches a second-stage attack.

The infection chain unfolds in several stages:

1. Detect whether it is running inside a CI/CD platform.
2. Exit immediately if GitHub Actions, GitLab CI, CircleCI or similar environments are detected.
3. If running on a developer workstation, contact an attacker-controlled Forgejo server.
4. Download a shell installer and native binary.
5. Install a hidden daemon.
6. Configure persistence using both systemd and cron.
7. Attempt privilege escalation if passwordless sudo is available.

The malware therefore remains largely invisible during automated testing while fully compromising developer endpoints.

This design significantly increases the likelihood that malicious packages pass unnoticed through software development pipelines.

Why Developer Machines Were Chosen

Traditional supply chain attacks often compromise CI environments because they provide access to production infrastructure.

SleeperGem takes the opposite approach.

Developers’ laptops frequently contain:

• SSH private keys
• GitHub access tokens
• Cloud credentials
• API secrets
• VPN certificates
• Browser session cookies
• Production configuration files

By avoiding CI runners – which are temporary and heavily monitored – the attackers gain access to richer targets with a much longer persistence window.

A Carefully Engineered Attack

StepSecurity’s runtime analysis revealed several sophisticated techniques.

The malware:

• disables SSL certificate verification
• disguises outbound traffic using the User-Agent “Git”
• downloads payloads only when required
• launches background daemons
• installs redundant persistence mechanisms
• attempts privilege escalation
• hides under legitimate-looking filenames

One notable finding was the evolution between versions.

Version 2.8.2 downloaded the payload but never executed it.

Version 2.8.3 activated the complete infection chain, suggesting the attackers were testing deployment before fully weaponizing the package.

Persistence Designed to Survive Cleanup

After installation, the malware copies itself into:

~/.local/share/gcm/git-credential-manager

It then creates:

• a systemd user service
• a cron job
• configuration files
• a hidden daemon

If elevated privileges are obtained, it may also plant a setuid root shell disguised as a networking utility, allowing future root access.

Multiple persistence mechanisms ensure that removing only one artifact does not eliminate the infection.

Indicators of Compromise (IoCs)

Organizations should immediately investigate systems showing any of the following:

Compromised Packages

• git_credential_manager 2.8.0–2.8.3
• Dendreo 1.1.3–1.1.4
• fastlane-plugin-run_tests_firebase_testlab 0.3.2

Suspicious Files

• ~/.local/share/gcm/git-credential-manager
• ~/.local/share/gcm/.env

Persistence

• systemd service named git-credential-manager
• cron entry launching the daemon

Network Activity

Outbound HTTPS connections to:

git.disroot.org

especially with:

• disabled certificate validation
• User-Agent: Git

Why This Matters

SleeperGem demonstrates that attackers increasingly understand developer workflows.

Rather than attacking production infrastructure directly, adversaries are compromising the software creators themselves.

This strategy offers several advantages:

• easier credential theft
• access to source code
• persistence for weeks or months
• lateral movement into cloud environments
• opportunity to poison future software releases

The campaign also reinforces a growing cybersecurity reality:

Open-source package ecosystems remain one of the largest attack surfaces in modern software development.

Expert Perspective

Although StepSecurity’s investigation focused on technical behavior, the broader implications extend well beyond Ruby developers.

The attack mirrors trends seen in npm, PyPI, Maven and other package repositories, where attackers increasingly exploit developer trust rather than software vulnerabilities.

Runtime analysis also proved critical.

Static code inspection alone would not have revealed the full execution chain, highlighting the growing importance of behavioral monitoring during software development.

10 Security Recommendations for Organizations

Security teams should consider the following actions immediately:

1. Audit Ruby Dependencies

Search every repository for affected package versions and remove them immediately.

2. Rotate All Developer Credentials

Treat compromised developer systems as fully exposed.

Rotate:

• SSH keys
• GitHub tokens
• cloud credentials
• API keys
• VPN certificates

3. Hunt for Persistence

Inspect:

• systemd services
• cron jobs
• hidden user directories

particularly under:

~/.local/share/gcm/

4. Review Network Logs

Search historical traffic for outbound connections to the identified command-and-control infrastructure.

5. Implement Runtime Monitoring

Behavioral detection identifies malicious execution that static scanners may miss.

Organizations should complement dependency scanning with runtime protection.

For organizations seeking advanced endpoint detection, threat hunting, and runtime monitoring, consider implementing enterprise-grade Endpoint Detection and Response (EDR) and Managed Detection and Response (MDR) capabilities through Saintynet Cybersecurity.

6. Strengthen Dependency Governance

Maintain an approved software package inventory and restrict unverified dependencies.

Regular Software Supply Chain Security assessments should be integrated into secure development programs delivered by Saintynet Cybersecurity.

7. Enforce Least Privilege

Developers should never routinely have passwordless sudo access.

8. Continuously Monitor Developer Endpoints

Developer laptops deserve the same security monitoring as production servers.

9. Educate Developers

Developers remain the first line of defense.

Regular Secure Software Development, Secure Coding, and Cybersecurity Awareness Training can significantly reduce supply chain risks. Organizations can strengthen developer resilience through specialized training programs offered by Saintynet Cybersecurity.

10. Adopt Zero Trust for Development Environments

Never assume developer devices are trustworthy.

Continuously verify:

• identities
• devices
• applications
• software dependencies

Global Implications

SleeperGem is not limited to any region.

Organizations worldwide using Ruby, Fastlane, or open-source development workflows may be affected.

Technology companies, fintech firms, SaaS providers, government software teams, startups, and enterprises all rely heavily on open-source ecosystems.

As software supply chains continue to expand, attacks like SleeperGem reinforce the urgent need for stronger dependency validation, continuous monitoring, and secure software development practices across every industry.

For readers interested in broader software supply chain security trends, CyberCory recommends exploring previous coverage on software supply chain attacks, dependency confusion, CI/CD security, and open-source ecosystem threats available on CyberCory.com.

Conclusion

SleeperGem marks another significant milestone in the evolution of software supply chain attacks.

Instead of targeting servers or CI pipelines, the attackers focused on developers the individuals who possess the credentials, access, and trust required to compromise entire software ecosystems.

The campaign also demonstrates how modern malware increasingly blends stealth, persistence, and operational security to remain undetected.

For organizations, the lesson is clear: protecting software supply chains now extends far beyond vulnerability scanning. Continuous runtime monitoring, secure development practices, developer awareness, and proactive endpoint protection are becoming essential components of modern cybersecurity strategies.