GHSA-JHM7-29PJ-4XVF
Vulnerability from github – Published: 2026-04-16 21:09 – Updated: 2026-04-16 21:09
VLAI?
Summary
@node-oauth/oauth2-server: PKCE code_verifier ABNF not enforced in token exchange allows brute-force redemption of intercepted authorization codes
Details
Summary
The token exchange path accepts RFC7636-invalid code_verifier values (including one-character strings) for S256 PKCE flows.
Because short/weak verifiers are accepted and failed verifier attempts do not consume the authorization code, an attacker who intercepts an authorization code can brute-force code_verifier guesses online until token issuance succeeds.
Root cause
lib/pkce/pkce.js(getHashForCodeChallenge) only checks thatverifieris a non-empty string before hashing forS256; it does not enforce RFC7636 ABNF (43..128unreserved chars).lib/grant-types/authorization-code-grant-type.jscompareshash(code_verifier)to storedcodeChallengewithout validating verifier format/length.- In
AuthorizationCodeGrantType.handle, authorization code revocation happens after verifier validation. Invalid guesses fail before revoke, so the same code can be retried repeatedly.
Steps to Reproduce
Setup
- PKCE authorization code exists with:
codeChallengeMethod = "S256"codeChallenge = BASE64URL(SHA256("z"))(verifier is one character, RFC-invalid)- Attacker has intercepted the authorization code value.
Reproduction
- Send repeated token requests with guessed
code_verifiervalues:
POST /token HTTP/1.1
Host: oauth.example
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&
client_id=client1&
client_secret=s3cret&
code=stolen-auth-code&
redirect_uri=https://client.example/callback&
code_verifier=<guess>
- Observe invalid guesses return
invalid_grant. - Continue guessing (
a..z). - When
code_verifier=z, token issuance succeeds and returns bearer tokens.
Confirmed PoC output
BRUTE_FORCE_SUCCESS { tries: 26, guess: 'z', status: 200, tokenIssued: true }
Impact
An intercepted authorization code can be redeemed by brute-forcing low-entropy verifiers that the server should have rejected under RFC7636.
This weakens PKCE’s protection goal and allows token theft when clients generate short/predictable verifiers.
Recommended Fix
- Enforce
pkce.codeChallengeMatchesABNF(request.body.code_verifier)in authorization code token exchange before hashing/comparison. - Reject verifier values outside RFC7636 charset/length (
43..128unreserved). - Invalidate authorization codes on failed verifier attempts (or add strict retry limits) to prevent online guessing.
Severity ?
5.9 (Medium)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 5.2.1"
},
"package": {
"ecosystem": "npm",
"name": "@node-oauth/oauth2-server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.3.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-1289",
"CWE-307"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-16T21:09:50Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\nThe token exchange path accepts RFC7636-invalid `code_verifier` values (including one-character strings) for `S256` PKCE flows. \nBecause short/weak verifiers are accepted and failed verifier attempts do not consume the authorization code, an attacker who intercepts an authorization code can brute-force `code_verifier` guesses online until token issuance succeeds.\n\n\n\n### Root cause\n\n1. `lib/pkce/pkce.js` (`getHashForCodeChallenge`) only checks that `verifier` is a non-empty string before hashing for `S256`; it does not enforce RFC7636 ABNF (`43..128` unreserved chars).\n2. `lib/grant-types/authorization-code-grant-type.js` compares `hash(code_verifier)` to stored `codeChallenge` without validating verifier format/length.\n3. In `AuthorizationCodeGrantType.handle`, authorization code revocation happens **after** verifier validation. Invalid guesses fail before revoke, so the same code can be retried repeatedly.\n\n## Steps to Reproduce\n\n### Setup\n\n- PKCE authorization code exists with:\n - `codeChallengeMethod = \"S256\"`\n - `codeChallenge = BASE64URL(SHA256(\"z\"))` (verifier is one character, RFC-invalid)\n- Attacker has intercepted the authorization code value.\n\n### Reproduction\n\n1. Send repeated token requests with guessed `code_verifier` values:\n\n```http\nPOST /token HTTP/1.1\nHost: oauth.example\nContent-Type: application/x-www-form-urlencoded\n\ngrant_type=authorization_code\u0026\nclient_id=client1\u0026\nclient_secret=s3cret\u0026\ncode=stolen-auth-code\u0026\nredirect_uri=https://client.example/callback\u0026\ncode_verifier=\u003cguess\u003e\n```\n\n2. Observe invalid guesses return `invalid_grant`.\n3. Continue guessing (`a`..`z`).\n4. When `code_verifier=z`, token issuance succeeds and returns bearer tokens.\n\n### Confirmed PoC output\n\n```text\nBRUTE_FORCE_SUCCESS { tries: 26, guess: \u0027z\u0027, status: 200, tokenIssued: true }\n```\n\n## Impact\n\nAn intercepted authorization code can be redeemed by brute-forcing low-entropy verifiers that the server should have rejected under RFC7636. \nThis weakens PKCE\u2019s protection goal and allows token theft when clients generate short/predictable verifiers.\n\n## Recommended Fix\n\n1. Enforce `pkce.codeChallengeMatchesABNF(request.body.code_verifier)` in authorization code token exchange before hashing/comparison.\n2. Reject verifier values outside RFC7636 charset/length (`43..128` unreserved).\n3. Invalidate authorization codes on failed verifier attempts (or add strict retry limits) to prevent online guessing.",
"id": "GHSA-jhm7-29pj-4xvf",
"modified": "2026-04-16T21:09:50Z",
"published": "2026-04-16T21:09:50Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/node-oauth/node-oauth2-server/security/advisories/GHSA-jhm7-29pj-4xvf"
},
{
"type": "PACKAGE",
"url": "https://github.com/node-oauth/node-oauth2-server"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "@node-oauth/oauth2-server: PKCE code_verifier ABNF not enforced in token exchange allows brute-force redemption of intercepted authorization codes"
}
Loading…
Loading…
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.
Loading…
Loading…