PyJWT is a JSON Web Token implementation in Python. Prior to 2.12.0, PyJWT does not validate the crit (Critical) Header Parameter defined in 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. This violates the MUST requirement in the RFC. This vulnerability is fixed in 2.12.0.
Security readout for executives and security teams
Plain-English summary
PyJWT before 2.12.0 may accept signed tokens that say they require critical handling the library does not understand. In authentication or authorization paths, that can let token integrity assumptions become wrong. The public bundle says the flaw is fixed in 2.12.0 and rates it high severity.
Executive priority
Treat as high priority for systems that depend on JWTs for access control. Patch promptly, starting with public APIs and identity-facing services. The evidence supports integrity risk, but not confirmed active exploitation.
Technical view
PyJWT fails to enforce RFC 7515 section 4.1.11 for the JWS crit header. Tokens containing unknown critical header extensions are accepted instead of rejected. CVSS 3.1 is 7.5, with network attack vector, low complexity, no privileges, no user interaction, and high integrity impact.
Likely exposure
Exposure is likely in Python applications or packaged products that use PyJWT versions below 2.12.0 to validate JWT or JWS input, especially authentication, authorization, session, API, and identity integrations.
Exploitation context
The bundle does not show CISA KEV listing or active exploitation. CVSS indicates remote unauthenticated reachability where vulnerable token validation is exposed. Actual exploitability depends on how the application interprets critical token extensions and authorization decisions.
Researcher notes
The key issue is standards noncompliance: unknown crit extensions must cause rejection. Assess whether applications rely on extension semantics, custom token profiles, or cross-library verification behavior. Do not assume all PyJWT usage is equally exposed.
Mitigation direction
Upgrade PyJWT to version 2.12.0 or later.
Apply fixed vendor packages from Debian, Red Hat, or other applicable distributions.
Prioritize internet-facing authentication and API token validation services.
Review vendor advisories for product-specific remediation status.
Avoid accepting untrusted JWT/JWS tokens through vulnerable validation paths.
Validation and detection
Inventory PyJWT versions in dependency files, SBOMs, containers, and deployed environments.
Confirm runtime environments no longer load PyJWT below 2.12.0.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-345: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
CWE-863: Authorization and privilege behavior lookup
Authorization weaknesses can support privilege escalation and valid-account review, depending on exploit path. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
The CVE wording references authentication or credential exposure, so valid-account and credential-access review may help. This is a Glexia inferred lookup path, not an official MITRE, ATT&CK, or CVE Program mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-345 · source CWE mapping
Insufficient Verification of Data Authenticity
Insufficient Verification of Data Authenticity represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.
Improper Verification of Cryptographic Signature represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.
Incorrect Authorization represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.