CVE-2026-32597: Update PyJWT to 2.12.0 for JWT Crit Fix

Microsoft’s Security Update Guide carries an entry for the CVE, but there is no Microsoft patch to deploy through Windows Update. The affected component is the third-party

package used by Python applications, automation services, API back ends, and identity-adjacent tooling. For Windows administrators, the relevant estate is IIS-hosted Python workloads, Windows Server application services, developer virtual environments, Azure-hosted containers, CI runners, and any packaged product that bundles Python and PyJWT.

GitHub’s PyJWT advisory, published March 12, 2026, rates the issue High with a CVSS 3.1 score of 7.5. NVD and Red Hat describe the same defect: a token can carry a

array naming a header extension the recipient does not understand, yet vulnerable PyJWT versions continue processing the token after a valid signature check. PyJWT 2.12.0 added validation that rejects unsupported critical extensions.

The crit field is supposed to stop silent policy downgrades​

A JWS header can include

, short for critical, to announce extensions whose meaning changes how a recipient must handle the token. The RFC rule is deliberately strict: if a recipient does not understand and process every listed critical header parameter, the JWS is invalid.

That rule exists to prevent one component from treating a token as carrying a mandatory security control while another component quietly ignores it. A token might, for example, declare an extension related to proof-of-possession, multi-factor enforcement, a constrained scope, or a tenant-specific authorization condition. If the extension is critical, software that cannot enforce it must reject the token rather than accept an incomplete interpretation of the issuer’s intent.

Before 2.12.0, PyJWT did not do that. Its decoder parsed the header and verified the signature but did not validate the

declaration. The PyJWT advisory demonstrates a token with an unknown header called

listed under

; vulnerable code accepts the token and returns its claims. An RFC-compliant verifier would reject the same token.

This is not a cryptographic signature break. An attacker does not gain the ability to forge an HS256, RS256, or ES256 token merely by adding

. The signature still has to validate. The risk emerges when a validly signed token reaches a PyJWT-based service that is expected to honor a policy communicated through a critical header extension—or when different parts of a token-processing path use different JWT libraries.

Mixed JWT stacks are where the defect turns into an authorization problem​

The clearest operational scenario is a split-brain verifier arrangement. An API gateway, authentication proxy, or broker may use one library and correctly reject a token because it contains an unknown critical extension. A downstream Windows-hosted Python service using vulnerable PyJWT may accept that same signed token and authorize the request without applying the extension’s security semantics.

That can happen in environments where token issuers, gateways, sidecars, and application services were assembled by different teams or products. It is especially plausible in a service mesh or API-management design where JWT verification happens at more than one tier, but the verification libraries and policy engines differ.

The flaw also deserves attention in products that mint custom JWT headers for internal federation. Many ordinary OAuth 2.0 and OpenID Connect deployments will not use critical JWS extensions at all. In those installations, the vulnerable parser is still noncompliant, but the immediate exploit path may be absent. Administrators should not mistake that narrower exposure for a reason to leave the package unpatched: the application may accept third-party tokens, add custom headers later, or have an upstream component already relying on a critical extension that the back end never enforced.

Red Hat’s advisory gives the CVE the same 7.5 High score and reports no generally suitable mitigation short of remediation. Its product records also show that the issue reached real enterprise dependency chains, including components in Red Hat Ansible Automation Platform. That is a useful warning for Windows teams: a package does not need to be installed directly with

for it to be present. It may arrive inside an automation suite, a management service, a Python SDK, a container base image, or a vendor appliance.

The advisory has a version-range error that can mislead inventory work​

The most important wrinkle in this CVE is not the severity score; it is an inconsistency in the primary records.

GitHub’s PyJWT advisory lists affected versions as earlier than 2.11.0 while also naming 2.12.0 as the patched release. Those two statements cannot both define the complete affected range. PyJWT 2.11.0 was released on January 30, 2026, and its source code still lacks critical-header validation during token decoding. The 2.12.0 source adds

and invokes header validation before signature verification completes. The PyJWT 2.12.0 release notes explicitly identify validation of the RFC 7515

parameter as its security change.

NVD’s CVE record gets the practical boundary right: all versions before 2.12.0 are affected. Debian’s security tracking also lists 2.6.0 as affected and shipped a security update for its 2.10.1 package line. The conclusion is straightforward: treat PyJWT 2.11.0 as vulnerable despite the GitHub advisory’s displayed

affected-version field.

That discrepancy matters for vulnerability management. SBOM scanners, GitHub Advisory Database consumers, dependency dashboards, and internal exception processes do not all normalize advisory data the same way. A rule that keys only on the erroneous

range could incorrectly mark a deployment of PyJWT 2.11.0 as unaffected. Security teams should query installed versions directly rather than accept a green finding at face value.

On a Windows application host or build agent, the quickest checks are typically:

py -m pip show PyJWT
py -m pip freeze | Select-String -Pattern '^PyJWT=='

For each application-specific virtual environment, run the commands through that environment’s interpreter rather than the system Python launcher. For containers, inspect the built image or generate an SBOM from the final image layer; checking only the source repository’s requirements file will miss transitive dependencies and pinned wheel bundles.

Upgrade to PyJWT 2.12.0 at minimum, but test 2.13.0 deliberately​

PyJWT 2.12.0, released March 12, 2026, is the minimum upstream version that fixes CVE-2026-32597. PyJWT 2.12.1 followed on March 13 with a Python compatibility dependency correction. The current upstream release, PyJWT 2.13.0 from May 21, contains the

fix and bundles several later security fixes and RFC-compliance changes.

For a narrowly scoped emergency remediation, upgrading an affected application to 2.12.1 or later removes this CVE. For a normal maintenance cycle, PyJWT 2.13.0 is the better target because it addresses additional token-verification and JWKS-handling weaknesses disclosed after 2.12.0.

However, 2.13.0 is not a zero-behavior-change upgrade. Its release notes say it now rejects empty HMAC secrets, enforces consistency between a token’s

header and a

algorithm, blocks non-HTTP(S) JWKS URLs, and tightens handling of detached

JWS payloads. Those changes close real security gaps, but a test environment may expose applications that were relying on an empty environment variable, a

JWKS source, or malformed detached tokens.

A practical remediation sequence is:

• Identify every installed PyJWT version, including versions inside virtual environments, containers, application bundles, and vendor-supported products.
• Treat all PyJWT releases through 2.11.0 as affected, regardless of any scanner result derived solely from GitHub’s inconsistent range.
• Upgrade to 2.12.0 or later immediately, then schedule compatibility validation for 2.13.0 where it is not already deployed.
• Test token issuance and validation flows with your actual identity provider, gateway, JWKS source, permitted signing algorithms, and any detached-payload JWS use.
• Review whether your organization uses custom JWT headers to signal mandatory policy. If it does, verify every component rejects tokens whose critical extensions it cannot enforce.

Microsoft’s listing should trigger dependency triage, not Patch Tuesday workflow​

The submitted MSRC entry risks sending administrators toward the wrong operational queue. This is not a KB-numbered Windows update, a Microsoft service-side remediation, or a vulnerability that Endpoint Manager can close by applying a cumulative update. It is an application dependency issue whose owner may be a development team, platform engineering group, product vendor, or managed-service provider.

The immediate consequence is simple: any Windows-hosted service that verifies JWTs with PyJWT 2.11.0 or older should be treated as needing an application update. The tougher work is proving where PyJWT is embedded and ensuring that scanners do not clear version 2.11.0 based on the GitHub advisory’s faulty affected-version boundary.

References​

1. Primary source: MSRC
   Published: August 8, 2026 at 8:40 AM UTC
   
   

   Security Update Guide - Microsoft Security Response Center

   msrc.microsoft.com
2. Related coverage: nvd.nist.gov
   
   https://nvd.nist.gov/vuln/detail/CVE-2026-32597
3. Related coverage: notcve.org
   
   

   CVE-2026-32597 - PyJWT accepts unknown `crit` header extensions (RFC 7515 §4.1.11 MUST violation)

   Public exploit available. Patch available. 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 MUS…

   notcve.org
4. Related coverage: advisories.gitlab.com
   

   PyJWT accepts unknown `crit` header extensions | GitLab Advisory Database (GLAD)

   CVE-2026-32597 PyJWT accepts unknown `crit` header extensions: PyJWT does not validate the crit (Critical) Header Parameter defined in RFC 7515 §4.1.11. When a JWS token contains a crit array …

   advisories.gitlab.com
5. Related coverage: github.com
   
   

   Security Advisories · jpadilla/pyjwt · GitHub

   GitHub is where people build software. More than 150 million people use GitHub to discover, fork, and contribute to over 420 million projects.

   github.com
6. Related coverage: github.com
   
   

   Releases · jpadilla/pyjwt · GitHub

   JSON Web Token implementation in Python. Contribute to jpadilla/pyjwt development by creating an account on GitHub.

   github.com
7. Related coverage: advisories.gitlab.com
   
   Pypi/PyJWT | GitLab Advisory Database (GLAD)
8. Related coverage: msrc.microsoft.com
   
   

   Security Update Guide - Microsoft Security Response Center

   msrc.microsoft.com
9. Related coverage: cvefeed.io
   
   

   CVE-2026-32597 - PyJWT accepts unknown `crit` header extensions (RFC 7515 §4.1.11 MUST violation)

   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...

   cvefeed.io
10. Related coverage: security.glexia.com
    
    

    CVE-2026-32597: jpadilla pyjwt vulnerability | Glexia

    CVE-2026-32597 is a High severity, CVSS 7.5. Affecting jpadilla pyjwt. Review impact, affected versions, remediation priorities, CWE and ATT&CK context.

    security.glexia.com
11. Related coverage: pyjwt.readthedocs.io
    
    https://pyjwt.readthedocs.io/_/downloads/en/2.8.0/pdf
12. Related coverage: vulert.com
    
    

    CVE-2026-32597: PyJWT Accepts Unknown crit Header Extensions Leading to Security Bypass

    Learn about CVE-2026-32597, a vulnerability in PyJWT that allows acceptance of unknown crit header extensions, leading to security bypasses. Update to version 2.12.0 or later to mitigate risks.

    vulert.com
13. Related coverage: vulmon.com
    
    

    CVE-2026-32597 - Missing `crit` Header Validation in PyJWT…

    Missing `crit` Header Validation in PyJWT Prior to 2.12.0. PyJWT, a Python implementation of JSON Web Tokens, prior to version 2.12.0 fails to validate the crit…

    www.vulmon.com
14. Related coverage: cvereports.hashnode.dev
    
    

    CVE-2026-32597: CVE-2026-32597: Critical Header Parameter Validation Bypass in PyJWT

    CVE-2026-32597: Critical Header Parameter Validation Bypass in PyJWT Vulnerability ID: CVE-2026-32597 CVSS Score: 7.5 Published: March 12, 2026 PyJWT versions prior to 2.12.0 fail to validate the crit (Critical) Header Parameter as mandated by RFC 7515...

    cvereports.hashnode.dev
15. Related coverage: secure.software
    
    

    [email protected] - PyPI | ReversingLabs Spectra Assure Community

    Supply chain risk analysis for [email protected]. Learn more about package security, deployment risks, vulnerabilities, popularity, versions, and more with ReversingLabs.

    secure.software