Rust 1.100 Adds Cargo Cooldowns to Blunt Malicious Crate Attacks
Rust 1.100, scheduled for 12 November 2026, gives Cargo an optional "cooldown": a minimum age a newly published crate version must reach before your builds will resolve to it. It's a simple idea that goes after one of the most dependable supply-chain attack patterns: publish a poisoned release, then let automated updates spread it before anyone notices.
What happened
The feature follows an August incident on crates.io. Socket's researchers documented a malicious crate, proc-macro1, whose build script downloaded a payload during compilation. Attackers pushed releases of three otherwise-legitimate crates, arrayref, internment and append-only-vec, that pulled in the harmful dependency.
The bad releases were only live for 86, 90 and 107 minutes before removal. That was still enough time to matter: CI pipelines and developer machines running automated updates could have fetched and built them before defenders responded. Because Cargo runs build scripts at compile time, just building the affected library was enough to execute attacker code, and the application's own source didn't change at all.
The Rust project had been working on dependency cooldowns before the attack. The tracking issue opened on 18 May, nightly Cargo gained support on 21 June, and stabilization merged on 28 August. The feature is in beta now and ships in the 1.100 stable release.
How the cooldown works
- Enable it in
.cargo/config.tomlunder[registry], for exampleglobal-min-publish-age = "7 days". Periods can be given in seconds, minutes, hours, days, weeks or months. - When resolving, Cargo skips versions younger than the threshold and picks an older version that still satisfies your requirements. If no version qualifies, resolution fails instead of quietly taking a fresh release.
incompatible-publish-agedefaults to"deny", so you don't need a separate resolver setting.- Cargo reports skipped releases and their ages so blocked updates are easy to understand.
- When you have to pull an urgent fix early, you can bypass the cooldown for a single package:
CARGO_RESOLVER_INCOMPATIBLE_PUBLISH_AGE=allow cargo update -p <crate> --precise <version>.
Why it matters, and where it stops
The default waiting period is zero. Upgrading to Rust 1.100 changes nothing until a team sets a minimum age. A few limits are worth knowing:
- Versions already recorded in
Cargo.lockstay put even if they're younger than the threshold. A cooldown won't evict a malicious release you've already locked in. - It doesn't cover
cargo install, git dependencies, local paths or registries that don't publish timestamps. - An age gate doesn't inspect code or prove that a crate is safe. Malware that evades detection for longer than your window still gets through. The approach is similar to the cooldown option in GitHub's Dependabot, but it enforces the policy in the resolver itself instead of relying on the update bot.
- Socket also flagged a September campaign aimed at Rust maintainers, using fake job and project offers and video calls to get targets to install software or run commands. Cooldowns don't help when the attacker takes over a trusted publisher's account.
What to do
- Turn it on once you're on 1.100. A 3–7 day
global-min-publish-ageis a reasonable starting point for most teams. Use a shorter window if you need to patch quickly. - Audit your lockfile against the known-bad releases of
proc-macro1,arrayref,internmentandappend-only-vecfrom the August incident. - Make the bypass a reviewed exception. Log every
CARGO_RESOLVER_INCOMPATIBLE_PUBLISH_AGE=allowoverride and require a second pair of eyes. - Close the gaps by hand. Pin git dependencies to commits, and treat
cargo installin CI as untrusted. - Harden maintainer accounts. Use MFA on crates.io and GitHub, scope publish tokens tightly, and train maintainers on recruitment-themed lures.
A cooldown buys you time, and that time only helps if something is reviewing your dependencies while you wait. That's the job of our AI-assisted code review service: it looks through your manifests, lockfiles and build scripts for risky or newly compromised dependencies, so a poisoned crate is caught before it reaches production.
Originally reported by Cyber Security News (Tushar Subhra Dutta, 21 October 2026). This article is 4Tify's summary and analysis.
