Add a [patch.crates-io] entry in your workspace root Cargo.toml that points the vulnerable crate at a fixed git revision or local path. Cargo applies it across the whole graph, including transitive uses, so a stuck parent crate picks up the fix. Remove it once a release ships.
When to reach for it
You have an advisory on a crate three levels down. The parent that pulls it in pins an old range, so a conservative update cannot move it. The fix exists upstream, maybe merged but unreleased. A patch lets you ship safely now without forking the parent.
How the patch works
The Cargo reference explains that a patch adds your copy to the registry for your build. It applies across the whole dependency graph, so one version of the crate resolves for everything. Each entry uses the same syntax as dependencies:
[patch.crates-io]
vulnerable_crate = { git = "https://example.com/org/vulnerable_crate.git", rev = "0123456789abcdef0123456789abcdef01234567" }
The name, URL and hash are placeholders for your real values.
Rules to remember
| Rule | Detail |
|---|---|
| Only the top level counts | Cargo reads patch settings from the workspace root manifest and ignores those in dependencies |
| Version must fit | The patched copy is used only if it satisfies the requirements in the graph |
| Libraries repeat it | Consumers of your library must add their own patch section |
| Config can override | A patch in a Cargo config file takes precedence, but the docs recommend using the manifest |
If the patch is not picked up, the reference suggests running a precise update for that crate to the right version.
Steps
- Confirm the fix commit and read it. You are putting this code into production.
- Check the fixed version number satisfies what the parents ask for.
- Add the patch entry with an explicit revision.
- Run a build and the test suite, then inspect the lockfile diff.
- Re-run your advisory check. The advisory should clear if the version is outside the affected range.
- Add a comment with the advisory ID, the upstream issue link and a removal date.
- Allow the git URL in your sources policy.
Cleanup
Once a fixed version is published, delete the patch section and update normally. The reference says exactly that for the case where a fix ships on the registry. If the fix is merged but unreleased, point the patch at the upstream repository instead of your fork.
Risks
A patch means you are running code that is not a registry release. A registry version cannot be changed after publication, a git revision can disappear if a repository is rewritten or deleted. Mirror it if the fix is critical.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a fix is proposed with the evidence a reviewer needs.
Quick check
Does a patch in a dependency's Cargo.toml affect my build?
No. Only the patch section at the workspace root is used.
Should I leave a patch in place indefinitely?
No. Treat it as temporary and set a removal date.
Safeguard can open fix pull requests through autonomous remediation, off by default with every category on Manual, and a free scan is available at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
