Audit Rust Dependencies for CVEs with cargo audit (2026)

cargo audit is your best friend for finding and fixing security vulnerabilities in your Rust projects, but it’s not magic. It relies on a curated database of known vulnerabilities, and sometimes, the way your project is structured can make it hard for cargo audit to see the whole picture.

Let’s say you’re running cargo audit and it’s not flagging a dependency you know is vulnerable, or it’s giving you a false positive. This usually boils down to how cargo audit queries the vulnerability database and how your Cargo.lock file represents your dependency tree.

Here are the most common reasons cargo audit might miss a CVE, or report one incorrectly:

Outdated cargo-audit Binary: The cargo-audit tool itself needs to be updated to fetch the latest vulnerability information. If you installed it a while ago, it might be using a stale database.
- Diagnosis: Run cargo audit --version. Compare this to the latest release on crates.io or its GitHub repository.
- Fix: cargo install cargo-audit --force
- Why it works: This fetches the newest version of the cargo-audit binary, which then pulls the most up-to-date vulnerability advisories from the crates.io security database.
Stale crates.io Index: Even with an updated cargo-audit, if your local cargo metadata (specifically, the registry index it uses) is old, it might not reflect the latest dependency versions or their associated advisories.
- Diagnosis: Run cargo clean --index. Then try cargo audit again.
- Fix: cargo clean --index
- Why it works: This command forces Cargo to re-download the entire registry index from crates.io, ensuring that it has the latest metadata about all published crates, including their version history and any security advisories linked to specific versions.
Dependency Version Mismatch in Cargo.lock: The most common culprit. cargo audit reports vulnerabilities based on the exact versions listed in your Cargo.lock file. If your Cargo.toml specifies a range (e.g., some-crate = "1.2.3"), cargo audit will check the version pinned in Cargo.lock. If that pinned version isn’t the one with the known CVE, cargo audit won’t flag it, even if a newer, vulnerable version could have been pulled.
- Diagnosis: Manually inspect your Cargo.lock file for the specific dependency in question. Cross-reference the version listed there with known CVE databases (like the RustSec Advisory Database directly on GitHub).
- Fix: Update the dependency in your Cargo.toml to a version that includes the fix for the CVE. Then, run cargo update --package <vulnerable-crate-name>. Finally, run cargo audit.
- Why it works: cargo update modifies Cargo.lock to use a newer version of the specified crate. cargo audit then analyzes this new, presumably patched, version.
Transitive Dependencies Not Fully Resolved: Sometimes, the vulnerability might be in a dependency of a dependency, and cargo audit might not be able to trace it correctly if there are complex overrides or indirect version constraints.
- Diagnosis: Run cargo tree --prefix 1 --no-indent to see your direct dependencies. Then, for each direct dependency, run cargo tree --prefix 1 --no-indent <direct-dependency-name> to inspect its dependencies. Look for the vulnerable crate deep in the tree.
- Fix: Similar to #3, update the direct dependency that brings in the vulnerable transitive dependency. If crate-a depends on vulnerable-crate@1.0.0, and you need vulnerable-crate@1.1.0 (which is fixed), you might need to update crate-a to a version that uses vulnerable-crate@1.1.0. Run cargo update --package <direct-dependency-name>.
- Why it works: By updating the direct dependency, you are forcing Cargo to re-evaluate the entire dependency graph, potentially pulling in newer versions of transitive dependencies that resolve the vulnerability.
Private Registries or Forked Crates: If you’re using a private registry or a forked version of a crate, cargo audit might not be able to query the public vulnerability database for advisories that apply to your custom versions.
- Diagnosis: Check your Cargo.toml for [patch.crates-io] or [replace] sections, or custom registry configurations in .cargo/config.toml.
- Fix: Manually audit the code of your forked crate or the versions published to your private registry against known CVEs. If a vulnerability exists, you’ll need to patch it yourself and potentially update the [patch.crates-io] or registry configuration to point to your fixed version.
- Why it works: cargo audit’s primary data source is the public crates.io advisory database. When you deviate from standard published versions, you bypass this automated checking mechanism, requiring manual intervention.
Incorrect Advisory Mapping: Occasionally, the RustSec advisory database might have a slight mismatch between the crate name/version range and the actual vulnerable code. This is rare but can happen.
- Diagnosis: If cargo audit reports a CVE for a crate and version that you know is not vulnerable (perhaps you’ve inspected the code or it’s a very old, unmaintained crate with no known issues), double-check the advisory details on the RustSec GitHub repository.
- Fix: You can use the CARGO_AUDIT_IGNORE environment variable or the [advisories] section in your .cargo/config.toml to suppress specific advisories. For example, to ignore advisory RUSTSEC-2023-0001:
```
# In .cargo/config.toml
[advisories]
ignore = ["RUSTSEC-2023-0001"]
```
  Or in your shell: CARGO_AUDIT_IGNORE=RUSTSEC-2023-0001 cargo audit
- Why it works: This explicitly tells cargo audit to disregard the specific advisory, preventing false positives while allowing it to continue checking other vulnerabilities.

After fixing these, the next error you’ll likely encounter is a new, distinct CVE that you’ll need to address, or perhaps a build failure if one of your dependency updates introduced a breaking change.