this post was submitted on 23 Feb 2026
8 points (90.0% liked)

Rust Programming

9158 readers
15 users here now

founded 6 years ago
MODERATORS
nutomic@lemmy.ml
Joe@lemmy.ml
AgreeableLandscape@lemmy.ml
8
What do I do after running cargo audit? (lemmy.ml)
submitted 16 hours ago by mawkler@lemmy.ml to c/rust@lemmy.ml
2 comments fedilink hide all child comments
 

So I ran cargo audit on a project and got the following output:

error: 4 vulnerabilities found!
warning: 8 allowed warnings found

What do I do to fix these errors? The vulnerabilities are in dependencies of my dependencies, and they seem to be using an older version of a package. Is my only option to upgrade my own dependencies (which would take a non-trivial amount of work), or is there any way to tell my dependencies to use a newer version of those vulnerable packages like how npm audit fix works? I'm guessing that's what cargo audit fix is supposed to do, but in my case it wasn't able to fix any of the vulnerabilities.

I tried searching the web, but there was surprisingly little information on this stuff.

you are viewing a single comment's thread
view the rest of the comments
[–] TehPers@beehaw.org 1 points 14 hours ago

If the version ranges for those dependencies which depend on vulnerable versions of packages cover the fixed versions as well, then just updating your Cargo.lock dependencies should pull the fixed versions. You can do this with cargo update.

If the ranges don't cover the fixes, you have a couple options:

  • If the vulnerability doesn't affect you, do nothing.
  • If it does affect you, you can patch the dependencies to a local version or one in a git branch.

If you choose to patch the dependency, the version of the patched package still needs to be compatible with what your dependencies are requesting. If foo v2.1.1 depends on bar = "3", then it can't use a patched bar v4.1.2 for example, but can use bar v3.3.4. You may need to backport a fix to an earlier version of a package in some cases. You can do that locally and use a path specifier in your patch for that.

In most cases, the vulnerability probably won't affect you. You should check to make sure though on a case-by-case basis.