To fix a vulnerable indirect dependency in Go, find the module and its fixed version, run go get module@fixed-version in your main module, then run go mod tidy and re-scan. Use replace or exclude only when no fixed release exists, and remember they apply only to your own build.
Step 1: find why the module is in your build
Start with the path from your code to the vulnerable package:
go mod why -m golang.org/x/text
go mod graph
The go mod why command prints a shortest path in the import graph from the main module to the package. The go mod graph command prints the module requirement graph, one pair per line.
Step 2: upgrade the module directly
Go lets you raise an indirect dependency from your own go.mod. Name the module and the fixed version from the advisory:
go get golang.org/x/text@v0.3.8
go mod tidy
The Go reference notes that required versions in go.mod are minimum versions and may be raised. After the upgrade, the module stays marked as indirect if your code does not import it. That is normal.
If upgrading one module forces a newer version of another, go get upgrades that too. If two arguments need different versions of the same module, go get reports an error.
Step 3: confirm the fix
Re-run your scanner. For Go projects, a reachability-aware tool will also tell you whether your code calls the vulnerable function at all. The govulncheck tutorial describes findings as affected when a call stack reaches a vulnerable symbol, and informational when the module is imported but no call reaches it.
When no fixed version exists
| Option | What it does | Limits |
|---|---|---|
| replace | Swaps a module version for a fork or local copy | Only applies in the main module's go.mod |
| exclude | Blocks a specific version from loading | Only applies in the main module's go.mod |
| Remove the call | Stop using the vulnerable function | Needs a code change |
The reference states that replace and exclude directives are ignored in dependencies. That means a library you publish cannot force its users onto your patched fork. Your applications can, but you then own that fork, and you should note why in a comment so the next person can remove it.
Do not stop at the lockfile
Go has no lock file, so your go.mod is the record. Review the diff of go.mod and go.sum in the pull request, as you would any dependency change.
Try it yourself
Click through it at your own pace, or open it full screen.
Look for how a fixed version is shown beside the affected one, which is the number you pass to go get.
Quick check
Can I upgrade a module I do not import directly?
Yes. Run go get with the module path and a version. It will be recorded in your go.mod as an indirect requirement.
Will my replace directive protect people who use my library?
No. The Go reference says replace is ignored outside the main module, so downstream users keep the versions their own go.mod selects.
Safeguard's autonomous remediation can open fix pull requests for vulnerable dependencies. It is off by default, with every category set to Manual, so a person approves each change. You can start with the free scan.
Sources
Last reviewed: 19 October 2026.
