If the version a fix PR proposes has been yanked or removed, do not merge it. Find out why it was withdrawn, check the advisory for another fixed release, and update the PR. Yanked versions are sometimes pulled because of a bug, and sometimes because of something worse.
What yanked means
Registries differ. Renovate's documentation says that for some registries, existing releases or even whole packages can be removed or yanked at any time, while for others only very new or unused releases can be removed. A maintainer might pull a release for a packaging mistake, a regression, a licensing issue or a compromise. The registry rarely says which.
Immediate steps
- Stop the merge. Mark the PR as blocked, so nobody merges it on a green check.
- Read the registry page and the project's issues. Look for a note about the withdrawal.
- Check the advisory again. Does it name another fixed version? Fixed lines sometimes include more than one release.
- Look at the next release after the yanked one. If a replacement exists, review its changes as a new update.
- Rescan after the change. Confirm the finding clears.
For guidance on a suspicious release specifically, see can a fix PR pull in a compromised release and a package you use was flagged malicious by mistake.
What if you already run the yanked version?
This is the harder case, and Renovate documents it. Its rollback feature proposes a downgrade to the next highest release if the current release is no longer found in the registry. The option, rollbackPrs, defaults to false, so the tool does not open such PRs unless you enable it. Treat any such PR like a normal fix PR: read what changes, run tests, and check whether the downgrade reopens a known vulnerability.
If you are running a withdrawn version that was pulled for a security reason, assume your build is affected until shown otherwise. See after removing the bad version, what is still compromised.
Decision table
| Situation | Action |
|---|---|
| Version yanked, no reason given, replacement exists | Review replacement, update PR |
| Version yanked for a bug | Move to the fixed release, watch for the same bug |
| Version yanked for compromise | Treat as an incident, rotate secrets that were reachable |
| Currently running version removed | Review a rollback or upgrade PR, rebuild from your lockfile and mirror |
| No replacement and vulnerability open | Mitigate, record an exception with an owner and a date |
Reduce the risk next time
Keep a mirror or cache of dependencies you use, so a removal upstream does not break your builds. Pin and verify with a lockfile. Be wary of brand new releases: Dependabot's cooldown feature delays version updates, with a default of three days, but GitHub states that the default cooldown does not apply to security updates, so urgent fixes still need human judgement. See dependabot cooldown: delay new releases.
Record the outcome
Add a note to the PR or the ticket: what was withdrawn, why if known, which version you chose, and the evidence. If the story turns out to involve a compromise, that note will be useful.
Try it yourself
Open the demo and look at how an inventory lists each package and version in use. You need that list to tell whether a withdrawn version is running anywhere.
Click through it at your own pace, or open it full screen.
Safeguard can open fix pull requests through autonomous remediation. It is off by default and every category starts on Manual, so a person approves each change. You can also run a free scan to see which dependencies have known fixes before you decide what to automate.
Quick check
Should I ever merge a PR for a yanked version?
No. Resolve why it was withdrawn first, then choose a version that still exists and fixes the issue.
Does a rollback PR from a bot mean something is wrong?
It means the current version is no longer in the registry. Review it carefully, since it may reintroduce a vulnerability.
Sources
- Renovate Docs: Configuration options
- GitHub Docs: Optimizing the creation of pull requests for Dependabot version updates
Last reviewed: 19 October 2026.
