CVE-2026-32597

What it actually does

PyJWT versions prior to 2.12.0 fail to enforce the JSON Web Signature requirement for the crit header parameter. In JWS/JWT, crit identifies header extensions that must be understood and processed by the verifier before the token can be accepted. A vulnerable verifier can accept a signed token that declares unknown critical extensions instead of rejecting it. The main impact is integrity failure: applications may treat tokens as valid even when they rely on token-processing semantics the library did not actually enforce. The vulnerability does not directly expose data or cause service unavailability, but it can undermine authentication or authorization decisions in applications that use JWTs for identity, session, API, or claims-based access control.

Why it matters to the business

Organizations using affected PyJWT versions may make incorrect trust decisions based on tokens that should have been rejected. If an application or identity flow depends on strict JWT/JWS standards compliance, attackers may be able to bypass intended token validation rules, gain unauthorized access, or manipulate authorization outcomes. The CVSS score is high, but current public exploit maturity and EPSS are low, and the vulnerability is not currently listed in CISA KEV; remediation should still be prioritized for internet-facing authentication, API gateway, SSO, and service-to-service authorization paths because successful exploitation affects trust and access control.

How an attack unfolds

An attacker first identifies an application or API that accepts JWTs verified by a vulnerable PyJWT version. They then craft a JWS/JWT containing a crit header array that references one or more critical header extensions not understood by PyJWT. Under the JWS specification, the verifier must reject such a token unless it understands and processes every listed critical extension. Vulnerable PyJWT versions do not perform that rejection. If the token is otherwise structurally valid and signed in a way the target accepts, the application may process it as a valid token while ignoring the declared critical semantics. The practical outcome depends on how the application uses JWT claims and headers: in the worst case, the application accepts a token that should be invalid and grants access or authorizes an action based on improperly validated token state.

How to fix it

Upgrade PyJWT to version 2.12.0 or later everywhere it is used. If PyJWT is included transitively through frameworks, SDKs, or internal packages, update dependency lockfiles and rebuild affected applications. Where immediate upgrade is not possible, add an explicit validation control before accepting tokens: reject any JWT/JWS that contains a crit header unless every listed extension is explicitly supported and correctly processed by the application. Avoid ad hoc token parsing that bypasses library verification. Review authentication and authorization code paths to confirm JWT validation includes expected issuer, audience, expiration, not-before, algorithm allow-listing, signature verification, and application-specific claims validation.

How to confirm the fix worked

Confirm that deployed Python environments resolve PyJWT to 2.12.0 or later using package inventories, software composition analysis, lockfiles, container image scans, and runtime checks such as `python -c "import jwt; print(jwt.__version__)"`. Add a regression test that submits a signed JWT containing a `crit` header with an unknown extension and verifies the application rejects it. Validate that CI/CD dependency checks fail builds for PyJWT versions earlier than 2.12.0. For running services, test representative authentication and API endpoints in a non-production or approved validation environment with a token containing an unsupported critical header and confirm rejection with an authentication/authorization error.

Typical attack path

1. Identify an application, API, or service that accepts JWTs and is likely implemented in Python using PyJWT.
2. Determine accepted token format, signing algorithm, issuer, audience, and validation behavior through documentation, traffic analysis, or probing.
3. Create or obtain a JWT that the target will otherwise accept, such as a token signed with a valid key in a context where the attacker can obtain legitimate tokens.
4. Add a JWS crit header containing an unsupported critical extension name.
5. Submit the token to authentication or authorization endpoints.
6. Observe whether the service accepts the token instead of rejecting it due to the unsupported critical header.
7. Use the accepted token to access protected functionality or perform actions that depend on JWT trust decisions.

How to detect it

Retrospective detection depends on whether applications log request headers, bearer tokens, JWT headers, authentication failures, or decoded token metadata. Review API gateway, reverse proxy, application, identity service, and authentication middleware logs for JWTs whose decoded JOSE header contains a `crit` array. Focus on tokens accepted successfully, not only failed authentication attempts, because vulnerable versions may not log an error. Look for unusual header parameters listed in `crit`, repeated probing with varied critical extension names, successful requests immediately following malformed-token attempts, and access patterns inconsistent with the token subject or normal authorization behavior. If full tokens are unavailable, search security telemetry for decoded JWT header fields, WAF captures, debug logs, or authentication audit records that include `crit`. Also review package deployment timelines: systems running PyJWT prior to 2.12.0 during the period of suspicious access should be treated as potentially exposed. No public named threat actors or ransomware campaigns are currently associated with this vulnerability in the provided data.

• "crit"
• "\"crit\""
• "crit": [
• "crit":[
• "unsupported critical"
• "critical header"
• "jwt.__version__"
• "PyJWT"

What your security team should do

• Inventory all applications, containers, serverless functions, and services that use PyJWT directly or transitively.
• Prioritize upgrades to PyJWT 2.12.0 or later for internet-facing APIs, authentication services, SSO integrations, API gateways, and service-to-service authorization components.
• Add SCA policy gates to block PyJWT versions earlier than 2.12.0 in new builds and dependency updates.
• Implement or verify defensive token validation that rejects unsupported `crit` headers and enforces issuer, audience, expiration, not-before, signature, and algorithm allow-list checks.
• Search authentication and API logs for JWTs containing a `crit` header, especially tokens with unusual or previously unseen critical extension names.
• Review recent authentication anomalies, authorization bypass reports, unexplained privilege changes, and suspicious API access involving JWT-bearing requests.
• Add regression tests for standards-compliant rejection of unsupported critical JWS headers.
• Monitor upstream framework and SDK updates that may bundle or constrain PyJWT versions.