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-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-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-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-102269	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.	MEDIUM	5.4	0.2%	27
CVE-2026-102270	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.	MEDIUM	4.9	0.2%	25

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

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.

MEDIUM

5.4

0.2%

27

CVE-2026-102270

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.

MEDIUM

4.9

0.2%

25

Severity Breakdown

Monthly CVE Trend

Affected Products (3)

Top Risky CVEs