[GHSA-6v2p-p543-phr9] golang.org/x/oauth2 Improper Validation of Syntactic Correctness of Input vulnerability

[jchax]

Updates

• Summary

Comments
According to both https://nvd.nist.gov/vuln/detail/CVE-2025-22868 and the original https://pkg.go.dev/vuln/GO-2025-3488 this is a vulnerabilty in oauth2/jws, not oauth2.

[JonathanLEvans]

Hi @jchax,

Thank you for the interest in improving the advisory database. We use the golang.org/x/oauth2 module name rather than the golang.org/x/oauth2/jws package name for the advisory because the dependency graph only maps Go modules, not Go packages.

[jchax]

oauth2/jws is a module. Go programs that import golang.org/x/oauth2 have no requirement to include golang.org/x/oauth2/jws and, indeed, skopeo (related to podman and buildah) does just that: it has oauth2 but there is nothing in skopeo that includes oauth2/jws so there is no way for skopeo to be vulnerable to GHSA-6v2p-p543-phr9: the code simply isn't present.

[JonathanLEvans]

Hi @jchax,

Could you explain how you found that golang.org/x/oauth2/jws is a module? When I look at the golang.org/x/oauth2/jws page in the registry, it only has the package label.

On the other hand, golang.org/x/oauth2 has both the package and module labels. The golang.org/x/oauth2 page also says that it includes golang.org/x/oauth2/jws.

[github-actions]

👋 This pull request has been marked as stale because it has been open with no activity. You can: comment on the issue or remove the stale label to hold stale off for a while, add the Keep label to hold stale off permanently, or do nothing. If you do nothing this pull request will be closed eventually by the stale bot. Please see CONTRIBUTING.md for more policy details.

[jchax]

Sorry about the delay in responding. I was originally going to write small programs to illustrate the point, but then I realised I can just refer you to skopeo and podman. The problem here is that CVE-2025-22868 and, in particular, GO-2025-3488 list "golang.org/x/oauth2/jws" as an affected package. However, if you look at podman or skopeo you'll see that that both have vendor/golang.org/x/oauth2/ directories but no vendor/golang.org/x/oauth2/jws directory (as I'm sure you know, when a project is "vendored" all the project dependencies and dependencies of dependencies are in the vendor directory). To double check this you can run grep -r golang.org/x.oauth2/jws in a cloned repo and you'll see that that package is not referred to anywhere. (And, unlike oauth2/jwt, golang.org/x/oauth2/jws does not even import or depend upon golang.org/x/oauth2.)

So the issue here is that simply having vulnerable code in a sub-directory of https://cs.opensource.google/go/x/oauth2/ does not mean that the entire repo is vulnerable to a bug -- the vulnerable code has to be explicitly referred to, that is, imported by, some source file in, for the cases in question, skopeo or podman. Or, to put it another way, rebuilding (and re-vendoring) skopeo and podman with any version, vulnerable to any bug, of golang.org/x/oauth2/jws won't make any difference at all to the built versions of podman or skopeo because that package is simply not present.

The issue here, really, is that the dependency mapping graph is introducing false positives. We had a long argument with a scanner vendor (who I won't name) who insisted that because the dependency graph showed skopeo (in our case) was affected that it must, in fact, be affected and we had to explain how Go programs are compiled and how vendoring works at considerable length before they, grudgingly admitted that CVE-2025-22868 and GO-2025-3488 are correct and complete and GHSA-6v2p-p543-phr9 is wrong.

Whether this means changing the way dependency graphs are computed or making a manual fix to GHSA-6v2p-p543-phr9 and similar advisories, I can't say, but the error does cause real problems for people like ourselves and for end-users.

[JonathanLEvans]

Thanks for the feedback @aburmash, we recognize that listing the module rather than just the specific subpackage (e.g., golang.org/x/crypto/ssh) may result in broader alerts. This approach is necessary to ensure that all potentially affected users are notified and can evaluate their own usage. Where possible, we strive to be as accurate and granular as ecosystem data allows, and we continually review advisories for opportunities to improve precision. We appreciate feedback like yours, as it helps us refine our processes.

For more information on managing Dependabot alerts, including how to dismiss alerts that may not apply to your usage, please see GitHub Docs on alert dismissal.

Thank you so much for contributing to the GitHub Advisory Database. This database is free, open, and accessible to all, and it's people like you who make it great. Thanks for choosing to help others. We hope you send in more contributions in the future!