CVE-2026-32597: 
Python vulnerability analysis and mitigation

CVE-2026-32597 is a JWT validation bypass vulnerability in PyJWT, a JSON Web Token implementation in Python, caused by the library's failure to validate the crit (Critical) Header Parameter as required by RFC 7515 §4.1.11. When a JWS token contains a crit array listing extensions that PyJWT does not understand, the library accepts the token instead of rejecting it — a direct violation of the RFC's MUST requirement. All PyJWT versions prior to 2.12.0 are affected. The vulnerability was published on March 12, 2026, and carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory, Red Hat Bugzilla).

The root cause is classified under CWE-345 (Insufficient Verification of Data Authenticity), CWE-347 (Improper Verification of Cryptographic Signature), and CWE-863 (Incorrect Authorization). RFC 7515 §4.1.11 mandates that if a JWS token's crit header lists extension parameters that the recipient does not understand, the token MUST be rejected as invalid. PyJWT's decode() function omits this check entirely, allowing an attacker to craft a token with arbitrary unknown critical extensions (e.g., "crit": ["x-custom-policy"]) that the library silently accepts. A public proof-of-concept demonstrates this by constructing a valid HS256-signed token with an unrecognized crit extension and showing PyJWT returns the payload instead of raising InvalidTokenError (GitHub Advisory). This is the same vulnerability class as CVE-2025-59420 affecting Authlib.

Successful exploitation allows an unauthenticated remote attacker to forge or tamper with JWT tokens that applications relying on PyJWT will incorrectly accept as valid, resulting in a high integrity impact with no confidentiality or availability loss. Practical consequences include security policy bypass when the crit header carries enforcement semantics such as MFA requirements, token binding, or scope restrictions; split-brain verification in mixed-library deployments where an API gateway using a compliant library rejects a token but the PyJWT-backed backend accepts it; and silent bypass of RFC 7800 Proof-of-Possession (cnf) key semantics. Downstream IBM products including Cloud Pak for Automation, Cloud Pak for Security, Maximo Application Suite, Engineering AI Hub, Guardium Data Security Center, and IBM Db2 on Cloud Pak for Data are also affected as they bundle vulnerable PyJWT versions (GitHub Advisory, Red Hat Bugzilla).

A self-contained Python proof-of-concept is publicly available in the official GitHub Security Advisory, demonstrating that a crafted JWT with an unknown crit extension is accepted by PyJWT when it should be rejected (GitHub Advisory). There is no evidence of in-the-wild exploitation at this time, and no threat actor attribution has been reported. The EPSS score is approximately 0.014% (3rd percentile), indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No exploit kits or weaponized tooling have been identified.

1. Identify target: Locate an application that uses PyJWT versions < 2.12.0 for JWT validation, particularly those where the crit header carries security-relevant semantics (e.g., MFA enforcement, token binding).
2. Obtain a valid signing secret or key: In scenarios where the attacker can obtain or guess the signing secret (e.g., weak shared secret, insider threat), or where the application accepts tokens signed with a known key.
3. Craft a malicious JWT: Construct a JWT with an unknown critical extension in the header, such as {"alg": "HS256", "crit": ["x-custom-policy"], "x-custom-policy": "require-mfa"}, and a payload with elevated privileges (e.g., {"sub": "attacker", "role": "admin"}).
4. Sign the token: Sign the crafted header and payload using the known secret with HMAC-SHA256 (or the applicable algorithm).
5. Submit the token: Send the crafted JWT to the target application's authentication or authorization endpoint.
6. Bypass security policy: PyJWT accepts the token without rejecting it for the unknown crit extension, returning the payload and granting the attacker access as if the token were fully valid — bypassing any security policy the crit extension was intended to enforce (GitHub Advisory).

• Network: Incoming JWT tokens in HTTP Authorization headers or request bodies containing a crit array with non-standard extension names (e.g., x-custom-policy, x-token-binding) that are not recognized by the application's JWT library.
• Logs: Application logs showing successful JWT validation for tokens that include unrecognized crit header parameters; absence of InvalidTokenError or equivalent rejection log entries for such tokens.
• Application Behavior: Unexpected privilege escalation or policy bypass events (e.g., MFA-required actions completed without MFA) correlated with JWT-authenticated sessions; discrepancies between API gateway rejection logs and backend acceptance logs for the same token.
• File System / Code: Presence of PyJWT versions < 2.12.0 in pip freeze output, requirements.txt, or installed package manifests (pip show PyJWT).

The primary remediation is to upgrade PyJWT to version 2.12.0 or later, which adds proper crit header validation in accordance with RFC 7515 §4.1.11 (GitHub Advisory). For affected IBM products (Cloud Pak for Automation, Cloud Pak for Security, Cloud Pak for Data, Maximo Application Suite, Engineering AI Hub, Guardium Data Security Center, IBM Db2 on Cloud Pak for Data, QRadar Suite Software, and Instana Observability), apply the corresponding security patches available through IBM support pages. Red Hat Enterprise Linux 8, 9, and 10 users should apply the relevant RHSA errata (e.g., RHSA-2026:12176, RHSA-2026:13672, RHSA-2026:13916) (Red Hat Bugzilla). As a temporary workaround where upgrading is not immediately possible, applications can implement their own crit header validation before passing tokens to PyJWT's decode() function, rejecting any token whose crit array contains extensions not explicitly supported.

The vulnerability was reported by researcher dmbs335 and published by the PyJWT maintainer (jpadilla) via GitHub Security Advisory on March 12, 2026 (GitHub Advisory). The advisory explicitly draws a parallel to CVE-2025-59420, a similar crit bypass in Authlib that received the same CVSS 7.5 (High) score, framing this as a recurring class of JWT library vulnerability. Multiple Linux distributions including Red Hat, SUSE, Debian, Ubuntu, AlmaLinux, Rocky Linux, and Oracle Linux issued security advisories and updated packages. IBM issued advisories for over a dozen affected enterprise products. Community coverage appeared on security aggregators and Linux security news sites, reflecting broad awareness of the issue across the open-source ecosystem.