PyJWT CVE-2026-102270

Exploitation requires that the attacker control the key/secret material passed into PyJWT's key-preparation path (is_pem_format is invoked when checking whether a supplied key is PEM-formatted). The concrete trigger is a certificate-like input containing repeated '-----BEGIN <label>-----' markers with NO matching END marker, causing the pre-fix lazy regex ('.+?' under re.DOTALL) to backtrack without bound. Limiting factors: PR:H - key material is normally operator/config-controlled, so the vulnerable input is not reachable from unauthenticated request data in typical deployments; AC:H - the input must be specifically crafted to maximize backtracking; affects only PyJWT versions prior to 2.14.0. Impact is availability-only (CPU exhaustion); no data exposure or forgery.

This is a genuine but low-priority issue. The vendor CVSS 3.1 vector (AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H, base 4.4) is internally consistent with a ReDoS: no confidentiality or integrity impact, availability-only, high attack complexity (crafting an input with repeated BEGIN markers and no matching END to force catastrophic backtracking), and high privileges required. The PR:H is the key signal - is_pem_format runs against the key/secret material handed to PyJWT, which in almost all deployments is operator-controlled configuration rather than untrusted request data, so an attacker generally needs privileged control over the key input to reach the vulnerable regex. No EPSS score, no CISA KEV listing, and no public exploit code are present in the input, so exploitation status is 'no public exploit identified at time of analysis.' The signals do not conflict: everything points to a narrow, low-real-risk CPU-exhaustion DoS in an extremely popular library. The ubiquitous deployment of PyJWT does NOT translate to wide exploitability here, because the trigger requires attacker influence over key material - a condition uncommon in typical architectures.

In an application that passes externally-influenced key material into a PyJWT verification/signing path (e.g., a multi-tenant service where users supply their own signing keys or PEM certificates), an attacker submits a crafted certificate-like blob containing many repeated '-----BEGIN PUBLIC KEY-----' markers with no matching END marker. is_pem_format's lazy PEM regex backtracks unboundedly searching for the end marker, pinning a CPU core and degrading or stalling the service. No public POC is identified; the fix commit ships regression tests demonstrating the pathological input (10,000x repeated BEGIN).