On July 5, 2026, the RustSec Advisory Database logged RUSTSEC-2026-0202, an informational unsoundness advisory against the cxx interop crate describing a use of uninitialized memory triggered by exception-safety violations. It was the 202nd advisory the project had filed in barely six months, following three separate entries the day before covering a panic bug in bcrypt and two denial-of-service flaws in the PDF-processing crate fulgur. Taken individually, none of these advisories would make headlines. Taken together, they are a snapshot of a maintainer-run vulnerability database that has quietly become one of the more consequential sources of ground truth for anyone shipping Rust into production, and one that security teams are still under-indexed on relative to the CVE-driven databases they already watch.
RustSec is not new — the project traces back to 2017 and is maintained by contributors associated with the Rust Secure Code working group — but the character of what shows up in it has shifted noticeably over the past two years. What used to be a steady trickle of memory-safety bugs in low-level crates has broadened into a database that also tracks malicious package uploads, supply-chain typosquatting campaigns, and a growing backlog of abandoned dependencies. For teams treating cargo audit as a checkbox rather than a signal, that shift matters.
What the database actually is
The RustSec Advisory Database (rustsec/advisory-db on GitHub) is a community-curated set of TOML-and-Markdown advisory files, one per issue, organized by crate. Each entry gets a RUSTSEC-YYYY-NNNN identifier, a severity rating, and one or more category tags — memory-corruption, denial-of-service, crypto-failure, unsound, unmaintained, or (for outright malware) a "removed from crates.io" notice. The repository itself has amassed over 1,100 GitHub stars, nearly 500 forks, and more than 3,000 commits, and its data is exported in OSV format so it feeds directly into osv.dev, the GitHub Advisory Database, and the tooling most Rust developers actually run: cargo audit, cargo deny, and Dependabot. In practice, RustSec is the upstream source of truth that those downstream tools are only as good as.
That matters because Rust's much-touted memory-safety guarantees only cover code the compiler can see and reason about. The moment a crate reaches for unsafe, wraps a C library via FFI, or ships a logic bug that has nothing to do with memory at all, RustSec is often the first and only place the issue gets documented — long before it earns a CVE, if it ever does.
The pattern in 2026's advisories: soundness bugs in "safe" APIs
A recurring theme in the current wave of advisories is that the bugs aren't showing up in obviously unsafe code — they're showing up in APIs that were supposed to be safe and weren't. RUSTSEC-2026-0198, filed July 3 against the popular error-handling crate error-stack, is a clean example: the Report::frames_mut method returned an iterator yielding mutable frame references with lifetimes decoupled from the iterator itself, which let ordinary, non-unsafe application code construct two live mutable references to the same frame simultaneously — a textbook aliasing violation that Rust's borrow checker exists specifically to prevent, defeated by an API design flaw rather than a missing bound check. The fix, shipped in version 0.8.0, replaced the iterator with a closure-based visitor pattern that scopes access instead of exposing raw mutable references.
The cxx advisory two days later followed the same shape: an exception thrown across the Rust/C++ FFI boundary could leave a value uninitialized, a bug rooted in exception-safety assumptions that don't hold at language boundaries. Two fulgur advisories (RUSTSEC-2026-0200 and -0201, both rated HIGH) covered denial-of-service conditions — one from blank PDF pages, one from unbounded page slicing — that let malformed input consume unbounded resources without ever touching an unsafe block. And bcrypt's RUSTSEC-2026-0199 showed that a panic on non-ASCII hash input can take down an authentication path in production, a reminder that even crates handling security-sensitive operations like password hashing aren't immune to basic input-validation gaps.
None of these require an attacker to find a buffer overflow. They require an attacker — or an unlucky user — to hit an underspecified code path. That's a materially different risk profile than the memory-corruption CVEs that dominated Rust's early advisory history, and it's one that static memory-safety guarantees do nothing to catch.
The other trend line: malicious packages are no longer rare
RustSec's "removed from crates.io" category, once an occasional entry, has become a steady feature of 2026's advisory feed. In February 2026, three near-identical typosquats of a legitimate crate — polymarket-clients-sdk, polymarket-client-sdks, and polymarkets-client-sdk — were published in rapid succession, each attempting to steal credentials from local files under names differing from the real package by a single letter or transposition. Download counts were low (59, 33, and effectively zero, respectively, for the version caught before any installs), which suggests the campaign was caught early, but the pattern — publish, wait, catch downloads from developers who fat-fingered an import — is now a recognizable playbook rather than an anomaly.
A second, more sophisticated campaign surfaced weeks later: five packages — chrono_anchor, dnp3times, time_calibrator, time_calibrators, and time-sync — posed as innocuous time-utility crates while exfiltrating .env files and other developer secrets to attacker infrastructure. Four were yanked from crates.io within days of discovery by Socket's threat research team and documented in RustSec and the GitHub Advisory Database. The fifth, chrono_anchor, had been quietly re-obfuscated to reduce detectable indicators and remained live on the registry longer than the others — evidence that the operators behind these campaigns are iterating on evasion, not just retrying the same trick. This isn't an isolated incident either: RustSec has been tracking malicious-crate removals since at least 2022, when rustdecimal was pulled for typosquatting the widely used rust_decimal crate. What's changed is frequency and sophistication, not the existence of the threat.
Unmaintained crates are quietly piling up
A less dramatic but arguably more consequential trend is the growth of RustSec's "unmaintained" notices — advisories that don't describe a vulnerability at all, just a crate whose maintainers have stopped responding. A large cluster of these landed in December 2024 covering gtk-rs GTK bindings, and the category has continued to grow since. Unmaintained isn't synonymous with vulnerable, but it is a leading indicator: a crate with no maintainer is a crate where the next memory-safety bug, the next malicious takeover of an abandoned namespace, or the next incompatibility with a security patch upstream simply won't get fixed. Dependency graphs that include unmaintained transitive crates are accumulating exactly the kind of latent risk that doesn't show up in a CVE feed until it's too late.
Why this is a supply chain story, not just a Rust story
Rust has moved well beyond its systems-programming origins and into cloud infrastructure, browser engines, blockchain tooling, and — increasingly — components that ship inside other languages' dependency trees via FFI crates like cxx. The wasmtime WebAssembly runtime alone has accumulated advisories across multiple years, and it's exactly the kind of dependency that gets embedded deep inside plugin systems and sandboxing layers where a security team may not even know it's present. Post-quantum and modern cryptography crates covering HPKE, ML-DSA, and ChaCha20-Poly1305 have also drawn RustSec advisories recently, underscoring that even the newest, most carefully specified crypto implementations aren't exempt from implementation bugs. As Rust adoption climbs inside organizations that are still primarily Python, Go, or JavaScript shops, RustSec becomes one more advisory feed that supply chain security programs need to actively monitor rather than assume someone else is watching.
How Safeguard Helps
Safeguard ingests RustSec advisories alongside the broader OSV and NVD feeds so that new RUSTSEC-YYYY-NNNN entries — including unmaintained notices and malicious-package removals — are matched against your Rust dependency graph the moment they're published, not weeks later when a scanner happens to run. Reachability analysis then determines whether the vulnerable function in a flagged crate, like the aliased-reference pattern in error-stack or the panic path in bcrypt, is actually exercised by your call paths, cutting through the noise of transitive dependencies that carry an advisory but no real exposure. Griffin AI correlates these findings against exploitability signals and campaign patterns — including typosquat and credential-theft indicators like those seen in the Polymarket and time-utility crates — to prioritize what genuinely needs attention this week. Safeguard's SBOM generation and ingest capabilities give teams a live inventory of every crate, including deeply nested FFI dependencies like cxx and wasmtime, so unmaintained-crate risk is visible before it becomes an incident. And where a fix is available, Safeguard opens an auto-fix pull request with the patched version pinned, so remediation ships in minutes instead of sitting in a backlog.