Peter Ullrich

**Name of the Vulnerable Software and Affected Versions** ueberauth guardian versions 2.0.0 through 2.4.0 **Description** An allocation of resources without limits or throttling allows a denial of service via unbounded atom creation from attacker-controlled binary input. The `Guardian.Permissions.AtomEncoding` encoder processes permission scopes by passing arbitrary binaries to the `String.to atom/1` function. When the `encode/3` function in `lib/guardian/permissions/atom encoding.ex` is called with a list, the `encode value/3` binary clause calls `String.to atom(value)` without an allow-list check, discarding the `perm set` argument. Because `String.to atom/1` creates a new atom for every unseen binary and atoms are not garbage collected, the BEAM atom table (limited to approximately 1,048,576 entries) can be exhausted. An attacker providing varied input through request bodies or JWT claims can trigger a `system limit` crash of the BEAM node, affecting all applications running on it. **Recommendations** Update ueberauth guardian to version 2.4.1 or later. As a temporary workaround, switch the permission encoder to `Guardian.Permissions.BitwiseEncoding` or `Guardian.Permissions.TextEncoding`. As a temporary workaround, validate every permission value against the configured `perm set` allowlist before passing it to the `encode/3` function.

**Name of the Vulnerable Software and Affected Versions** ueberauth guardian versions 1.0.0 through 2.4.0 **Description** Improper verification of cryptographic signatures allows an unauthenticated attacker to revoke a victim's session using a forged token. The `Guardian.revoke/3` function in `lib/guardian.ex` uses `peek/1` to decode tokens, which only performs base64-decoding of the JWT header and payload without verifying the signature. These unverified claims are then passed to the token module's revoke callback and the `on revoke` callback, which can mutate state. An attacker who knows or guesses identifying claim values such as `jti` or `sub` can forge a JWT and submit it to endpoints that use `Guardian.revoke/3`, leading to a denial of service where the victim's legitimate session is evicted. This occurs when the token module mutates state based on these claims, such as in whitelist deletions or blacklist insertions. **Recommendations** Update ueberauth guardian to version 2.4.1 or later. As a temporary workaround, call `decode and verify` on the caller-supplied token to validate the signature before passing it into `Guardian.revoke/3`, and reject tokens with invalid signatures at the application boundary.

**Name of the Vulnerable Software and Affected Versions** ueberauth guardian versions 2.0.0 through 2.4.0 **Description** An allocation of resources without limits or throttling in the `Guardian.Permissions` module allows a denial of service via BEAM atom-table exhaustion. The `Guardian.Permissions` mixin installs a public `encode permissions!/1` function that calls `String.to atom(to string(k))` for each key of a supplied map before validation. In the `do encode permissions!/2` function, the integer-value clause bypasses validation against the configured permission set, allowing keys with integer values to be interned as new atoms. Since atoms are not garbage collected and the BEAM atom table has a fixed size, an attacker who can influence a permission map passed to `encode permissions!/1` or `encode permissions into claims!/2` can exhaust the table, crashing the BEAM node and all running services. This issue is associated with the file `lib/guardian/permissions.ex` and the functions `encode permissions!/1`, `encode permissions into claims!/2`, and `do encode permissions!/2`. **Recommendations** Update ueberauth guardian to version 2.4.1 or later. As a temporary workaround, filter the permission map to ensure only keys belonging to the configured permission set are passed to `encode permissions!/1` or `encode permissions into claims!/2`, and avoid passing attacker-influenced permission maps into these functions.

**Name of the Vulnerable Software and Affected Versions** ueberauth guardian versions 0.1.0 through 2.4.0 **Description** An allocation of resources without limits or throttling allows a denial of service via unbounded atom creation from attacker-influenced binary input. The `Guardian.Plug.Keys` module derives connection and session namespace keys by passing arbitrary binaries to the `String.to atom/1` function. Specifically, the `base key/1` function in `lib/guardian/plug/keys.ex` converts binaries into atoms, and the helpers `claims key/1`, `resource key/1`, and `token key/1` create additional atoms. Similarly, `key from other/1` converts regex-captured binaries through `String.to atom/1`. High-level entry points, such as `Guardian.Plug.current token(conn, key: key)`, pass caller-supplied keys directly into these functions. Because `String.to atom/1` creates a new atom for every unseen binary and atoms are not garbage collected, the BEAM atom table (which has a default limit of approximately 1,048,576 entries) can be exhausted. If an application routes untrusted data, such as a tenant identifier or request header, into a Guardian key via the `key` parameter, an attacker can send a stream of varied input to consume the atom table and crash the BEAM node, affecting all applications running on it. **Recommendations** Update ueberauth guardian to version 2.4.1 or later. As a temporary workaround, do not derive Guardian keys from untrusted input; instead, use a fixed, hardcoded set of namespace keys or validate values against a bounded allowlist before passing them as the `key` option.

**Name of the Vulnerable Software and Affected Versions** ufirstgroup ymlr versions 0.0.1 through 5.1.5 **Description** Improper neutralization of CRLF (Carriage Return Line Feed) sequences in the `Elixir.Ymlr` module allows attackers to inject arbitrary content into generated YAML documents via document comments. The functions `document!/2`, `document/2`, `documents!/2`, and `documents/2` interpolate caller-supplied comment strings behind a # prefix without validating or escaping line breaks. Since YAML comments are terminated by line breaks, a carriage return or line feed ends the comment context, causing subsequent text to be treated as part of the document body. This enables attackers to forge top-level mapping keys, override application-set values, or use markers to split output into multiple documents, which are then parsed as legitimate data by downstream consumers like configuration loaders and CI pipelines. The issue is located in the `lib/ymlr.ex` file and specifically affects the `document!/2` and `documents!/2` routines. **Recommendations** Update to version 5.1.6. As a temporary workaround, split untrusted comment strings on line breaks and pass the resulting list as the comment element of the `{comment, data}` tuple. Reject comment strings containing carriage return or line feed characters. Avoid placing untrusted text in comments and instead place it in the encoded data where the encoder applies quoting.

**Name of the Vulnerable Software and Affected Versions** bandit versions 1.11.0 through 1.12.0 **Description** An inefficient algorithmic complexity issue allows unauthenticated remote denial of service via CPU exhaustion during WebSocket fragment reassembly. The function `oversize message?/2`, called from `handle frame/3` in `lib/bandit/websocket/connection.ex`, appends non-final continuation frames to a left-nested iolist and re-measures the entire buffer using `IO.iodata length/1` for every frame. This results in quadratic (O(n^2)) reassembly work relative to the number of continuation frames. While the `max fragmented message size` limit restricts total bytes, it does not limit the frame count. An attacker can send numerous small continuation frames to exhaust CPU resources, potentially starving the server and denying service to legitimate users. This issue specifically affects applications serving WebSocket endpoints through Bandit, including Phoenix applications using Bandit as the HTTP adapter. **Recommendations** Update bandit to version 1.12.1.

**Name of the Vulnerable Software and Affected Versions** elixir-plug versions 0.1.0 through 1.16.5 elixir-plug versions 1.17.0 through 1.17.3 elixir-plug versions 1.18.0 through 1.18.4 elixir-plug versions 1.19.0 through 1.19.4 elixir-plug versions 1.20.0 through 1.20.2 **Description** Improper neutralization of parameter delimiters allows an attacker to inject or override HTTP cookie attributes. The `encode/2` function in `Plug.Conn.Cookies` constructs the Set-Cookie response header by interpolating the cookie value and its path, domain, `same site`, and extra attributes without neutralizing the ';' delimiter. If an application places attacker-controlled data into a cookie value or attribute, such as through the `put resp cookie/4` function, an attacker can inject a ';' to append or override attributes like Domain and Path scope, or remove the Secure and HttpOnly flags. This can lead to cookie tossing and session fixation. While carriage return, line feed, and null bytes are rejected, preventing HTTP response splitting, attribute injection via ';' remains possible. **Recommendations** Update to version 1.16.6 or later. Update to version 1.17.4 or later. Update to version 1.18.5 or later. Update to version 1.19.5 or later. Update to version 1.20.3 or later. As a temporary workaround, validate or reject the ';' delimiter in any untrusted data before passing it as a cookie value or attribute to the `put resp cookie/4` or `encode/2` functions.

**Name of the Vulnerable Software and Affected Versions** plug versions 1.4.0 through 1.16.5 plug versions 1.17.0 through 1.17.3 plug versions 1.18.0 through 1.18.4 plug versions 1.19.0 through 1.19.4 plug versions 1.20.0 through 1.20.2 **Description** The `Plug.Parsers.MULTIPART` request-body parser, used for file uploads and multipart forms, fails to enforce the `:length` budget across all consumed resources. The parser only counts bytes in the part body, ignoring part header bytes and parts with empty bodies. An unauthenticated remote attacker can exploit this by sending a single request containing numerous empty-body file parts with a non-empty filename in the `Content-Disposition`. This process triggers the creation of a temporary file via `Plug.Upload` and retains a `Plug.Upload` struct for each part, leading to unbounded memory growth and exhaustion of disk space and inodes. The issue is linked to the file `lib/plug/parsers/multipart.ex` and the functions `Plug.Parsers.MULTIPART.parse multipart/2`, `Plug.Parsers.MULTIPART.parse multipart headers/5`, `Plug.Parsers.MULTIPART.parse multipart body/4`, and `Plug.Parsers.MULTIPART.parse multipart file/4`. **Recommendations** Update plug to version 1.16.6 or later. Update plug to version 1.17.4 or later. Update plug to version 1.18.5 or later. Update plug to version 1.19.5 or later. Update plug to version 1.20.3 or later.

**Name of the Vulnerable Software and Affected Versions** postgrex versions 0.16.0 through 0.22.2 **Description** An issue in the `Postgrex.Notifications` module allows an attacker to inject SQL into the reconnect replay query by influencing a LISTEN channel name. While the `quote channel/1` function sanitizes double quotes, it fails to escape the `$$` dollar-quote delimiter used in the anonymous code block within the `handle connect/1` function. Because the `listen/3` function only rejects null bytes and names exceeding 63 bytes, a channel name containing `$$` can prematurely terminate the dollar-quoted string. This causes PostgreSQL to parse the remaining input as top-level statements, leading to the rejection of the replay query during every reconnection attempt. Consequently, the notification connection fails to re-establish subscriptions, resulting in a denial of service where notifications are silently dropped for all channels sharing that connection. This occurs when untrusted input is passed as a channel name to `Postgrex.Notifications.listen/3`. **Recommendations** Update postgrex to version 0.22.3 or later. Validate channel names before passing them to `Postgrex.Notifications.listen/3` by rejecting any name containing the `$$` delimiter or restricting names to alphanumeric characters and underscores.

**Name of the Vulnerable Software and Affected Versions** phoenix versions 0.11.0 through 1.5.14 phoenix versions 1.6.0-rc.0 through 1.6.16 phoenix versions 1.7.0-rc.0 through 1.7.23 phoenix versions 1.8.0-rc.0 through 1.8.8 **Description** An unauthenticated attacker can cause a denial of service against any endpoint mounting a Phoenix socket with a reachable channel transport, such as WebSocket or LongPoll. The issue resides in the `Elixir.Phoenix.Socket`:handle in/4 routine within the lib/phoenix/socket.ex file. Because Phoenix transports do not limit the number of channels a single transport process can join, a client can send an unbounded number of phx join messages over one connection. This spawns excessive channel processes, potentially exhausting the BEAM maximum process limit and preventing the virtual machine from starting new processes for legitimate traffic. This amplification occurs within a single connection, rendering network-layer connection caps and rate limiting ineffective. **Recommendations** Update phoenix to version 1.5.15 or later. Update phoenix to version 1.6.17 or later. Update phoenix to version 1.7.24 or later. Update phoenix to version 1.8.9 or later. Configure the `:max channels per transport` option to bound the number of channels a single transport process can join.

**Name of the Vulnerable Software and Affected Versions** phoenix versions 1.2.0-rc.0 through 1.5.14 phoenix versions 1.6.0-rc.0 through 1.6.16 phoenix versions 1.7.0-rc.0 through 1.7.23 phoenix versions 1.8.0-rc.0 through 1.8.8 **Description** The Presence JavaScript client in phoenix contains an improper check for unusual conditions that allows an attacker with ordinary channel access to cause a persistent client-side denial of service for all viewers of a presence channel topic. The issue resides in the `assets/js/phoenix/presence.js` file within the `Presence.syncState()` and `Presence.syncDiff()` routines. The client uses a bare truthiness test (`state[key]`) instead of an own-property check to verify if a presence exists. Since presence keys are attacker-controlled, a user can provide a key that matches an `Object.prototype` member name (such as ` proto `, `constructor`, `toString`, or `hasOwnProperty`). This causes the lookup to return the built-in `Object.prototype` instead of `undefined`, leading the code to attempt to read `.metas.map(...)` from the prototype, which throws an uncaught `TypeError`. This exception prevents the local state from updating and stops `onSync()` from firing. Because the server continues to push the malicious key, the synchronization remains broken for all viewers of the topic until the attacker leaves. This is a read-time confusion of the prototype object and not prototype pollution. **Recommendations** Update phoenix to version 1.5.15 or later. Update phoenix to version 1.6.17 or later. Update phoenix to version 1.7.24 or later. Update phoenix to version 1.8.9 or later.

**Name of the Vulnerable Software and Affected Versions** mint versions 0.5.0 through 1.9.0 **Description** A denial of service issue exists in the `Mint.HTTP1` module. When decoding a chunked HTTP response body, the software accumulates partial fragments in the `data buffer` (an unbounded iolist) using the `add body to buffer/2` function and does not emit data until the full declared chunk length is received. Because the chunk size is parsed from the server without an upper bound, a malicious server can specify an enormous chunk size and send bytes slowly. This forces the client to buffer data indefinitely, potentially leading to an out-of-memory condition. This can be triggered when a client follows redirects, fetches user-supplied URLs, or processes webhooks. The issue is associated with the `decode body/5` function in the `lib/mint/http1.ex` file. **Recommendations** Update mint to version 1.9.1 or later.

**Name of the Vulnerable Software and Affected Versions** hpax versions 0.1.1 through 1.0.3 **Description** An inefficient algorithmic complexity issue exists during the decoding of HPACK variable-length integers. The `Elixir.HPAX.Types`:decode remaining integer/3 function, accessed via the `Elixir.HPAX`:decode/2 entry point, does not impose an upper bound on the decoded value or the number of continuation octets. Since BEAM integers use arbitrary precision, a sequence of continuation octets creates an O(N)-bit bignum, resulting in a superlinear decoding cost of approximately O(N^2). An unauthenticated attacker can exploit this by sending a small HTTP/2 header block that consumes excessive CPU and transient memory, leading to a denial-of-service amplification. **Recommendations** Update hpax to version 1.0.4 or later.

**Name of the Vulnerable Software and Affected Versions** swoosh versions 1.12.0 through 1.26.2 **Description** URL path injection exists in the Microsoft Graph adapter of Swoosh. The `Swoosh.Adapters.MsGraph` component constructs the Microsoft Graph API request URL by interpolating the sender's email address into the path `/users/{from}/sendMail` without validation or percent-encoding. In applications where the `from` address is derived from untrusted or user-influenced input, an attacker can use URL-special characters such as `/`, `?`, or `#` in the local part of the address to escape the intended path segment. This allows the attacker to rewrite the request path and query string, redirecting the authenticated POST request to other Graph endpoints within the token's scopes using the application's bearer token. **Recommendations** Update to version 1.26.3 or later. Validate or reject sender addresses containing characters outside the allowed RFC 5321 set, specifically `/`, `?`, `#`, and `..`, before passing the email to the adapter. Set a static `:url` in the adapter configuration to bypass the interpolation of the `from` address into the request path.

**Name of the Vulnerable Software and Affected Versions** leandrocp mdex versions 0.8.3 through 0.13.1 **Description** Improper neutralization of input during web page generation allows cross-site scripting (XSS) via unsanitized URL schemes in Quill Delta output. The function `to delta/2` converts Markdown into a Quill Delta, and the function `default convert node/3` copies URLs from link, wikilink, or image nodes directly into the Delta `link` or `image` attributes without normalization or applying a scheme allowlist. An attacker providing Markdown text can include a `javascript:` URL that is passed verbatim into the Delta attribute. When a downstream renderer converts this Delta to HTML, the attribute becomes an `<a href>` or `<img src>`, executing the script in the browser of the user. Links and wikilinks are the primary vectors as they execute on click, while images have lower impact in modern browsers. **Recommendations** Update leandrocp mdex to version 0.13.2 or later. As a temporary workaround, sanitize the Quill Delta produced by `to delta/2` before rendering by dropping or blanking any `link` or `image` value with a URL scheme not included in a safe allowlist (e.g., http, https, mailto, tel).

**Name of the Vulnerable Software and Affected Versions** mdex versions 0.11.0 through 0.12.2 mdex native versions 0.1.0 through 0.2.2 **Description** A memory leak occurs in the native rendering code when processing documents containing escaped-tag nodes. The conversion of each `%MDEx.EscapedTag{}` node into its native representation via the Rust NIF (Native Implemented Function) uses `Box::leak` on the caller-supplied literal string. This causes the memory allocation to persist for the entire lifetime of the operating system process without being freed. Since the number of nodes and the length of the literals are attacker-controlled and lack size caps or rate limits, repeated rendering of such documents leads to unbounded native memory exhaustion. This can be triggered through the `MDEx.to html/1` endpoint or any API that renders a `%MDEx.Document{}`. Consequently, an attacker can cause a denial of service by exhausting the resident memory of the BEAM process, leading to a system crash. **Recommendations** Update mdex to version 0.12.3 or later. Update mdex native to version 0.2.3 or later.

**Name of the Vulnerable Software and Affected Versions** mdex versions 0.11.3 through 0.12.2 mdex native versions 0.1.0 through 0.2.2 **Description** Improper neutralization of input during web page generation allows stored or reflected cross-site scripting via attacker-controlled Markdown. When syntax highlighting and full info-string forwarding (`render: [full info string: true]`) are enabled, the Lumis adapter copies the value of a code fence's `highlight lines class` info-string attribute unescaped into the class attribute of every rendered line. The `comrak nif::lumis adapter::LumisAdapter::parse custom attributes()` function shlex-parses the info string and stores key-value pairs verbatim. Subsequently, `highlight lines config` pulls `highlight lines class` into the per-line class value, and `write highlighted()` interpolates that value directly into the class attribute of the per-line `<div>`. A single-quoted shell token can preserve an inner double quote, allowing an attacker to terminate the class attribute and inject arbitrary HTML and JavaScript. This can lead to session theft and account takeover without requiring authentication or special privileges. **Recommendations** Update mdex to version 0.12.3 or later. Update mdex native to version 0.2.3 or later. As a temporary workaround, do not enable full info-string forwarding (`render: [full info string: true]`) when rendering untrusted Markdown. Restrict `highlight lines class` values to a safe character set (e.g., `[A-Za-z0-9 -]`) before rendering.

**Name of the Vulnerable Software and Affected Versions** mdex versions 0.11.0 through 0.12.2 mdex native versions 0.1.0 through 0.2.2 **Description** An unauthenticated attacker can cause a denial of service through unbounded memory allocation. The issue occurs when the `parse highlight lines()` function in the native adapter eagerly expands a user-controlled inclusive line range from a fenced code block's `highlight lines` decorator into a `Vec<usize>` without an upper bound on the range size. An attacker providing Markdown rendered via `MDEx.to html/2` can specify an extremely large range, forcing the system to allocate excessive memory and abort the BEAM, which denies service to all users of the rendering process. Additionally, the per-line write loop performs a linear scan over the vector, resulting in quadratic cost for rendering. Exploitation requires the application to enable code-block decorators by setting both `github pre lang` and `full info string` render options and configuring an inline syntax-highlight formatter. **Recommendations** Update mdex to version 0.12.3 or later. Update mdex native to version 0.2.3 or later. As a temporary workaround, disable code-block decorators by leaving the `github pre lang` and `full info string` render options unset or avoid configuring an inline syntax-highlight formatter to prevent the parsing of `highlight lines` specifications.

**Name of the Vulnerable Software and Affected Versions** leandrocp MDEx versions 0.4.3 through 0.13.1 **Description** An excessive allocation issue exists when the `MDEx.parse document/2` function accepts a `{:json, json}` source. The private `json to node/1` function passes an attacker-controlled `node type` value to `Module.concat/1`, which subsequently calls `String.to atom/1`. This process creates a new atom for every distinct value provided. Because atoms are not garbage collected on the BEAM (the Erlang Virtual Machine), a specially crafted JSON document with unique `node type` values at each deeply nested node can exhaust the default atom table. This leads to an unauthenticated denial-of-service by aborting the entire Erlang VM and terminating all processes on the node. **Recommendations** Update leandrocp MDEx to version 0.13.2 or later. As a temporary workaround, do not pass untrusted or attacker-controlled input to the `{:json, ...}` source of `MDEx.parse document/2`.

[Content removed]