Use your package manager's patch command. Both pnpm and Yarn can extract a dependency into a temporary directory, let you edit it, then record the difference as a patch file registered in your manifest. It is a stopgap for a vulnerability with no fixed release, not a replacement for upgrading.
How the patch commands work
The pnpm documentation describes the flow. You run the patch command with a package name and version, and pnpm extracts that package into a temporary directory intended to be editable at will. When you are done you run patch-commit with that directory. pnpm generates a patch file and registers it in your top-level manifest through the patchedDependencies field.
Yarn works the same way. Its patch command extracts the package for editing, and patch-commit generates a patchfile and registers it through the patch protocol. The Yarn docs add a detail worth knowing: running the command when you already have a patch resets existing patches by default, and an update flag imports the current patch.
Steps
- Confirm there is no fixed release and that you cannot mitigate another way.
- Extract the exact installed version for editing.
- Make the smallest change that closes the hole. Do not refactor.
- Commit the patch and the manifest entry together.
- Add a test that fails without the patch.
- Record the advisory, the version, and a review date in the pull request.
Details that bite
pnpm patches can be keyed by exact version, a version range, or the name alone. The docs give a priority order: exact versions first, then ranges, then name-only. They also advise avoiding overlapping ranges. Prefer an exact version, so a later upgrade does not silently apply an old patch to new code.
There is a setting that lets installs continue when a patch was not applied. By default it is off, so a patch that no longer applies fails the install. That is good behavior: a failure tells you the dependency changed and the patch needs review, rather than leaving you unprotected without knowing.
One warning from the pnpm docs matters for security work. To change a package's own dependencies, do not edit its package.json through the patch command. Use overrides or a package hook instead.
Patch versus the other options
| Option | Effort | Maintenance | Use when |
|---|---|---|---|
| Upgrade | Low | None | A fixed release exists |
| Override a transitive version | Low | Remove later | A fixed release exists but a parent blocks it |
| Patch file | Medium | You carry it | No fixed release, change is small |
| Fork | High | You own it | Upstream is gone or the change is large |
See also the guide on when to fork an abandoned dependency.
Tell upstream
Open an issue or pull request upstream with your change. A patch you carry quietly is a patch nobody else benefits from, and it is one you must remember to remove.
Try it yourself
Click through it at your own pace, or open it full screen. Look for findings with no fixed version, since those are the ones that push teams toward patch files.
Where Safeguard fits
Safeguard scans dependencies, runs reachability analysis to show which findings your code can actually reach, and can open fix pull requests through autonomous remediation. That last feature is off by default and every category starts on Manual, so a person approves each change. You can try a free scan on a repository first.
Quick check
Does a patch file survive an upgrade of the dependency?
Only if it still applies. By default pnpm fails the install when a patch is not applied, which flags that it needs review.
Should I patch a dependency's package.json to change its dependencies?
No. The pnpm docs say to use overrides or a package hook for that.
Sources
Last reviewed: 19 October 2026.
