Summary
JWK Set's HTTP client only overwrites and appends JWK to local cache during refresh
Workarounds
The only workaround would be to remove the provided auto-caching HTTP client and replace it with a custom implementation. This involves setting the HTTPClientStorageOptions.RefreshInterval to zero (or not specifying the value). Upgrade to v0.6.0 is advised.
References
Please see the tracking issue on GitHub for additional details: https://github.com/MicahParks/jwkset/issues/40
Impact
The project's provided HTTP client's local JWK Set cache should do a full replacement when the goroutine refreshes the remote JWK Set. The current behavior is to overwrite or append. This is a security issue for use cases that utilize the provided auto-caching HTTP client and where key removal from a JWK Set is equivalent to revocation.
Example attack scenario:
- An attacker has stolen the private key for a key published in JWK Set.
- The publishers of that JWK Set remove that key from the JWK Set.
- Enough time has passed that the program using the auto-caching HTTP client found in
github.com/MicahParks/jwksetv0.5.0-v0.5.21 has elapsed itsHTTPClientStorageOptions.RefreshIntervalduration, causing a refresh of the remote JWK Set. - The attacker is signing content (such as JWTs) with the stolen private key and the system has no other forms of revocation.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
The affected auto-caching HTTP client was added in version v0.5.0 and fixed in v0.6.0. Upgrade to v0.6.0 or later.
Frequently Asked Questions
- What is CVE-2025-22149? CVE-2025-22149 is a low-severity security vulnerability in github.com/MicahParks/jwkset (go), affecting versions >= 0.5.0, <= 0.5.21. It is fixed in 0.6.0.
- Which versions of github.com/MicahParks/jwkset are affected by CVE-2025-22149? github.com/MicahParks/jwkset (go) versions >= 0.5.0, <= 0.5.21 is affected.
- Is there a fix for CVE-2025-22149? Yes. CVE-2025-22149 is fixed in 0.6.0. Upgrade to this version or later.
- Is CVE-2025-22149 exploitable, and should I be worried? Whether CVE-2025-22149 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2025-22149 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2025-22149? Upgrade
github.com/MicahParks/jwksetto 0.6.0 or later.