The SleeperGem campaign highlights how software supply-chain attacks are becoming more patient, selective, and developer-focused.

Researchers found malicious RubyGems packages published under the names git_credential_manager, Dendreo, and fastlane-plugin-run_tests_firebase_testlab. These were not random throwaway packages with obvious suspicious names. They were designed to look useful, familiar, or connected to existing developer workflows.

That is what makes this type of attack dangerous. Developers trust package managers because they are part of normal work. Installing a gem, updating a dependency, or requiring a library inside a project feels routine. Attackers are abusing exactly that routine trust.

The malicious packages acted as loaders. Instead of containing all malicious functionality directly, they downloaded a second-stage payload from an attacker-controlled Forgejo host. This makes detection harder because the package itself may appear smaller, cleaner, or less obviously malicious during static review.

SleeperGem also showed deliberate evasion. The malware checked whether it was running in a continuous integration environment and skipped execution if it detected CI variables. This means a normal build pipeline might not show malicious behavior, while the same package could activate on a developer’s laptop.

That detail is important. Many organizations focus heavily on CI/CD security while underestimating developer workstations. But developer machines often contain the most valuable secrets: Git credentials, SSH keys, cloud tokens, API keys, package registry tokens, environment files, browser sessions, VPN access, and access to private repositories.

Once the second-stage payload runs on a developer machine, it can install a background daemon, create persistence using systemd and cron, and attempt privilege escalation. In some cases, the malware included a path to plant a setuid root shell if it gained sufficient privileges.

This turns a simple dependency installation into a long-term foothold. The attacker is not only trying to run once and disappear. The goal is persistence, credential theft, and continued access.

For software teams, the biggest risk is downstream compromise. If attackers steal developer credentials, they may access private repositories, publish malicious package updates, tamper with source code, modify CI/CD workflows, steal customer data, access cloud infrastructure, or move into production environments.

Organizations should immediately check whether any of the affected RubyGems versions were installed or referenced in projects, lockfiles, developer machines, or automation environments. Any system that installed or required these packages should be treated as potentially compromised.

Cleanup should include removing the malicious gems, deleting dropped payload directories, checking for suspicious systemd user services, reviewing cron entries, and inspecting for unexpected setuid binaries. But cleanup alone is not enough.

Secrets reachable from affected machines should be rotated. This includes SSH keys, Git tokens, cloud credentials, package registry tokens, API keys, environment variables, browser-stored secrets, and credentials used by developer tools. Removing the malware while leaving stolen credentials active is basically changing the curtains after the burglar copied the house keys.

Security teams should review network logs for outbound connections to unexpected code-hosting or Forgejo infrastructure, especially connections that do not match normal developer workflows. They should also monitor for Ruby processes spawning shell scripts, background daemons created under user directories, and suspicious activity involving Git credential tools.

The campaign also shows why dependency verification matters. Teams should compare registry releases with source repository tags, review sudden updates to dormant packages, and investigate packages that publish new versions without matching commits or release history. A project that has been quiet for years and suddenly releases new versions should not be accepted blindly.

Development environments should use least privilege. Developers should not routinely run package installations with unnecessary administrative privileges. Passwordless sudo should be restricted, and developer laptops should be monitored like real production-adjacent assets, not treated as personal playgrounds with corporate stickers.

CI/CD controls are still important, but they are not enough. SleeperGem deliberately avoided CI environments, which means organizations need visibility on developer endpoints as well. Endpoint monitoring, egress controls, package behavior analysis, and suspicious file detection should extend to developer workstations.

Organizations should also improve dependency intake processes. Package pinning, lockfile review, internal mirrors, approved package registries, software composition analysis, and behavior-based sandboxing can reduce the chance of unknown packages reaching developers directly.

The key lesson is that software supply-chain attacks no longer need to compromise the final product immediately. They can compromise the people and machines that build the product first.

SleeperGem is a reminder that developer environments are part of the production security boundary. A malicious gem installed on one laptop can become stolen credentials, poisoned repositories, compromised builds, and wider infrastructure access.

Package managers are useful, but they are not trust engines. Every dependency is code from someone else running inside your environment. Treating that as harmless convenience is how attackers turn normal development workflows into quiet compromise channels.

Cybersecurity researchers have flagged a new software supply chain attack codenamed SleeperGem targeting the Ruby ecosystem after three malicious gems were published to RubyGems with the end goal of serving additional payloads. The rogue gems are listed below - git_credential_manager (versions 2.8.0, 2.8.1, 2.8.2, 2.8.3) - Published on July 18, 2026 Dendreo (versions 1.1.3, 1.1.4) -

Source: SleeperGem Uses Three Malicious RubyGems Packages to Target Developer Machines via The Hacker News — published 20 Jul 2026.