CVE-2026-103001: State Pollution in PyJWT Option Merging Leads to Claim Verification Bypass

PyJWT is a Python implementation of JSON Web Token (JWT) standards widely used in web applications and backend microservices. Between versions 2.11.0 and 2.13.0, PyJWT is susceptible to a state pollution vulnerability within its internal option merging mechanism.

The vulnerability is triggered when a caller-supplied, mutable mapping (such as a standard Python dictionary) is passed to decode() or decode_complete() with signature verification set to disabled. Under these conditions, PyJWT's _merge_options() method directly modifies the caller's options mapping in-place, adding or modifying registered claim verification options to false.

This in-place modification permanently alters the configuration state of the reused mapping. If the calling application subsequently re-enables signature verification on that same object, the claim validation steps (such as expiration, audience, and issuer checks) remain disabled. This behavior allows attackers to present cryptographically valid but expired tokens, which the library accepts without throwing validation errors.

In Python, dictionary structures are passed by reference. When an application provides an options configuration dictionary to PyJWT.decode(), the library merges default options with user-provided settings inside jwt/api_jwt.py.

The logic in the vulnerable version of _merge_options() evaluates whether signature verification is disabled. If verify_signature is false, PyJWT defensively sets default verification flags to false directly within the input object itself rather than a localized copy. This operation mutates the caller's shared state directly.

When the application processes a second token and changes verify_signature back to true, the previously injected false parameters remain in the dictionary. Because PyJWT checks the specific dictionary keys for explicit verification overrides, the presence of these mutated keys bypasses checks for expiration (verify_exp), not-before (verify_nbf), issued-at (verify_iat), audience (verify_aud), issuer (verify_iss), subject (verify_sub), and JWT ID (verify_jti).

The vulnerability lies in jwt/api_jwt.py inside the _merge_options function. Prior to the patch, the mapping passed to the function was not isolated from the original reference.

Below is the vulnerable implementation:

def _merge_options(self, options: Options | None = None) -> FullOptions:
    if options is None:
        return self.options
 
    # (defensive) set defaults for verify_x to False if verify_signature is False
    if not options.get("verify_signature", True):
        options["verify_exp"] = options.get("verify_exp", False)
        options["verify_nbf"] = options.get("verify_nbf", False)
        options["verify_iat"] = options.get("verify_iat", False)
        options["verify_aud"] = options.get("verify_aud", False)
        options["verify_iss"] = options.get("verify_iss", False)
        options["verify_sub"] = options.get("verify_sub", False)
        options["verify_jti"] = options.get("verify_jti", False)
    return {**self.options, **options}

The patch addresses this state pollution by converting the incoming mapping to a standard, shallow-copied dictionary utilizing dict(options) and casting it as an Options object. This ensures that any key assignment affects only the isolated copy of the options mapping.

Below is the patched implementation:

def _merge_options(self, options: Options | None = None) -> FullOptions:
    if options is None:
        return self.options
 
    # Convert and isolate the incoming options mapping to prevent pollution
    merged_options = cast("Options", dict(options))
 
    # (defensive) set defaults for verify_x to False if verify_signature is False
    if not merged_options.get("verify_signature", True):
        merged_options["verify_exp"] = merged_options.get("verify_exp", False)
        merged_options["verify_nbf"] = merged_options.get("verify_nbf", False)
        merged_options["verify_iat"] = merged_options.get("verify_iat", False)
        merged_options["verify_aud"] = merged_options.get("verify_aud", False)
        merged_options["verify_iss"] = merged_options.get("verify_iss", False)
        merged_options["verify_sub"] = merged_options.get("verify_sub", False)
        merged_options["verify_jti"] = merged_options.get("verify_jti", False)
    return {**self.options, **merged_options}

Exploitation of this vulnerability requires that the target application reuse an options configuration dictionary across multiple decode requests. An attacker targeting the application must provide an expired or claim-mismatched token that has been cryptographically signed by the correct backend secret.

The following Python script reproduces the state pollution and demonstrates the subsequent verification bypass:

import jwt
import time
 
SECRET_KEY = "super_secure_secret_key"
ALGORITHM = "HS256"
 
# Generate a token that expired in the past
expired_payload = {
    "user_id": 1337,
    "exp": int(time.time()) - 3600
}
expired_token = jwt.encode(payload=expired_payload, key=SECRET_KEY, algorithm=ALGORITHM)
 
# Create a reusable options mapping
shared_options = {
    "verify_signature": False
}
 
# Trigger state pollution via unverified decoding
jwt.decode(jwt=expired_token, options=shared_options)
 
# Attempt to enforce signature verification while reusing the polluted mapping
shared_options["verify_signature"] = True
 
try:
    # This call should raise ExpiredSignatureError, but it returns the decoded payload
    decoded = jwt.decode(
        jwt=expired_token,
        key=SECRET_KEY,
        algorithms=[ALGORITHM],
        options=shared_options
    )
    print("Vulnerable: Token accepted despite expiration check being active")
    print(decoded)
except jwt.ExpiredSignatureError:
    print("Secure: Expired signature exception raised")

If the application utilizes the vulnerable version of PyJWT and reuses shared_options, the script will bypass the expiration check. If the PyJWT installation has been upgraded or patched, an ExpiredSignatureError is raised.

The impact of this state pollution vulnerability is classified as Medium (CVSS 6.5). The complexity of the attack is High, as exploitation relies entirely on how the consuming application implements PyJWT and manages configuration lifecycles. If an application never reuses options mappings, the vulnerability cannot be triggered.

For systems that do reuse options configuration mappings, the vulnerability bypasses critical logical controls. Attackers can replay expired authentication tokens or present tokens intended for different audiences, which can result in privilege escalation or session hijacking.

The vulnerability is a regression of similar mutable dictionary issues identified in previous developer discussions (such as Issue 679). No active exploitation in the wild has been reported, and the vulnerability has not been added to CISA's Known Exploited Vulnerabilities catalog.

To fully remediate CVE-2026-103001, update PyJWT to version 2.14.0 or higher. The fixed version ensures that all input mapping parameters are localized through copy operations prior to modifications.

In scenarios where immediate upgrading is not feasible, developers should adjust their implementation code to prevent dictionary reuse. Instead of modifying or referencing a shared dictionary, code should instantiate a fresh dictionary for each decode call:

# Insecure reuse pattern
jwt.decode(token, key, options=settings.JWT_CONFIG)
 
# Secure non-reused instantiation
jwt.decode(token, key, options=dict(settings.JWT_CONFIG))

Security teams can identify vulnerable patterns by scanning codebases with static analysis rules that alert on modified dictionary parameters passed directly to jwt.decode interfaces.