Jpadilla

CVE	Summary	Severity	CVSS	EPSS	Priority	Signals
CVE-2026-102266	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).	CRITICAL	9.1	0.2%	66	PoC
CVE-2026-102275	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.	HIGH	8.2	0.1%	61	PoC
CVE-2026-102274	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.	HIGH	7.5	0.4%	58	PoC
CVE-2026-101918	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.	HIGH	7.5	0.3%	58	PoC
CVE-2026-48526	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.	HIGH	7.4	0.0%	57	PoC
CVE-2026-103001	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.	MEDIUM	6.5	0.4%	53	PoC
CVE-2026-102265	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.	MEDIUM	5.3	0.3%	47	PoC
CVE-2026-48525	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.	MEDIUM	5.3	0.0%	47	PoC
CVE-2026-102268	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.	CRITICAL	9.1	0.2%	46
CVE-2026-102267	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.	CRITICAL	9.1	0.2%	46
CVE-2026-48524	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.	LOW	3.7	0.0%	39	PoC
CVE-2026-101917	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.	HIGH	7.5	0.4%	38
CVE-2026-102272	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.	HIGH	7.4	0.2%	37
CVE-2026-102271	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.	HIGH	7.4	0.2%	37
CVE-2026-102273	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.	HIGH	7.4	0.2%	37

CVE-2026-102266

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

CRITICAL

9.1

0.2%

66

PoC

CVE-2026-102275

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.

HIGH

8.2

0.1%

61

PoC

CVE-2026-102274

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.

HIGH

7.5

0.4%

58

PoC

CVE-2026-101918

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.

HIGH

7.5

0.3%

58

PoC

CVE-2026-48526

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.

HIGH

7.4

0.0%

57

PoC

CVE-2026-103001

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.

MEDIUM

6.5

0.4%

53

PoC

CVE-2026-102265

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.

MEDIUM

5.3

0.3%

47

PoC

CVE-2026-48525

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.

MEDIUM

5.3

0.0%

47

PoC

CVE-2026-102268

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.

CRITICAL

9.1

0.2%

46

CVE-2026-102267

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.

CRITICAL

9.1

0.2%

46

CVE-2026-48524

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.

LOW

3.7

0.0%

39

PoC

CVE-2026-101917

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.

HIGH

7.5

0.4%

38

CVE-2026-102272

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.

HIGH

7.4

0.2%

37

CVE-2026-102271

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.

HIGH

7.4

0.2%

37

CVE-2026-102273

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.

HIGH

7.4

0.2%

37

Severity Breakdown

Monthly CVE Trend

Affected Products (3)

Top Risky CVEs