Threats Tagged 'cwe-436'

A really Ruby Mail handler. Security Fix(es): Affected versions of this package are vulnerable to Improper Validation of Syntactic Correctness of Input through `q_value_decode` and `b_value_decode` in `lib/mail/utilities.rb`. An attacker can make a display name or local part decode to a different address than intended by supplying a malformed RFC 2047 encoded-word, including one that embeds extra encoded-word markers or additional text. The decoders only matched the first encoded-word and used a greedy charset capture, so a crafted header could cause the parsed `From`, `To`, or `Reply-To` value to omit or reshuffle literal text. Applications that display, compare, or authorize based on the decoded address can then present or act on a spoofed sender or recipient address.(CVE-2026-63435)

Elysia v1.4.28 is vulnerable to denial-of-service attacks due to CPU exhaustion in the form data normalization code. Elysia uses `getAll` to retrieve value from FormData. It is called directly relative to the total number of key-value pairs in the form data. The total amount of work the for loop has to do grows quadratically, so doubling the number of unique key-value pairs quadruples the amount of work. In the above PoC, each .getAll call scans through all of the `n` key-value pairs in the form data. Because there are `n` unique keys in the form data, there are .getAll calls, so in total the form data normalizer has to scan `n` x `n` key-value pairs. ### Impact Endpoints using `multipart/form-data` ### Patches 1.4.29 ### Workarounds no 100% confirm workaround beside updating the patch

CVE-2026-73511 is an authentication bypass vulnerability in Envoy proxy caused by inconsistent path matching behavior with backend servers that strip semicolon matrix parameters per path segment. This allows a remote attacker to bypass path-based access controls by crafting requests that cause Envoy to select an unprotected fallback path while the backend resolves the protected resource. The issue affects Envoy versions prior to 1.36.10, 1.37.6, 1.38.4, and 1.39.1 and is fixed in these versions.

Envoy proxy versions prior to 1.36.10, 1.37.6, 1.38.4, and 1.39.1 contain a vulnerability where inconsistent path canonicalization allows bypassing path-based authorization. When the ignore_path_parameters_in_path_matching option is enabled, the router strips semicolon suffixes before matching, but the RBAC url_path matcher evaluates the raw path. This discrepancy can let unauthenticated clients bypass DENY rules on protected routes. The issue is fixed in the specified versions.

Interpretation conflict in Visual Studio Code allows an unauthorized attacker to bypass a security feature over a network.

authentik is an open-source identity provider. Prior to 2026.2.6 and 2026.5.5, an inbound SAML Source configured with the non-default USERNAME_LINK or EMAIL_LINK user-matching mode interprets an XML comment in a NameID differently from the identity provider's signed assertion. An attacker with an account on the source identity provider who can set the account's NameID can inject an XML comment that truncates the value used by authentik to the text before the comment while the signed assertion remains valid. A crafted NameID can therefore truncate to a victim's username or email and bind the attacker's external identity to the victim's existing account. This grants full takeover without the victim's password or the identity provider's private key, and the malicious link persists so later logins succeed without the comment. Sources using the default unique-identifier matching mode and authentik's outbound SAML Provider role are not affected. This issue is fixed in versions 2026.2.6 and 2026.5.5.

CKAN MCP Server is a tool for querying CKAN open data portals. Prior to 0.4.112, canonicalizeParams in src/utils/cache.ts serializes request parameters with unescaped ampersand, equals-sign, and vertical-bar delimiters, allowing different logical parameter sets used by buildCacheKey to collide and an attacker to prime a shared cache with a response for a victim's distinct query. This issue is fixed in version 0.4.112.

### Summary `QuerystringParser` treated `;` as a field separator in `application/x-www-form-urlencoded` bodies, in addition to `&`. The [WHATWG URL standard](https://url.spec.whatwg.org/#urlencoded-parsing), modern browsers, and Python's `urllib.parse` (since the CVE-2021-23336 fix) treat only `&` as a separator. This creates a parser differential: the same bytes are tokenized into different fields than a WHATWG compliant intermediary would produce, allowing an attacker to smuggle extra form fields past an upstream body inspecting component. ### Details In `python_multipart/multipart.py`, the `FIELD_NAME` and `FIELD_DATA` states located the next separator by scanning for `&` and, failing that, for `;`: ```python sep_pos = data.find(b"&", i) if sep_pos == -1: sep_pos = data.find(b";", i) ``` As a result, `;` acted as a field boundary. Because the fallback only triggered when no `&` remained in the current chunk, tokenization also depended on unrelated bytes later in the buffer and on how the body was split across `write()` calls. This is the same class of issue as CVE-2021-23336 in CPython's `urllib.parse`. For example, a body inspecting WAF or gateway that follows the WHATWG rule (only `&` separates fields) receives: ``` role=user&x=;role=admin ``` The upstream parses two fields, `role=user` and `x=";role=admin"`, sees a benign `role=user`, and forwards the request. `QuerystringParser` parsed the same bytes as three fields: `role="user"`, `x=""`, and `role="admin"`. The application (for example via Starlette/FastAPI `request.form()`, where the last value wins) then received `role=admin`, a value the upstream validator never saw. The parser is reachable through the public `QuerystringParser` class, the high level `FormParser`, `create_form_parser`, and `parse_form` APIs, and Starlette/FastAPI `request.form()` for url encoded bodies. ### Impact Interpretation conflict / HTTP parameter pollution. An attacker can smuggle extra or overriding form fields past an upstream component that applies the WHATWG separator rule, reaching the backend with parameters the intermediary did not observe. ### Mitigation Upgrade to `python-multipart` `0.0.30` or later, which treats only `&` as a field separator per the [WHATWG URL standard](https://url.spec.whatwg.org/#urlencoded-parsing). `;` is parsed as ordinary field data, matching `urllib.parse`, browsers, and other compliant parsers.

@cedar-policy/authorization-for-expressjs is an open-source Express.js middleware that integrates Cedar authorization into Express applications by mapping HTTP requests to Cedar actions and evaluating authorization policies before allowing requests to proceed. Versions prior to 0.3.0 have an issue where, under certain circumstances, the middleware matches incoming requests against Cedar action mappings using req.originalUrl, which includes the query string, while Express routes requests using only the path component. The middleware uses req.originalUrl to match incoming requests against Cedar action mappings. In Express, req.originalUrl includes the query string, while route matching uses only the path. This creates a divergence between what Cedar authorizes and what Express executes. When an application defines separate actions for overlapping path prefixes with different authorization requirements (for example, GET /users for listing all users with admin-only access, and GET /users/{id} for retrieving a single user with any authenticated user access), an actor can append a query string to bypass the more restrictive policy. Sending GET /users/?x=1 causes the middleware to match against /users/{id} (with id parameter set to ?x=1) and evaluate the less restrictive action, while Express routes the request to the /users list handler. This allows inappropriate access to the more restrictive endpoint. This issue has been addressed in version 0.30. Some workarounds are available. Validate and sanitize incoming request paths before they reach the authorization middleware. Ensure that applications do not rely solely on the middleware for authorization when defining multiple actions on overlapping path prefixes with different permission levels.

Apache Airflow's Backfill API authorized a request against a Dag id supplied by the caller whenever the `backfill_id` path segment failed to parse. The authorization dependency parsed it with `int()` while the route handler parsed it as pydantic's `NonNegativeInt`, which accepts values `int()` rejects (`1.0` coerces to `1`); FastAPI resolves dependencies before endpoint validation, so the two acted on different Dags. An authenticated user holding edit permission on any single Dag could therefore read, pause and cancel backfills belonging to any other Dag, including moving another Dag's queued runs to `failed`. No non-default configuration is required and backfill ids are sequential, so finding a target is trivial. Users are advised to upgrade to apache-airflow 3.3.1 or later, which parses the backfill id with the same type the routes declare.