Threats Tagged 'cwe-755'

OWASP Coraza WAF is a golang modsecurity compatible web application firewall library. From 3.4.0 until 3.8.0, the multipart processor in internal/bodyprocessors/multipart.go treats io.ErrUnexpectedEOF as nonfatal without setting MULTIPART_STRICT_ERROR. A remote attacker can submit a truncated multipart body that produces io.ErrUnexpectedEOF, causing parsing to stop without raising the strict-error signal used by the recommended defensive rule. Rules 200002 and 200003 do not fire, allowing multipart parser-disagreement payloads to reach a backend that interprets the truncated body differently. This issue is fixed in version 3.8.0.

## Summary A malformed RSA JWK inside a JWK Set aborts parsing of the entire set instead of being skipped, because `RSAAlgorithm.from_jwk` can raise a plain `ValueError` that isn't caught by `PyJWKSet`'s per-key error-skipping logic. ## Affected component / version - Package: `PyJWT` (PyPI, ecosystem `pip`) - Files: `jwt/api_jwk.py` (`PyJWK.__init__`, `PyJWKSet.__init__`), `jwt/algorithms.py` (`RSAAlgorithm.from_jwk`) - Confirmed present in the `master` branch as of 2026-09-05 (commit `7144e4534c34810f4525dc4578a32addd8212cff`, tag `2.13.0`). Directly verified identical in tags `2.9.0`, `2.10.0`, `2.11.0`, `2.12.0`, `2.12.1`, `2.13.0` -- the vulnerable call and the `except PyJWTError` guard are unchanged across all six releases. Not verified against any release prior to `2.9.0`. ## Details `PyJWKSet.__init__` (`jwt/api_jwk.py:145-152`) iterates each key in a JWK Set: ```python for key in keys: try: self.keys.append(PyJWK(key)) except PyJWTError as error: if isinstance(error, MissingCryptographyError): raise error # skip unusable keys continue ``` `PyJWK.__init__` (`api_jwk.py:82`) calls `self.Algorithm.from_jwk(self._jwk_data)` with no try/except of its own. For an RSA JWK, this dispatches to `RSAAlgorithm.from_jwk` (`jwt/algorithms.py:539-586`). When the JWK supplies `d`, `e`, `n` without the CRT parameters (`p`, `q`, `dp`, `dq`, `qi`), `from_jwk` calls `cryptography`'s `rsa_recover_prime_factors(public_numbers.n, d, public_numbers.e)` (`algorithms.py:572-574`) to derive the key. If `d` is not the correct private exponent for that `n`/`e` pair, `rsa_recover_prime_factors` raises a plain `ValueError`. `ValueError` is a built-in Python exception and is not a subclass of `jwt.exceptions.PyJWTError` (`PyJWTError(Exception)` is the root of PyJWT's own exception hierarchy). It is therefore not caught by `PyJWKSet.__init__`'s `except PyJWTError`, and propagates out of the constructor, aborting the `for key in keys:` loop before any subsequent key in the list is processed. `PyJWKSet.from_dict`/`from_json` and `PyJWK.from_dict`/`from_json` are exported public API (`jwt/__init__.py`). `PyJWKClient.get_jwk_set` (`jwt/jwks_client.py:158`) feeds a fetched JWKS HTTP response directly into `PyJWKSet.from_dict` with no per-key pre-validation, so this is reachable through the documented `PyJWKClient` flow whenever the fetched JWKS contains a malformed key alongside valid ones. ## Proof of concept ```python import jwt good_jwk = { "kty": "RSA", "n": "<a valid base64url-encoded RSA modulus, e.g. from a real 2048-bit public key>", "e": "AQAB", } bad_jwk = { "kty": "RSA", "n": good_jwk["n"], "e": "AQAB", "d": "AAAAAA", # not the true private exponent for n/e, no CRT params present } jwks_doc = {"keys": [bad_jwk, good_jwk]} jwt.PyJWKSet.from_dict(jwks_doc) # raises: ValueError: Unable to compute factors p and q from exponent d. # (uncaught -- PyJWKSet.__init__ never returns, `good_jwk` is never added) ``` ## Impact `PyJWKSet.__init__` raises before completing, so no key in the JWK Set is added to the resulting set, including keys unrelated to the malformed entry. This requires the malformed key to already be present in a JWK Set the application parses (e.g. one entry in an aggregated/federated key set, or a key affected by transit corruption before signature verification of the JWKS transport itself). Applications that vet each key individually before adding it to a trusted set are not affected. The failure is an uncaught `ValueError`, not one of PyJWT's documented `jwt.exceptions.*` types, so exception handling written against PyJWT's documented contract (`except jwt.exceptions.PyJWTError`) will not catch it either. ## Suggested remediation Wrap the key-construction call in `PyJWK.__init__` (`api_jwk.py:82`) so a `ValueError` is converted into `InvalidKeyError` (a `PyJWTError` subclass): ```python try: self.key = self.Algorithm.from_jwk(self._jwk_data) except ValueError as e: raise InvalidKeyError(f"Unable to construct key from JWK: {e}") from e ``` This lets `PyJWKSet.__init__`'s existing `except PyJWTError: continue` skip the one malformed key as its own comment already states is intended. ## Responsible Disclosure Timeline Per the [OWASP Vulnerability Disclosure Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html) and [Google Project Zero's 2020 disclosure policy](https://projectzero.google/2020/01/policy-and-disclosure-2020-edition.html): - **Day 0** (date of submission): to be set to the actual API response's `created_at` timestamp when this report is submitted. If submitted on the date of this draft (2026-09-05), Day 0 = 2026-09-05. - **Day 90** (full-public-disclosure deadline, regardless of fix status): Day 0 + 90 days -- 2026-12-04 if Day 0 is 2026-09-05. - A brief mutually-agreed extension (standard 14-day grace period) is available if a fix is scheduled bu

> [!NOTE] > The vulnerability surfaces only when a JWKS fetch fails; an attacker can attempt to provoke that with sustained unknown-kid traffic, but the outcome depends on upstream JWKS-endpoint behavior (rate limiting, transient errors) which is beyond the attacker's control. Impact is reduced auth availability until the next successful fetch, not complete denial of service. ## Summary PyJWKClient.get_signing_key() forces a fresh HTTP request to the JWKS endpoint for every JWT with an unknown kid value, with no rate limiting. Since kid comes from the unverified token header, an attacker can trigger unlimited outbound requests. Additionally, fetch_data() finally block clears the JWKS cache on network error. ## Root Cause jwt/jwks_client.py:172-198 - get_signing_key(kid) calls get_signing_keys(refresh=True) for unknown kids, bypassing TTL cache with no cooldown. jwt/jwks_client.py:120-122 - finally block writes None to cache on error, clearing valid data. ## Impact - DoS against JWKS endpoint (unlimited requests per invalid token) - DoS against application (network I/O latency) - Cascading failure (rate limiting clears cache, breaking legitimate auth) ## Suggested Fix 1. Add refresh cooldown (refuse refresh more than once per TTL period) 2. Move cache write from finally to else block ## Affected Versions All versions with PyJWKClient (2.4.0 through 2.12.1)

Improper Handling of Exceptional Conditions vulnerability in the aspnet-request pattern converter of Apache log4net. Reading request parameters triggers ASP.NET request validation, so a request carrying content such as markup made the layout throw and the appender discarded the whole event. A sender could suppress the log record of their own request. Only applications on ASP.NET for .NET Framework whose layout uses %aspnet-request are affected. This issue affects Apache log4net: from 1.2.11 before 3.5.0. Users are recommended to upgrade to version 3.5.0, which fixes the issue.

vLLM is an inference and serving engine for large language models. Prior to 0.30.0, structured-output request failures can escape request-scoped validation and reach the EngineCore fatal-error path. A per-request backend mismatch can re-raise a grammar compilation exception, padding produced by the ngram_gpu speculative-decoding mode can pass a negative token to guidance validation, and the Rust frontend can admit empty structured-output values that the Python frontend rejects, allowing ordinary constrained-generation requests to terminate the shared engine. This issue is fixed in version 0.30.0.

Uncaught exception, Improper Handling of Exceptional Conditions vulnerability in Apache Thrift Ruby bindings. This issue affects Apache Thrift: before 0.25.0. Users are recommended to upgrade to version 0.25.0, which fixes the issue.

Uncaught exception, improper handling of exceptional conditions, improper resource shutdown vulnerability in Apache Thrift D thrift.server.nonblocking.TNonblockingServer. This issue affects Apache Thrift: before 0.25.0. Users are recommended to upgrade to version 0.25.0, which fixes the issue.

Apache Thrift Java bindings prior to version 0.25.0 contain a vulnerability due to improper handling of exceptional conditions, which results in resources not being released after their effective lifetime. This flaw can cause resource exhaustion and potentially lead to denial of service. The issue has been addressed and fixed in version 0.25.0.

Uncaught exception, Improper Handling of Exceptional Conditions vulnerability in Apache Thrift NodeJS bindings. This issue affects Apache Thrift: before 0.25.0. Users are recommended to upgrade to version 0.25.0, which fixes the issue.

Apache Thrift Java bindings prior to version 0.25.0 have a vulnerability due to improper handling of exceptional conditions, including resource allocation without limits and uncaught exceptions. This flaw can cause resource exhaustion or application instability. The issue is resolved in version 0.25.0, and users should upgrade to mitigate the risk.