Jpadilla
Monthly
Improper validation in PyJWT 2.1.0 through 2.14.0 allows an attacker who already holds a stolen sender-constrained (DPoP-bound) access token to replay it without possessing the legitimate holder's private key, because OKPAlgorithm.from_jwk imports an Ed25519/Ed448 private JWK from the d parameter without checking that the public key derived from d matches the declared x. An attacker-supplied JWK that pairs the victim's x with the attacker's own d therefore satisfies RFC 7638 thumbprint binding (cnf.jkt) while all signing operations use the attacker's key. Publicly available exploit code exists (a public gist reproducer), but EPSS is only 0.14% (3rd percentile) and there is no KEV listing - this is a conditional, integration-dependent flaw rather than a default-configuration remote compromise, and standard signature-verification use of PyJWT with trusted server-side keys is not affected.
Denial of service in PyJWT 2.9.0 through 2.13.0: a single malformed RSA JWK embedded in a JWK Set aborts construction of the entire set, causing authentication failures or request-level outages for applications that rely on that key set. The root cause is PyJWKSet's per-key error-skipping logic, which only catches PyJWTError and therefore misses the plain ValueError raised by RSAAlgorithm.from_jwk when an RSA key supplies d/e/n with an incorrect private exponent and omits the CRT parameters. The issue is remotely reachable without authentication or user interaction (CVSS 7.5, AV:N/AC:L/PR:N/UI:N, availability-only), publicly available exploit code exists (no confirmed active exploitation), EPSS is low at 0.35% (26th percentile), and the vendor-released patch is version 2.14.0.
Signature forgery in PyJWT 2.13.0 lets an attacker forge arbitrary JWT claims when an application verifies tokens using both HMAC and asymmetric algorithms and hands a public JWK container (a JWKS document, a bare array, a nested array, or a BOM-prefixed variant) directly to the library as the raw key. Because the version 2.13.0 HMAC key guard only recognizes top-level public JWK objects and misses these container wrappers, public asymmetric key material - which is not secret - is accepted as the HMAC secret, so anyone who knows the target's public key can sign a token with any claims and have it validate. The flaw is an improper-signature-verification issue (CWE-347) rated CVSS 3.1 7.4 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N) and unauthenticated in the sense that no credentials are needed, but real-world urgency is lower than the headline score: exploitation requires a non-default application design that mixes algorithm families and passes container-form keys, and no public exploit code or confirmed active exploitation was identified at time of analysis. Vendor-released patch: PyJWT 2.14.0.
Token forgery in PyJWT 2.13.x lets unauthenticated remote attackers mint tokens that the library will accept as authentic: when a public JWK is prefixed with a UTF-8 byte-order mark and passed directly as the raw HMAC secret inside a mixed-algorithm verification path, HMACAlgorithm.prepare_key fails to recognize the material as an asymmetric key and uses the publicly known JWK bytes as the shared secret, so anyone who knows the public key can sign arbitrary claims that verify successfully. The flaw carries an assessed CVSS of 7.4 (integrity-only impact, AC:H, PR:N) and per our independent assessment is conditionally scoped: it requires PyJWT 2.13.0 through 2.13.x, an application that permits HMAC alongside asymmetric algorithms, code that hands a raw public JWK to prepare_key instead of loading it via PyJWK/HMACAlgorithm.from_jwk, and BOM-prefixed key material. No public exploit code was identified at time of analysis and the issue is not in CISA KEV; the vendor-released patch is 2.14.0.
Signature forgery in the PyJWT Python library (versions 2.4.0 through 2.13.x) lets a remote, unauthenticated attacker mint forged HMAC tokens whenever an application is misconfigured to accept both HMAC and asymmetric algorithms and passes a DER-encoded public key as the shared verification secret. PyJWT's HMACAlgorithm.prepare_key only rejected PEM- and SSH-formatted asymmetric keys using textual markers, so a DER public key (SubjectPublicKeyInfo, PKCS1, or a DER x509 certificate) slipped through and its public bytes were used directly as the HMAC secret - meaning anyone who knows the public key can sign valid tokens. The flaw is rated CVSS 7.4 with High attack complexity precisely because it requires that specific non-default application configuration; no public exploit code has been identified at time of analysis, and the vendor-released patch is PyJWT 2.14.0.
Signature forgery in PyJWT before 2.14.0 allows an attacker who knows a target's asymmetric public key to forge HMAC-authenticated JWTs when the application mixes HMAC and asymmetric algorithms and passes asymmetric public-key PEM bytes into HMAC verification. The flaw is in is_pem_format in jwt/utils.py, which fails to recognize all PEM formatting variants accepted by the cryptography loader, causing HMACAlgorithm.prepare_key to treat a mutated public-key PEM as an HMAC secret. Exploitation requires a specific non-default deployment pattern-mixed algorithm verification with raw PEM key bytes-and the assessed CVSS vector is AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N; no public exploit identified at time of analysis, and no CISA KEV status was provided.
JWKS trust-boundary bypass in PyJWT's PyJWKClient allows a configured trusted JWKS endpoint that returns an HTTP 3xx redirect to steer the client to an attacker-chosen host, which is then consumed as authoritative key material; the same mechanism can forward caller-supplied request headers such as Authorization to that destination. Only PyJWT 2.13.0 and earlier are affected (fixed in 2.14.0), and exploitation is not unconditional: it requires the application to actually use PyJWKClient for remote JWKS fetching, attacker influence over the trusted endpoint's redirect response, and - for credential leakage - caller-supplied headers passed into the client, or - for forged-JWT acceptance - a mixed-configuration deployment. There is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis; EPSS is low at 0.16% (4th percentile), and CISA SSVC rates Exploitation as 'none' and Automatable as 'no', so the practical risk sits well below the headline 9.1 base score.
Forged HS256 JSON Web Tokens can be accepted as authentic by PyJWT (pip package PyJWT) versions 2.13.0 through 2.13.x when an application verifies tokens through the PyJWK or PyJWKSet path and its trusted JWK Set already contains a symmetric oct entry with an empty key value ({"kty":"oct","k":""}), an unusual precondition typically caused by a missing Base64URL configuration or secret-manager value. Because the PyJWK verification path passes the decoded zero-length key straight to the HMAC check instead of running it through HMACAlgorithm.prepare_key, unauthenticated remote attackers (CVSS PR:N) who know this pre-existing misconfiguration can independently compute HMAC-SHA256(b"", signing_input) and mint valid tokens carrying arbitrary authenticated claims, giving high confidentiality and integrity impact. Public proof-of-concept exploit code exists, but the issue is not in CISA KEV, EPSS is low at 0.18% (6th percentile), and the independent assessment rates attack complexity as High rather than Low, so the headline CVSS 9.1 overstates real-world urgency; the vendor-released patch is version 2.14.0 (commit f91ed44dd65baaf457f4b3353ed35e98a753934c).
Unauthenticated denial of service in the PyJWT Python library (versions 2.0.0a1 through 2.14.0) allows a remote attacker to crash the calling application's authentication handler by supplying a JWT whose payload is valid JSON but nested roughly 20,000 levels deep. The vulnerable code paths - PyJWKClient.get_signing_key_from_jwt(), the documented JWKS verification flow, and any jwt.decode(token, options={"verify_signature": False}) call - parse the attacker-controlled payload with json.loads before any signature check, and a catch clause that handles only ValueError lets RecursionError escape as an undocumented exception (CWE-248), producing an HTTP 500 or dead worker with no credentials, valid signature, user interaction, or JWKS network lookup required. Publicly available exploit code exists (a PoC gist is referenced in the advisory data) and CISA's SSVC assessment rates the issue as automatable with partial technical impact; EPSS is low at 0.29% (20th percentile) and there is no indication of confirmed active exploitation. Impact is confined to availability - no data exposure, integrity loss, or code execution.
Unauthenticated attackers can amplify outbound HTTP traffic from any application that validates JWTs with PyJWT's PyJWKClient against a remote JWKS endpoint, because prior to 2.14.0 an unknown 'kid' in the token header forces a full JWKS refresh on every call with no negative cache or minimum refresh interval. One attacker request produces one outbound JWKS fetch plus full JSON parsing on the victim server, and because the 'kid' is read from the unverified token header, no valid token or authentication is required - even enabling key caching does not help, since a repeated identical unknown 'kid' re-fetches every time. A verified proof-of-concept exists (CISA SSVC records exploitation as 'poc', no CISA KEV listing), so this is treated as publicly available exploit code; EPSS is low (0.35%, 27th percentile). The issue is fixed in 2.14.0, which introduces a 30-second cooldown between forced refreshes.
Authentication bypass in PyJWT versions prior to 2.13.0 allows remote attackers to forge valid JSON Web Tokens by exploiting an algorithm confusion flaw where the library fails to validate that a JSON Web Key intended for asymmetric verification is not reused as an HMAC shared secret. An attacker who knows the issuer's public key (typically distributed openly via JWKS endpoints) can sign HMAC-algorithm tokens with that public key and have them accepted as legitimate. No public exploit identified at time of analysis, though the underlying algorithm-confusion class is a well-documented JWT attack pattern.
Reuse of a caller-supplied options mapping in PyJWT 2.11.0 through 2.13.0 can silently leave registered-claim verification disabled on subsequent decode calls, allowing a correctly signed but otherwise invalid token to be accepted. When an application first calls decode() or decode_complete() with a mutable options mapping containing verify_signature set to false, PyJWT._merge_options() mutates that same mapping in place, writing verify_exp, verify_nbf, verify_iat, verify_aud, verify_iss, verify_sub, and verify_jti to false; if the application then reuses that identical mapping for a later call after flipping verify_signature to true, the stale false flags persist and expired, not-yet-valid, wrong-audience, wrong-issuer, or wrong-subject tokens are accepted even though signature verification is nominally on. This is a conditional integrity flaw rather than a signature bypass, it is reachable by unauthenticated remote attackers (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:N) but only in applications that reuse a mutable options mapping, and no public exploit code or confirmed active exploitation was identified at time of analysis.
Malformed JSON Web Token headers can cause an uncaught RecursionError in PyJWT 2.13.0 through versions before 2.14.0, resulting in HTTP 500 for the request handling the token. Unauthenticated remote attackers can trigger the condition by sending a deeply nested JWS header to an application that calls jwt.decode or PyJWS.decode on untrusted token input. No public exploit identified at time of analysis; the assessed CVSS 3.1 score is 5.3 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L), making this a bounded availability impact rather than a confidentiality or integrity compromise.
CPU-exhaustion denial of service in PyJWT versions prior to 2.14.0, where the lazy PEM-detection regular expression used by is_pem_format() backtracks without bound on certificate-like input containing repeated '-----BEGIN <label>-----' markers and no matching END marker. The flaw is reachable only through the key-preparation path (the key/secret material supplied to PyJWT for verification/signing), which in normal deployments is operator- or configuration-controlled; the assessed vector accordingly requires high privileges (PR:H) and a specifically crafted input (AC:H), and impact is limited to availability with no confidentiality or integrity effect. No public exploit code has been identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV), but a vendor fix exists and the issue was publicly disclosed, so unpatched instances should be upgraded promptly given the trivial resource-consumption nature of ReDoS bugs once a trigger is known.
PyJWT versions prior to 2.14.0 accept signature segments that are not canonical Base64URL, so a token whose compact JWS signature has non-alphabet characters appended still decodes to the same signature bytes and passes verification. The practical impact is limited: an attacker who already holds a valid-but-revoked token can craft an equivalent serialized string that bypasses revocation or blocklisting logic which matches on the raw token string rather than a claim such as jti. This is a low-severity defense-in-depth flaw (assessed CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N) that requires the application to compare raw serialized tokens for revocation. No public exploit identified at time of analysis.
Uncontrolled resource consumption in PyJWT 2.8.0-2.12.1 exposes any service that verifies detached JWS tokens to unauthenticated denial-of-service. When the unencoded-payload extension (b64=false, RFC 7797) is in use, PyJWT unnecessarily Base64URL-decodes the compact-serialization payload segment before discarding it in favor of the caller-supplied detached payload - turning that segment into an attacker-controlled amplifier for CPU and memory exhaustion regardless of signature validity. No public exploit has been identified at time of analysis, but the CVSS vector (AV:N/AC:L/PR:N/UI:N) confirms fully unauthenticated remote exploitation against any affected endpoint using this feature.
Algorithm allow-list bypass in PyJWT 2.9.0-2.12.1 permits an attacker who controls a registered JWK/JWKS private key to circumvent caller-enforced algorithm restrictions during JWT signature verification. The library correctly checks the token header's alg claim against the caller-supplied allow-list, but then performs the actual cryptographic verification using the algorithm bound to the PyJWK object rather than the header-declared algorithm - creating a exploitable mismatch. Specifically, the documented PyJWKClient.get_signing_key_from_jwt() flow is affected, meaning applications relying on this pattern for algorithm-restricted JWT validation may accept tokens signed with algorithms they explicitly prohibited. No public exploit has been identified at time of analysis and the vulnerability is not listed in CISA KEV.
Unconstrained outbound JWKS requests in PyJWT's PyJWKClient.get_signing_key() allow unauthenticated remote attackers to amplify HTTP traffic toward a downstream JWKS endpoint by submitting JWTs carrying arbitrary, unrecognized kid values. All PyJWT versions prior to 2.13.0 are affected when the PyJWKClient class is used for signature verification. The availability impact is low (CVSS A:L) and exploitation success is gated on the upstream JWKS provider exhibiting rate limiting or transient failures; no public exploit code exists and this CVE does not appear in CISA KEV.
PyJWKClient in PyJWT prior to 2.13.0 passes attacker-influenced URIs directly to Python's urllib.request.urlopen() without restricting URI schemes, enabling Server-Side Request Forgery (SSRF) across file://, FTP, and data-URI schemes against applications that accept untrusted jku values. Affected deployments include any Python application using PyJWKClient where the jku URL originates from a JWT header, OAuth flow parameter, or externally influenced configuration. No public exploit exists and no CISA KEV listing is present; real-world exploitation is constrained by a CVSS-confirmed high attack complexity (AC:H) and required user interaction (UI:R), making opportunistic mass exploitation unlikely.
Improper validation in PyJWT 2.1.0 through 2.14.0 allows an attacker who already holds a stolen sender-constrained (DPoP-bound) access token to replay it without possessing the legitimate holder's private key, because OKPAlgorithm.from_jwk imports an Ed25519/Ed448 private JWK from the d parameter without checking that the public key derived from d matches the declared x. An attacker-supplied JWK that pairs the victim's x with the attacker's own d therefore satisfies RFC 7638 thumbprint binding (cnf.jkt) while all signing operations use the attacker's key. Publicly available exploit code exists (a public gist reproducer), but EPSS is only 0.14% (3rd percentile) and there is no KEV listing - this is a conditional, integration-dependent flaw rather than a default-configuration remote compromise, and standard signature-verification use of PyJWT with trusted server-side keys is not affected.
Denial of service in PyJWT 2.9.0 through 2.13.0: a single malformed RSA JWK embedded in a JWK Set aborts construction of the entire set, causing authentication failures or request-level outages for applications that rely on that key set. The root cause is PyJWKSet's per-key error-skipping logic, which only catches PyJWTError and therefore misses the plain ValueError raised by RSAAlgorithm.from_jwk when an RSA key supplies d/e/n with an incorrect private exponent and omits the CRT parameters. The issue is remotely reachable without authentication or user interaction (CVSS 7.5, AV:N/AC:L/PR:N/UI:N, availability-only), publicly available exploit code exists (no confirmed active exploitation), EPSS is low at 0.35% (26th percentile), and the vendor-released patch is version 2.14.0.
Signature forgery in PyJWT 2.13.0 lets an attacker forge arbitrary JWT claims when an application verifies tokens using both HMAC and asymmetric algorithms and hands a public JWK container (a JWKS document, a bare array, a nested array, or a BOM-prefixed variant) directly to the library as the raw key. Because the version 2.13.0 HMAC key guard only recognizes top-level public JWK objects and misses these container wrappers, public asymmetric key material - which is not secret - is accepted as the HMAC secret, so anyone who knows the target's public key can sign a token with any claims and have it validate. The flaw is an improper-signature-verification issue (CWE-347) rated CVSS 3.1 7.4 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N) and unauthenticated in the sense that no credentials are needed, but real-world urgency is lower than the headline score: exploitation requires a non-default application design that mixes algorithm families and passes container-form keys, and no public exploit code or confirmed active exploitation was identified at time of analysis. Vendor-released patch: PyJWT 2.14.0.
Token forgery in PyJWT 2.13.x lets unauthenticated remote attackers mint tokens that the library will accept as authentic: when a public JWK is prefixed with a UTF-8 byte-order mark and passed directly as the raw HMAC secret inside a mixed-algorithm verification path, HMACAlgorithm.prepare_key fails to recognize the material as an asymmetric key and uses the publicly known JWK bytes as the shared secret, so anyone who knows the public key can sign arbitrary claims that verify successfully. The flaw carries an assessed CVSS of 7.4 (integrity-only impact, AC:H, PR:N) and per our independent assessment is conditionally scoped: it requires PyJWT 2.13.0 through 2.13.x, an application that permits HMAC alongside asymmetric algorithms, code that hands a raw public JWK to prepare_key instead of loading it via PyJWK/HMACAlgorithm.from_jwk, and BOM-prefixed key material. No public exploit code was identified at time of analysis and the issue is not in CISA KEV; the vendor-released patch is 2.14.0.
Signature forgery in the PyJWT Python library (versions 2.4.0 through 2.13.x) lets a remote, unauthenticated attacker mint forged HMAC tokens whenever an application is misconfigured to accept both HMAC and asymmetric algorithms and passes a DER-encoded public key as the shared verification secret. PyJWT's HMACAlgorithm.prepare_key only rejected PEM- and SSH-formatted asymmetric keys using textual markers, so a DER public key (SubjectPublicKeyInfo, PKCS1, or a DER x509 certificate) slipped through and its public bytes were used directly as the HMAC secret - meaning anyone who knows the public key can sign valid tokens. The flaw is rated CVSS 7.4 with High attack complexity precisely because it requires that specific non-default application configuration; no public exploit code has been identified at time of analysis, and the vendor-released patch is PyJWT 2.14.0.
Signature forgery in PyJWT before 2.14.0 allows an attacker who knows a target's asymmetric public key to forge HMAC-authenticated JWTs when the application mixes HMAC and asymmetric algorithms and passes asymmetric public-key PEM bytes into HMAC verification. The flaw is in is_pem_format in jwt/utils.py, which fails to recognize all PEM formatting variants accepted by the cryptography loader, causing HMACAlgorithm.prepare_key to treat a mutated public-key PEM as an HMAC secret. Exploitation requires a specific non-default deployment pattern-mixed algorithm verification with raw PEM key bytes-and the assessed CVSS vector is AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N; no public exploit identified at time of analysis, and no CISA KEV status was provided.
JWKS trust-boundary bypass in PyJWT's PyJWKClient allows a configured trusted JWKS endpoint that returns an HTTP 3xx redirect to steer the client to an attacker-chosen host, which is then consumed as authoritative key material; the same mechanism can forward caller-supplied request headers such as Authorization to that destination. Only PyJWT 2.13.0 and earlier are affected (fixed in 2.14.0), and exploitation is not unconditional: it requires the application to actually use PyJWKClient for remote JWKS fetching, attacker influence over the trusted endpoint's redirect response, and - for credential leakage - caller-supplied headers passed into the client, or - for forged-JWT acceptance - a mixed-configuration deployment. There is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis; EPSS is low at 0.16% (4th percentile), and CISA SSVC rates Exploitation as 'none' and Automatable as 'no', so the practical risk sits well below the headline 9.1 base score.
Forged HS256 JSON Web Tokens can be accepted as authentic by PyJWT (pip package PyJWT) versions 2.13.0 through 2.13.x when an application verifies tokens through the PyJWK or PyJWKSet path and its trusted JWK Set already contains a symmetric oct entry with an empty key value ({"kty":"oct","k":""}), an unusual precondition typically caused by a missing Base64URL configuration or secret-manager value. Because the PyJWK verification path passes the decoded zero-length key straight to the HMAC check instead of running it through HMACAlgorithm.prepare_key, unauthenticated remote attackers (CVSS PR:N) who know this pre-existing misconfiguration can independently compute HMAC-SHA256(b"", signing_input) and mint valid tokens carrying arbitrary authenticated claims, giving high confidentiality and integrity impact. Public proof-of-concept exploit code exists, but the issue is not in CISA KEV, EPSS is low at 0.18% (6th percentile), and the independent assessment rates attack complexity as High rather than Low, so the headline CVSS 9.1 overstates real-world urgency; the vendor-released patch is version 2.14.0 (commit f91ed44dd65baaf457f4b3353ed35e98a753934c).
Unauthenticated denial of service in the PyJWT Python library (versions 2.0.0a1 through 2.14.0) allows a remote attacker to crash the calling application's authentication handler by supplying a JWT whose payload is valid JSON but nested roughly 20,000 levels deep. The vulnerable code paths - PyJWKClient.get_signing_key_from_jwt(), the documented JWKS verification flow, and any jwt.decode(token, options={"verify_signature": False}) call - parse the attacker-controlled payload with json.loads before any signature check, and a catch clause that handles only ValueError lets RecursionError escape as an undocumented exception (CWE-248), producing an HTTP 500 or dead worker with no credentials, valid signature, user interaction, or JWKS network lookup required. Publicly available exploit code exists (a PoC gist is referenced in the advisory data) and CISA's SSVC assessment rates the issue as automatable with partial technical impact; EPSS is low at 0.29% (20th percentile) and there is no indication of confirmed active exploitation. Impact is confined to availability - no data exposure, integrity loss, or code execution.
Unauthenticated attackers can amplify outbound HTTP traffic from any application that validates JWTs with PyJWT's PyJWKClient against a remote JWKS endpoint, because prior to 2.14.0 an unknown 'kid' in the token header forces a full JWKS refresh on every call with no negative cache or minimum refresh interval. One attacker request produces one outbound JWKS fetch plus full JSON parsing on the victim server, and because the 'kid' is read from the unverified token header, no valid token or authentication is required - even enabling key caching does not help, since a repeated identical unknown 'kid' re-fetches every time. A verified proof-of-concept exists (CISA SSVC records exploitation as 'poc', no CISA KEV listing), so this is treated as publicly available exploit code; EPSS is low (0.35%, 27th percentile). The issue is fixed in 2.14.0, which introduces a 30-second cooldown between forced refreshes.
Authentication bypass in PyJWT versions prior to 2.13.0 allows remote attackers to forge valid JSON Web Tokens by exploiting an algorithm confusion flaw where the library fails to validate that a JSON Web Key intended for asymmetric verification is not reused as an HMAC shared secret. An attacker who knows the issuer's public key (typically distributed openly via JWKS endpoints) can sign HMAC-algorithm tokens with that public key and have them accepted as legitimate. No public exploit identified at time of analysis, though the underlying algorithm-confusion class is a well-documented JWT attack pattern.
Reuse of a caller-supplied options mapping in PyJWT 2.11.0 through 2.13.0 can silently leave registered-claim verification disabled on subsequent decode calls, allowing a correctly signed but otherwise invalid token to be accepted. When an application first calls decode() or decode_complete() with a mutable options mapping containing verify_signature set to false, PyJWT._merge_options() mutates that same mapping in place, writing verify_exp, verify_nbf, verify_iat, verify_aud, verify_iss, verify_sub, and verify_jti to false; if the application then reuses that identical mapping for a later call after flipping verify_signature to true, the stale false flags persist and expired, not-yet-valid, wrong-audience, wrong-issuer, or wrong-subject tokens are accepted even though signature verification is nominally on. This is a conditional integrity flaw rather than a signature bypass, it is reachable by unauthenticated remote attackers (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:N) but only in applications that reuse a mutable options mapping, and no public exploit code or confirmed active exploitation was identified at time of analysis.
Malformed JSON Web Token headers can cause an uncaught RecursionError in PyJWT 2.13.0 through versions before 2.14.0, resulting in HTTP 500 for the request handling the token. Unauthenticated remote attackers can trigger the condition by sending a deeply nested JWS header to an application that calls jwt.decode or PyJWS.decode on untrusted token input. No public exploit identified at time of analysis; the assessed CVSS 3.1 score is 5.3 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L), making this a bounded availability impact rather than a confidentiality or integrity compromise.
CPU-exhaustion denial of service in PyJWT versions prior to 2.14.0, where the lazy PEM-detection regular expression used by is_pem_format() backtracks without bound on certificate-like input containing repeated '-----BEGIN <label>-----' markers and no matching END marker. The flaw is reachable only through the key-preparation path (the key/secret material supplied to PyJWT for verification/signing), which in normal deployments is operator- or configuration-controlled; the assessed vector accordingly requires high privileges (PR:H) and a specifically crafted input (AC:H), and impact is limited to availability with no confidentiality or integrity effect. No public exploit code has been identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV), but a vendor fix exists and the issue was publicly disclosed, so unpatched instances should be upgraded promptly given the trivial resource-consumption nature of ReDoS bugs once a trigger is known.
PyJWT versions prior to 2.14.0 accept signature segments that are not canonical Base64URL, so a token whose compact JWS signature has non-alphabet characters appended still decodes to the same signature bytes and passes verification. The practical impact is limited: an attacker who already holds a valid-but-revoked token can craft an equivalent serialized string that bypasses revocation or blocklisting logic which matches on the raw token string rather than a claim such as jti. This is a low-severity defense-in-depth flaw (assessed CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N) that requires the application to compare raw serialized tokens for revocation. No public exploit identified at time of analysis.
Uncontrolled resource consumption in PyJWT 2.8.0-2.12.1 exposes any service that verifies detached JWS tokens to unauthenticated denial-of-service. When the unencoded-payload extension (b64=false, RFC 7797) is in use, PyJWT unnecessarily Base64URL-decodes the compact-serialization payload segment before discarding it in favor of the caller-supplied detached payload - turning that segment into an attacker-controlled amplifier for CPU and memory exhaustion regardless of signature validity. No public exploit has been identified at time of analysis, but the CVSS vector (AV:N/AC:L/PR:N/UI:N) confirms fully unauthenticated remote exploitation against any affected endpoint using this feature.
Algorithm allow-list bypass in PyJWT 2.9.0-2.12.1 permits an attacker who controls a registered JWK/JWKS private key to circumvent caller-enforced algorithm restrictions during JWT signature verification. The library correctly checks the token header's alg claim against the caller-supplied allow-list, but then performs the actual cryptographic verification using the algorithm bound to the PyJWK object rather than the header-declared algorithm - creating a exploitable mismatch. Specifically, the documented PyJWKClient.get_signing_key_from_jwt() flow is affected, meaning applications relying on this pattern for algorithm-restricted JWT validation may accept tokens signed with algorithms they explicitly prohibited. No public exploit has been identified at time of analysis and the vulnerability is not listed in CISA KEV.
Unconstrained outbound JWKS requests in PyJWT's PyJWKClient.get_signing_key() allow unauthenticated remote attackers to amplify HTTP traffic toward a downstream JWKS endpoint by submitting JWTs carrying arbitrary, unrecognized kid values. All PyJWT versions prior to 2.13.0 are affected when the PyJWKClient class is used for signature verification. The availability impact is low (CVSS A:L) and exploitation success is gated on the upstream JWKS provider exhibiting rate limiting or transient failures; no public exploit code exists and this CVE does not appear in CISA KEV.
PyJWKClient in PyJWT prior to 2.13.0 passes attacker-influenced URIs directly to Python's urllib.request.urlopen() without restricting URI schemes, enabling Server-Side Request Forgery (SSRF) across file://, FTP, and data-URI schemes against applications that accept untrusted jku values. Affected deployments include any Python application using PyJWKClient where the jku URL originates from a JWT header, OAuth flow parameter, or externally influenced configuration. No public exploit exists and no CISA KEV listing is present; real-world exploitation is constrained by a CVSS-confirmed high attack complexity (AC:H) and required user interaction (UI:R), making opportunistic mass exploitation unlikely.