CVE-2025-3757 is a critical flaw (CVSS 9.8) in the OpenPubkey library, in versions before 0.10.0. A specially crafted JWS could bypass signature verification, with no login or user action needed. The fix is to upgrade to 0.10.0 or later, then check every project that depends on the library.
What's affected
The record names the OpenPubkey library, versions prior to 0.10.0. The description says a specially crafted JWS could bypass signature verification. The fixed line is 0.10.0, so any build older than that should be treated as affected.
OpenPubkey is a Go library, so the question for most teams is not whether they installed it directly but whether something they ship pulls it in.
The record lists the weakness as CWE-305 (authentication bypass by primary weakness) and CWE-347 (improper verification of cryptographic signature). The CVSS 3.1 score is 9.8 (critical), with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. The vector shows the flaw can be reached over the network, and no login is needed. Confidentiality impact is rated high, integrity high and availability high.
The record does not say this flaw is exploited in the wild, and the CISA Known Exploited Vulnerabilities flag is false. The record gives no further technical detail, and this post does not add any.
How to check if you're exposed
OpenPubkey is a Go module, so your go.mod and go.sum files are the place to look.
- In each Go project, list the version of the module in use:
go list -m github.com/openpubkey/openpubkey
- If the command reports that the module is not in the build list, see whether it comes in through another dependency:
go mod why -m github.com/openpubkey/openpubkey
- Search your repositories for the module path in go.mod files:
grep -r 'github.com/openpubkey/openpubkey' --include=go.mod .
- Compare any version you find with 0.10.0. Anything lower needs the update. Also check vendored copies and container images built from older commits.
If you manage many repositories, the free in-browser dependency scan covers the libraries your projects pull in, and the Gold directory lets you look up other CVEs by product. Neither replaces reviewing the code of an application you deploy by hand.
What to do now
- Upgrade github.com/openpubkey/openpubkey to 0.10.0 or later in every project that uses it, then rebuild and redeploy.
- If another dependency pulls it in, update that dependency, or add a direct requirement on the fixed version until the upstream project catches up.
- Rebuild container images and binaries that were compiled before the upgrade. A fixed go.mod does not change a binary that is already deployed.
- Review where your code trusts a verified token to make an authorization decision, and make sure a failed verification stops the request.
- Add a check in your pipeline that fails builds when a known vulnerable version of this module appears.
- Read the project's repository and release notes for any further guidance, and check them for newer advisories.
Why it matters
Signature verification is the step that makes a signed token worth trusting. If a crafted token can get past it, the rest of the system sees a claim that looks valid but was never signed by the expected party. That is why the record rates this at 9.8, the top of the range for network flaws that need no privileges.
The record lists CWE-305, an authentication bypass by a primary weakness, and CWE-347, improper verification of a cryptographic signature. Both point at the same place: a check that should have rejected an input did not. Libraries like this sit deep in the stack, so the practical risk depends on how many of your services call into them and what they decide based on the result.
Reachability analysis helps here. Knowing that a vulnerable module is in your dependency tree is the first step. Knowing whether your code actually calls the affected verification path tells you which services to fix first.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Which version fixes CVE-2025-3757?
The record says versions prior to 0.10.0 are affected, so 0.10.0 or later is the version to move to. Check the project's repository for anything newer.
I never installed OpenPubkey. Am I safe?
Not necessarily. It may be a transitive dependency. Run go mod why on the module path, or scan the project to see the full dependency tree.
Sources
- Gold entry for CVE-2025-3757
- NVD record for CVE-2025-3757, published 2025-05-13, as summarized above
- OpenPubkey repository, listed in the record
- OpenPubkey releases page
Last reviewed: 18 October 2026.
