In September 2025, a phishing campaign targeted crates.io maintainers with a credential-harvesting page mimicking the registry's login flow. In mid-April 2025, the Socket research team had already disclosed a malicious crate named evm-units that had accumulated more than seven thousand downloads from a user named ablerust over eight months before takedown. By December 2025, additional Web3-targeted Rust malware (covered in The Hacker News on December 8) prompted another removal cycle. The cumulative effect through late 2025 and early 2026 was a clear shift in how the crates.io team handles malicious-package response, culminating in a February 13, 2026 Rust blog post titled "crates.io: an update to the malicious crate notification policy." This post walks through what the response workflow now looks like and what the policy change means for downstream consumers.
What did the crates.io team change in February 2026?
The February 2026 update revised the public notification cadence. Previously the crates.io team published a per-incident blog post each time a malicious crate was detected, regardless of the crate's actual reach. The new policy is that the team will no longer publish a blog post for every malicious-crate takedown, on the grounds that most notifications involved crates with no evidence of real-world usage and the per-incident posts were diluting the signal to actual consumers. The team committed instead to always publishing a RustSec advisory when a crate is removed for containing malware, which is the machine-readable feed that downstream tooling consumes anyway. The change is explicitly framed as moving from a "noisy but human-readable" model to a "less noisy but more reliable for automation" model. The headline trade-off is fewer human-targeted updates in exchange for cleaner downstream feeds.
How was the actual response coordinated during the 2025 incidents?
The response pattern documented across the Socket disclosures, the Rust Foundation security update, and the Inside Rust postmortem of the 2023 user-uploaded-malware case has stabilized into a recognizable workflow. A report arrives via the help@crates.io address or a private CVE coordination channel. The crates.io team confirms the malicious behavior, removes the crate, and locks the namespace so the same name cannot be re-registered immediately. The Rust Foundation security team (Walter Pearce, Dirkjan Ochtman from the secure code WG, and Emily Albini from the security response WG were credited in the public 2025 incidents) handles cross-org coordination if the crate's payload affects ecosystem properties beyond crates.io itself. A RustSec advisory is filed for downstream tooling, and the user account that published the crate is reviewed; if the account looks freshly created for malicious purposes it is disabled, otherwise the action is narrower. The pacing during 2025 was generally measured in hours from report to removal for clear cases, with the longer tail extending when the maliciousness was non-obvious and required Socket or other vendor analysis to confirm.
What new infrastructure has the Rust Foundation deployed?
The Rust Foundation's Alpha-Omega progress update describes two infrastructure investments shipped through 2025 and 2026. The first is crate-scanning infrastructure that scans every newly published crate for known vulnerabilities and malware signatures, reducing the time-to-detect from "when a researcher reports it" to "automated within minutes of publish." The scanning runs against RustSec, OpenSSF malicious-packages signatures, and the registry's own heuristics. The second is engineering resources for Trusted Publishing on crates.io, which shipped in July 2025 with GitHub Actions support and was extended to GitLab CI/CD in early 2026. Together these investments narrow the window during which a freshly published malicious crate is invisible to defenders and shrink the credential-theft surface that the September 2025 phishing wave exploited.
What signals can a consumer read from crates.io today?
Three signals are useful for downstream defenders. First, the RustSec advisory database (rustsec.org), which is the canonical machine-readable feed for both vulnerability and malicious-crate notifications. Second, the per-crate published_by field returned by the crates.io API, which now distinguishes between long-lived API tokens and Trusted Publishing OIDC issuance with the underlying GitHub workflow recorded for OIDC publishes. Third, the cargo-vet audit chain, which lets organizations cooperatively share trust decisions on which crate versions have been reviewed. The Rust Foundation expanded cargo-vet investment in 2025 and the resulting public audits cover a growing share of the dependency graph commonly used in production Rust services.
How do you verify a Rust dependency before pulling it?
The defender workflow combines a freshness check against RustSec, a Trusted-Publishing audit on the version metadata, and a cargo-vet audit step before resolution.
# Audit lockfile against the RustSec advisory database (incl. malicious crates)
cargo install cargo-audit
cargo audit
# Verify recent versions came in through Trusted Publishing where expected
cargo install cargo-attest
cargo attest verify \
--identity-regex "^https://github.com/upstream-org/.+" \
--crate my-critical-dep
# Apply the org's cargo-vet trust list
cargo install cargo-vet
cargo vet --locked
For organizations running their own internal crate mirror, the same RustSec feed can be wired into the mirror's quarantine pipeline so a removed crate is also pulled from the local mirror within the next sync cycle. The cargo-vet tool's vet-audits mechanism lets teams import audits from peer organizations rather than auditing every crate from scratch.
What policy gate catches the next crates.io incident going forward?
Three gates align with the policy direction the crates.io team is pushing. Gate one is "fail closed on any new RustSec advisory affecting the lockfile, including the malicious-crate class," which automates the response side of the team's February 2026 policy change. Gate two is "require Trusted Publishing for any production dependency added or upgraded after a defined cutoff," which makes the long-lived-token surface explicitly visible. Gate three is "require cargo-vet audit coverage for any crate above a usage threshold inside the org," shifting the cost-benefit so widely-used internal dependencies carry a public or peer-shared audit trail. None of these prevent a sophisticated attacker, but together they keep the response window short enough that defenders catch a wave before it reaches production.
What still has to mature?
Two gaps stand out. The first is non-GitHub CI integration. While crates.io Trusted Publishing extended to GitLab in early 2026, Jenkins and Buildkite workflows still rely on long-lived tokens for crates.io publication, and the Rust Foundation has been clear that the long-tail of CI systems will take time. The second is the inherent malicious-package problem: scanning catches signature-known malware and obvious obfuscation patterns, but adversaries adapt, and the long-tail of typosquatting-style attacks against Web3 developers persisted through 2025. The defender mindset has to be "shrink the response window, don't expect prevention to be perfect."
How Safeguard Helps
Safeguard ingests the RustSec advisory feed, the OpenSSF malicious-packages stream, and Trusted Publishing metadata for crates.io alongside the equivalent signals for npm, PyPI, RubyGems, and NuGet, into a single supply-chain policy framework. When the February 2026 policy shifted notification from blog posts to RustSec advisories, Safeguard's pipeline already consumed both, so the change was invisible to tenants. Policy gates can be configured to fail builds on any new malicious-crate advisory affecting the lockfile, require Trusted Publishing for selected critical crates, and enforce cargo-vet audit coverage thresholds. The provenance verification engine reads the crates.io API's published_by metadata to detect when a new release was published from an unexpected workflow file or repository, catching maintainer-takeover patterns that scanning alone cannot see. Postinstall and build-script auditing covers build.rs scripts the same way it covers npm postinstall hooks, so the install-time execution surface that several 2025 Rust attacks exploited is visible to your security team before the crate ever resolves.