Monitor vulnerabilities like this one.
Sign up free to get alerted when software you use is affected.
5.9
OAuth Server: Weak Code Verifier Allows Brute-Force Token Theft
GHSA-jhm7-29pj-4xvf
Summary
A security flaw in the OAuth server allows an attacker to steal tokens by guessing a weak code verifier. This can happen if an attacker intercepts an authorization code and tries different weak code verifier values. To protect your OAuth server, ensure that it properly enforces the code verifier format and length as per the RFC7636 specification.
What to do
- Update node-oauth oauth2-server to version 5.3.0.
Affected software
| Ecosystem | Vendor | Product | Affected versions |
|---|---|---|---|
| npm | node-oauth | oauth2-server |
<= 5.2.1 Fix: upgrade to 5.3.0
|
Original title
@node-oauth/oauth2-server: PKCE code_verifier ABNF not enforced in token exchange allows brute-force redemption of intercepted authorization codes
Original description
## 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
1. `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).
2. `lib/grant-types/authorization-code-grant-type.js` compares `hash(code_verifier)` to stored `codeChallenge` without validating verifier format/length.
3. 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
1. Send repeated token requests with guessed `code_verifier` values:
```http
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>
```
2. Observe invalid guesses return `invalid_grant`.
3. Continue guessing (`a`..`z`).
4. When `code_verifier=z`, token issuance succeeds and returns bearer tokens.
### Confirmed PoC output
```text
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
1. Enforce `pkce.codeChallengeMatchesABNF(request.body.code_verifier)` in authorization code token exchange before hashing/comparison.
2. Reject verifier values outside RFC7636 charset/length (`43..128` unreserved).
3. Invalidate authorization codes on failed verifier attempts (or add strict retry limits) to prevent online guessing.
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
1. `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).
2. `lib/grant-types/authorization-code-grant-type.js` compares `hash(code_verifier)` to stored `codeChallenge` without validating verifier format/length.
3. 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
1. Send repeated token requests with guessed `code_verifier` values:
```http
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>
```
2. Observe invalid guesses return `invalid_grant`.
3. Continue guessing (`a`..`z`).
4. When `code_verifier=z`, token issuance succeeds and returns bearer tokens.
### Confirmed PoC output
```text
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
1. Enforce `pkce.codeChallengeMatchesABNF(request.body.code_verifier)` in authorization code token exchange before hashing/comparison.
2. Reject verifier values outside RFC7636 charset/length (`43..128` unreserved).
3. Invalidate authorization codes on failed verifier attempts (or add strict retry limits) to prevent online guessing.
ghsa CVSS3.1
5.9
Vulnerability type
CWE-307
CWE-1289
Published: 16 Apr 2026 · Updated: 16 Apr 2026 · First seen: 16 Apr 2026