Loading story…
RubyGems has introduced an opt-in cooldown feature in RubyGems 4.0.13 and Bundler 4.0.13 that delays installation of newly published gem versions to reduce exposure to malicious releases. The control lets developers require a gem version to be public for a configurable number of days before Bundler will resolve it, using per-version created_at timestamps from RubyGems.org’s v2 compact index. The feature is disabled by default, can be bypassed with:
bundle install --cooldown 0
The release comes as software supply-chain defenders respond to fast-moving package compromises, including a backdoored @cap-js/openapi 1.4.1 package on npm. Guidance for affected environments says any host with that version in its dependency graph should be treated as untrusted, upgraded to 1.4.2 or later, and followed by recycling developer sessions, execution nodes, and CI/CD containers, plus rotating exposed secrets such as AWS keys, GitHub tokens, database credentials, and npm tokens. RubyGems said the cooldown mechanism complements broader ecosystem protections including mandatory 2FA, trusted publishing, compromised-password checks, push-time validation, and AI-assisted vulnerability scanning.
Trace attribution and downstream blast radius.
2 events from the most recent confirmed update back to the earliest known activity.
A remediation notice stated that npm package @cap-js/openapi version 1.4.1 contained backdoored code and directed organizations to upgrade to version 1.4.2 or later. The notice also advised treating affected hosts as untrusted and rotating sensitive credentials.
On the RubyGems blog, the project announced a new opt-in Bundler cooldown feature that delays installation of newly published gem versions so they can be vetted before use.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See attribution and downstream blast radius, and whether this package or vendor reaches your builds.
3 references tracked. Mallory keeps watching after this page renders.
socket.dev
Open sourcecvereports.com
Open sourceblog.rubygems.org
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
GitHub has changed Dependabot to wait three days before opening pull requests for non-security version updates, aiming to keep fast-moving malicious package releases out of automated developer workflows. The company said the change was driven by repeated software supply-chain incidents in which poisoned npm releases were detected and removed within hours, but still had enough time to be pulled into builds. GitHub pointed to a 2025 npm compromise in which an attacker phished a maintainer and published malicious versions of widely used packages including **`chalk`** and **`debug`**, with code that rewrote cryptocurrency wallet addresses before the packages were taken down roughly two hours later. Security updates tied to known advisories are not delayed and will still be issued immediately. The move aligns with broader industry guidance that the first hours after a package is published are the highest-risk period for dependency consumers. Research cited similar attacks affecting 18 npm packages with more than 2.6 billion weekly downloads and the **Nx** build attack, which remained live for about four hours, reinforcing recommendations to delay automated updates by 24 to 48 hours or longer. GitHub said the npm ecosystem logged more than 6,500 malware advisories in the year ending May 2026 and urged teams to combine cooldowns with other controls, including lockfiles, careful review before merge, scoped CI tokens, disabling install scripts where possible, and pinning dependency versions to reduce supply-chain exposure.
Jul 29, 2026
Organizations are adopting **dependency cooldowns** to prevent build systems from automatically selecting newly published package versions during a defined waiting period. Semgrep deployed a one-week cooldown across Python projects using `uv`, causing resolution to choose older eligible releases while registries and the community have time to identify and remove malicious packages. Its rollout required an updated `uv` version, exemptions for internal or urgently needed packages and registries without reliable publication timestamps, and lockfile validation. The control addresses supply-chain campaigns in which compromised maintainer credentials and trusted release pipelines distribute malicious updates, including reported Shai-Hulud-related npm activity. Renovate provides a comparable `minimumReleaseAge` policy for dependency-update workflows; updates remain pending until they meet the age threshold, while security updates bypass the delay. Effective deployment depends on strict handling of missing release timestamps, immutable dependency pinning, curated registries, short-lived OIDC credentials, restricted CI/CD runner egress, and hardened GitHub Actions workflows so a compromised update or pull request cannot seize build credentials.
Aug 31, 2026
A coordinated RubyGems supply-chain attack dubbed **SleeperGem** used malicious releases of `git_credential_manager`, `Dendreo`, and `fastlane-plugin-run_tests_firebase_testlab` to target developer workstations. Researchers reported that the attacker appears to have hijacked long-dormant maintainer accounts and pushed trojanized gem versions, including `git_credential_manager` `2.8.0` through `2.8.3`, with code that executed on library load, fetched additional payloads from a fake-looking Git ecosystem repository on `git.disroot.org`, and deliberately avoided running in CI environments to reduce detection. On developer machines, the gems reportedly acted as loaders for a second stage that installed a native daemon, established persistence through **systemd** and **cron**, and attempted privilege escalation via passwordless `sudo` to place a setuid root shell at `/usr/local/sbin/ping6`. Investigators said the malicious releases did not match legitimate source tags and that some affected packages had been inactive for years before suddenly publishing updates, indicating account compromise rather than normal maintenance. Security firms warned that any system that installed or required the affected gems should be treated as fully compromised and that all accessible credentials and secrets should be rotated.
Jul 26, 2026