CVE-2026-102266: PyJWT Authentication Bypass Vulnerability

CVE-2026-102266 Overview

CVE-2026-102266 is a signature verification flaw [CWE-347] in PyJWT, a widely used Python implementation of JSON Web Token (JWT) standards. The vulnerability affects versions from 2.13.0 up to (but not including) 2.14.0. The HMACAlgorithm.from_jwk verification path decoded the key without applying the prepare_key validation step. When a trusted JWK Set contains an oct entry with an empty k value, an attacker can sign an HMAC token using the same zero-length key. The forged token is then accepted by PyJWT and can carry arbitrary authenticated claims. The issue is fixed in version 2.14.0.

Critical Impact
Attackers can forge HMAC-signed JWTs accepted by PyJWT when a trusted JWK Set contains an oct key with an empty k value, enabling authentication bypass and privilege escalation through arbitrary authenticated claims.

Affected Products

PyJWT 2.13.0
PyJWT versions after 2.13.0 and prior to 2.14.0
Applications consuming JWK Sets containing oct entries via HMACAlgorithm.from_jwk

Discovery Timeline

2026-09-28 - CVE-2026-102266 published to NVD
2026-09-30 - Last updated in NVD database

Technical Details for CVE-2026-102266

Vulnerability Analysis

PyJWT provides HMAC-based JWT signing and verification through the HMACAlgorithm class. The prepare_key method normally enforces constraints on HMAC keys, including rejecting empty byte strings and preventing keys that resemble asymmetric PEM material. The verification path in jwt/api_jws.py bypassed this step when the key originated from a PyJWK object. It assigned prepared_key = key.key directly instead of routing the key through alg_obj.prepare_key(key.key).

This inconsistency between the signing path and the verification path allowed a zero-length HMAC secret to reach the underlying cryptographic primitive. An attacker who can influence the trusted JWK Set, or who identifies a deployment that already publishes an oct entry with an empty k, can generate valid HMAC signatures over attacker-controlled claims.

Root Cause

The root cause is missing input validation on JWK-derived HMAC keys during verification. prepare_key was applied to raw string keys but skipped for PyJWK instances, producing inconsistent key handling across code paths. An empty octk value therefore propagated to hmac.new unchecked, permitting signature forgery.

Attack Vector

Exploitation requires a JWK Set trusted by the application to contain an oct entry with k set to an empty value. The attacker constructs a JWT, sets the alg header to a matching HMAC algorithm (HS256, HS384, or HS512), populates arbitrary claims, and signs the token using a zero-length key. The vulnerable PyJWT verifier accepts the signature and returns the forged claims to the application.

python

# Security patch in jwt/api_jws.py
#                     f"algorithm {key.algorithm_name!r}"
#                 )
             alg_obj = key.Algorithm
-            prepared_key = key.key
+            prepared_key = alg_obj.prepare_key(key.key)
         else:
             try:
                 alg_obj = self.get_algorithm_by_name(alg)

Source: PyJWT commit f91ed44. The patch routes JWK-derived keys through alg_obj.prepare_key, restoring the same validation applied to raw string keys and rejecting empty HMAC secrets.

Detection Methods for CVE-2026-102266

Indicators of Compromise

JWK Set responses (jwks.json) served by trusted issuers containing "kty": "oct" entries with "k": "" or otherwise empty values.
Authentication logs showing successful JWT validation for tokens with unusually short or empty signature segments.
Access events for privileged accounts originating from unexpected clients shortly after a JWKS refresh.

Detection Strategies

Inventory Python services and identify the installed PyJWT version using pip show pyjwt; flag any release from 2.13.0 up to but not including 2.14.0.
Statically scan application code for calls to PyJWK, PyJWKSet, or HMACAlgorithm.from_jwk and audit the trusted JWK sources they consume.
Add integration tests that submit a JWT signed with an empty HMAC key and confirm the verifier rejects it.

Monitoring Recommendations

Monitor outbound fetches to JWKS endpoints and alert on JWK entries with empty or malformed k fields.
Log JWT kid, alg, and issuer values on every verification and alert on unexpected alg downgrades to HS256/HS384/HS512.
Correlate JWKS retrieval events with subsequent authentication decisions to detect anomalous token acceptance patterns.

How to Mitigate CVE-2026-102266

Immediate Actions Required

Upgrade PyJWT to version 2.14.0 or later across all Python services and rebuild container images.
Audit trusted JWK Sets and remove any oct entries with empty or short k values before redeploying.
Rotate any HMAC keys and invalidate long-lived tokens issued during the exposure window.

Patch Information

The fix is delivered in PyJWT 2.14.0. The relevant change in jwt/api_jws.py ensures that HMACAlgorithm.prepare_key runs on the key returned by a PyJWK instance, applying the same validation used for raw string keys. See the GitHub Security Advisory GHSA-9j54-fg26-wv3r, the PyJWT 2.14.0 release notes, and the upstream patch commit for full details.

Workarounds

Restrict accepted JWT algorithms by passing an explicit algorithms= allowlist to jwt.decode and prefer asymmetric algorithms such as RS256 or ES256 where feasible.
Validate JWK Sets before caching them and reject any oct entry whose k value is empty or shorter than the algorithm's minimum key length.
Pin PyJWT>=2.14.0 in requirements.txt or pyproject.toml to prevent regressions during dependency resolution.

bash

# Upgrade PyJWT to the patched release
pip install --upgrade "PyJWT>=2.14.0"

# Verify the installed version
python -c "import jwt; print(jwt.__version__)"

# Example dependency pin
echo 'PyJWT>=2.14.0' >> requirements.txt