A yanked module version is one the registry says should be avoided, such as because of a security vulnerability. Bazel stops with an error if module resolution selects it. Upgrade to a newer, non-yanked version. Allow the yanked one only as a short, documented exception.
Definition
Bazel module registries can declare certain versions of a module as yanked. The registry's metadata file for a module has a yanked versions field: a JSON object whose keys are versions and whose values describe why, ideally with a link to more information. When resolution picks a yanked version, Bazel throws an error.
What to do, in order
- Read the reason. The yank message is your first piece of evidence. If it links to an advisory, read it.
- Find out who pulls it in. Use the module graph command to see which module depends on the yanked version, and the explain command to list every place the module appears.
- Upgrade. Bump your direct dependency, or bump the module that requests the old one. Because Bazel picks the highest version any dependent requests, raising the minimum in one place can fix it.
- Pin if you must. A single version override can pin a module to a specific version regardless of what the graph requests. Only the root module's overrides apply.
- Allow only with a deadline. A flag lets the build proceed with a yanked version. Record why, who approved it and when it expires.
What gets recorded
If you do allow a yanked version, the lockfile stores it in a section for selected yanked versions, because yank data is mutable and cannot be referenced by hash. That section is only non-empty when yanked versions are explicitly allowed. A diff that adds an entry there is a clear review trigger.
Keeping the signal fresh
Yank information changes after you resolve. The default lockfile mode avoids refreshing mutable information for dependencies that have not changed. A scheduled job in refresh mode picks up new yanks, so a version that was fine last month can fail loudly this month.
| Mode | Notices a new yank? |
|---|---|
| update | Not for unchanged dependencies |
| refresh | Yes, when switching to it and roughly hourly while in it |
| error | No network during resolution |
What a yank is not
It is not proof that you were attacked, and it is not a full vulnerability database. Registries yank for many reasons. Also, a clean resolution does not mean the module is free of known issues. Scan the dependency inventory separately.
Quick check
Will a yanked version silently build?
No. Bazel errors when resolution selects one, unless you explicitly allow yanked versions with a flag or environment variable.
How do I see who depends on a yanked module?
Use the module command with the explain subcommand, which shows where the module appears and which modules directly depend on it.
Sources
- Bazel documentation: Bazel modules
- Bazel documentation: Bazel registries
- Bazel documentation: Bazel lockfile
- Bazel documentation: mod command
Last reviewed: 19 October 2026.
