PyJWT versions from 2.13.0 up to but not including 2.14.0 contain a vulnerability in the HMACAlgorithm.prepare_key function. The issue arises because the HMAC key guard only recognizes top-level public JWK forms and misses container representations, allowing public asymmetric key material to be accepted as the HMAC secret. This flaw enables an attacker who knows the public key to forge tokens with arbitrary authenticated claims. The vulnerability is fixed in version 2.14.0.
PyJWT version 2.13.0 has a vulnerability in its cryptographic signature verification due to improper handling of UTF-8 BOM prefixes in JSON Web Key detection. This flaw allows attackers who know the RSA public key to forge JWT tokens with arbitrary claims if the verifier accepts both HS256 and RS256 algorithms. The issue causes an RSA public key to be misinterpreted as an HMAC secret, resulting in complete authentication and authorization bypass. A fix has been committed but not yet released as of the advisory date.
CVE-2026-102266 is a vulnerability in PyJWT 2.13.0 where verification of HS256 tokens using an empty symmetric octet JWK key bypasses the intended empty key rejection. While raw empty HMAC keys are rejected, empty keys supplied via PyJWK objects are accepted, allowing attackers to forge valid HS256 JWTs if the application uses an empty key in its JWK set. This occurs because the PyJWK verification path does not invoke the empty key validation, enabling signature verification with a zero-length key.
setup.py test %endif
Security Fix(es):
PyJWT is a Python implementation of JSON Web Token standards. From 2.0.0a1 until 2.15.0, PyJWT PyJWKClient.get_signing_key_from_jwt is affected because payload parser catches ValueError but not RecursionError. This occurs when an attacker-controlled recursively nested payload reaches json.loads. As a result, documented PyJWT exception handling does not contain the failure. Consequently, an unauthenticated request can raise an exception that may produce an HTTP 500 response. The advisory-defined affected implementation also includes jwt/api_jwt.py, verify_signature=False. This issue is fixed in version 2.15.0.(CVE-2026-101918)
PyJWT is a Python implementation of JSON Web Token standards. From 2.13.0 until 2.14.0, PyJWS._load in jwt/api_jws.py is affected because parser catches ValueError but not RecursionError. This occurs when a deeply nested token header reaches json.loads. As a result, RecursionError escapes the documented PyJWT error hierarchy. Consequently, an unauthenticated malformed token can cause a request-level failure and HTTP 500. This issue is fixed in version 2.14.0.(CVE-2026-102265)
PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, PyJWT signature segment is affected because signature segment decoding accepts characters outside the canonical Base64URL representation. This occurs when non-Base64URL characters are appended to a valid compact JWS signature segment. As a result, base64url_decode produces the same signature bytes for different serialized segments. Consequently, raw-token revocation checks can fail to recognize an equivalent modified token. This issue is fixed in version 2.14.0.(CVE-2026-102269)
PyJWT is a Python implementation of JSON Web Token standards. From 2.1.0 until 2.15.0, PyJWT OKPAlgorithm.from_jwk in jwt/algorithms.py is affected because private-JWK import path does not compare the public key derived from d with x. This occurs when an OKP private JWK supplies non-corresponding x and d components. As a result, identity derived from x can differ from operations performed with d. Consequently, if an integration also accepts private key parameters from a proof header without rejecting them, an attacker may use a stolen sender-constrained token without the legitimate private key. This issue is fixed in version 2.15.0.(CVE-2026-102275)
setup.py test %endif
Security Fix(es):
PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, PyJWT get_signing_key_from_jwt is affected because unknown kid misses force refreshes without a negative cache or minimum refresh interval. This occurs when unauthenticated tokens repeatedly use the same unknown kid or varying kid values absent from the cached JWKS. As a result, each cache miss causes PyJWKClient to refresh the JWKS. Consequently, attacker traffic can amplify outbound requests to the configured JWKS endpoint. This issue is fixed in version 2.14.0.(CVE-2026-101917)
PyJWT is a Python implementation of JSON Web Token standards. From 2.0.0a1 until 2.15.0, PyJWT PyJWKClient.get_signing_key_from_jwt is affected because payload parser catches ValueError but not RecursionError. This occurs when an attacker-controlled recursively nested payload reaches json.loads. As a result, documented PyJWT exception handling does not contain the failure. Consequently, an unauthenticated request can raise an exception that may produce an HTTP 500 response. The advisory-defined affected implementation also includes jwt/api_jwt.py, verify_signature=False. This issue is fixed in version 2.15.0.(CVE-2026-101918)
PyJWT is a Python implementation of JSON Web Token standards. From 2.13.0 until 2.14.0, PyJWS._load in jwt/api_jws.py is affected because parser catches ValueError but not RecursionError. This occurs when a deeply nested token header reaches json.loads. As a result, RecursionError escapes the documented PyJWT error hierarchy. Consequently, an unauthenticated malformed token can cause a request-level failure and HTTP 500. This issue is fixed in version 2.14.0.(CVE-2026-102265)
PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, PyJWT signature segment is affected because signature segment decoding accepts characters outside the canonical Base64URL representation. This occurs when non-Base64URL characters are appended to a valid compact JWS signature segment. As a result, base64url_decode produces the same signature bytes for different serialized segments. Consequently, raw-token revocation checks can fail to recognize an equivalent modified token. This issue is fixed in version 2.14.0.(CVE-2026-102269)
PyJWT is a Python implementation of JSON Web Token standards. From 2.1.0 until 2.15.0, PyJWT OKPAlgorithm.from_jwk in jwt/algorithms.py is affected because private-JWK import path does not compare the public key derived from d with x. This occurs when an OKP private JWK supplies non-corresponding x and d components. As a result, identity derived from x can differ from operations performed with d. Consequently, if an integration also accepts private key parameters from a proof header without rejecting them, an attacker may use a stolen sender-constrained token without the legitimate private key. This issue is fixed in version 2.15.0.(CVE-2026-102275)
CVE-2026-85644 is a type confusion vulnerability in XS::Parse::Infix versions 0.40 through 0.49 for Perl. The vulnerability arises because the wrapper function incorrectly checks argument types, leading to dereferencing invalid memory and causing a segmentation fault. This can be triggered by supplying crafted input, such as a number treated as an array reference, potentially allowing an attacker to control memory dereferencing.
GitPython versions before 3.1.62 contain a path traversal vulnerability in the handling of the `path` field from untrusted .gitmodules files during submodule updates. This flaw allows directory creation outside the repository working tree, potentially leading to unauthorized file system modifications. The vulnerability requires an application flow that updates submodules at a non-HEAD commit, which is less common. The issue is fixed in GitPython 3.1.62.
A vulnerability in the python-cryptography library allows duplicate self-signed intermediate certificates to cause exponential path-building. This can lead to performance degradation or denial of service. The issue affects multiple versions of the library and has been assigned CVE-2026-69249. A security update addressing this vulnerability is available from Red Hat.
CVE-2026-5241 is a high-severity vulnerability in Red Hat AI Inference Server 3.4.5 (spyre) affecting the mlx-lm product, specifically in the huggingface/transformers LightGlue model loading path. It allows arbitrary code execution during model initialization. The vulnerability has a CVSS score of 8.0 and requires user interaction with high attack complexity. No known exploits in the wild have been reported. The Red Hat advisory lists this CVE among multiple others affecting the product but does not provide specific patch or fix details.
GitPython versions prior to 3.2.0 contain a Regular Expression Denial of Service (ReDoS) vulnerability in the Actor.name_email_regex pattern used to parse commit author and committer fields. The regex can cause catastrophic backtracking when processing a commit object with a long author or committer string containing an unterminated '<' character, leading to quadratic CPU exhaustion. This can result in denial of service conditions in any service or tool that reads commit metadata via GitPython, including CI runners and repository scanners.
GitPython versions from 5.5.3 up to but not including 9.26.0 contain a vulnerability where the repository's git directory is misresolved. This allows attacker-controlled repository content to impersonate the git directory, leading to arbitrary code execution when a victim performs a commit using GitPython. The flaw arises because GitPython tests candidate paths for the git directory in an order that considers the real .git directory last, enabling tracked files named gitdir, commondir, and HEAD to mislead the resolution. This can also lead to unauthorized reading of files outside the repository and writing config files to attacker-chosen locations. The issue is fixed in version 9.26.0.
A path traversal vulnerability exists in Redocly CLI's `split` command that allows an attacker to cause files to be written outside the intended output directory. This occurs when processing malicious OpenAPI or AsyncAPI descriptions. The attacker’s control over file names and contents is limited, as files are emitted only as YAML/JSON and code-sample files are named after HTTP methods. The issue affects versions from 1.27.2 up to but not including 2.33.2 and is fixed in version 2.33.2.
A Regular Expression Denial of Service (ReDoS) vulnerability exists in soupsieve's CSS selector parsing, specifically in the IDENTIFIER and VALUE sub-patterns. The flaw causes quadratic-time regex backtracking when parsing certain crafted selectors that fail to match, such as unterminated attribute values or identifiers followed by invalid characters. This can stall the interpreter for seconds to minutes depending on input size. The vulnerability is exploitable when user-controlled CSS selectors are passed to soupsieve or BeautifulSoup's select methods. Fixed in version 3.19.30 of the affected product.
A Regular Expression Denial of Service (ReDoS) vulnerability exists in soupsieve's whitespace/comment trimming regex RE_WS_END, which is used during CSS selector parsing. The regex is unanchored at the start and uses .search(), causing quadratic time complexity (O(n²)) on valid selectors with long whitespace or comment runs not exactly at the string end. This can cause significant CPU delays (e.g., ~10 seconds for a 20 KB selector). The issue affects soupsieve versions >=3.17.7 and <3.19.30 and is exploitable when user-controlled selectors are passed to soupsieve or BeautifulSoup's select methods. A fix is available in version 3.19.30.