José Valim

**Name of the Vulnerable Software and Affected Versions** Erlang/OTP versions 17.0 through 27.3.4.16 Erlang/OTP versions 28.0 through 28.5.0.5 Erlang/OTP versions 29.0 through 29.0.5 snmp versions 4.25.1 through 5.18.2.0 snmp versions 5.19 through 5.20.2.1 snmp versions 5.20.3 through 5.20.4 **Description** Improper validation of the specified quantity in input within the snmp module allows a remote attacker to degrade availability. An attacker can send an SNMP message containing a BER INTEGER with an arbitrarily large length field. The function `snmp pdus:dec integer notag/1` defaults its size limit to infinity, and `do dec integer notag/2` accumulates the value across every declared byte using a recursive shift and bitwise or. This causes the workload to grow superlinearly as each operation acts on a progressively larger bignum. While a size-limited variant `dec integer notag/2` exists, it is only used by `dec snmp version/1`. Other fields, including the request identifier, error status, index, generic and specific trap fields, engine boots, time, and varbind values decoded by `dec value/1`, use the unbounded form. The decoding occurs before the PDU is processed, meaning no valid request is required to trigger the issue. **Recommendations** Update Erlang/OTP to version 27.3.4.17 or later. Update Erlang/OTP to version 28.5.0.6 or later. Update Erlang/OTP to version 29.0.6 or later. Update snmp to version 5.18.2.1 or later. Update snmp to version 5.20.2.2 or later. Update snmp to version 5.20.5 or later.

**Name of the Vulnerable Software and Affected Versions** Erlang/OTP versions 17.0 through 27.3.4.16 Erlang/OTP versions 28.0 through 28.5.0.5 Erlang/OTP versions 29.0 through 29.0.5 **Description** Improper validation of input quantities in the inets httpc module allows a malicious or compromised HTTP server to degrade availability. The issue occurs when the server returns a numeric header containing an excessively long sequence of digits. Specifically, `httpc handler.erl` uses the `list to integer/1` function to convert the `Content-Length` header before comparing it against `max body size`, meaning the size check does not prevent the conversion process. Similar unbounded conversions exist in the `format response/1` function for `Content-Length` and the `get ms from retry after/1` function for the `Retry-After` header. Because the conversion function supports arbitrary-precision arithmetic, processing up to 1.26 million digits can consume significant CPU resources, causing delays of hundreds of milliseconds per response for the requesting process. **Recommendations** Update Erlang/OTP to version 27.3.4.17 or later. Update Erlang/OTP to version 28.5.0.6 or later. Update Erlang/OTP to version 29.0.6 or later.

**Name of the Vulnerable Software and Affected Versions** Erlang/OTP versions 17.0 through 27.3.4.16 Erlang/OTP versions 28.0 through 28.5.0.5 Erlang/OTP versions 29.0 through 29.0.5 **Description** Improper validation of input quantity in the eldap module allows a malicious or compromised LDAP server to degrade availability. The issue occurs when the server returns a referral URL containing a port component consisting of an excessively long sequence of digits. The function `parse port/2` passes the port substring to `list to integer/1` without a length bound. Because the conversion function accepts integers of any size, a syntactically valid port of up to approximately 1.26 million digits can be processed, consuming significant CPU resources through arbitrary-precision arithmetic. This flaw is triggered when an application passes a server-supplied referral to the `parse ldap url/1` function. **Recommendations** Update Erlang/OTP to version 27.3.4.17 or later. Update Erlang/OTP to version 28.5.0.6 or later. Update Erlang/OTP to version 29.0.6 or later.

**Name of the Vulnerable Software and Affected Versions** Erlang/OTP versions 21.0 through 27.3.4.16 Erlang/OTP versions 28.0 through 28.5.0.5 Erlang/OTP versions 29.0 through 29.0.5 stdlib versions 3.5 through 6.2.2.4 stdlib versions 7.0 through 7.3.0.1 stdlib versions 8.0 through 8.0.3 **Description** Improper validation of input quantity in the stdlib allows a remote attacker to degrade availability by providing a URI with a port component consisting of an excessively long sequence of digits. The function `uri string:get port/1` passes the port substring to `binary to integer/1` without a length bound. Consequently, a syntactically valid port of up to approximately 1.26 million digits can be converted successfully, consuming hundreds of milliseconds of arbitrary-precision arithmetic in the calling process. This conversion is triggered via every authority-parsing path in `uri string:parse/1`, including host, registered-name, and IPv4 and IPv6 forms. Any application using `uri string:parse/1` to parse attacker-supplied URIs is exposed. **Recommendations** Update Erlang/OTP to version 27.3.4.17 or later. Update Erlang/OTP to version 28.5.0.6 or later. Update Erlang/OTP to version 29.0.6 or later. Update stdlib to version 6.2.2.5 or later. Update stdlib to version 7.3.0.2 or later. Update stdlib to version 8.0.4 or later.

**Name of the Vulnerable Software and Affected Versions** Elixir versions 1.15.0-rc.0 through 1.18.4 Elixir versions 1.19.0-rc.0 through 1.19.5 Elixir versions 1.20.0-rc.0 through 1.20.3 **Description** An uncontrolled recursion issue in the standard library allows an attacker who controls a list passed to the `inspect/1`, `List.to string/1`, or `List.to charlist/1` functions to exhaust the memory of a BEAM node. The problem occurs when a list's printable prefix exceeds the `:printable limit` (default 4096 elements) but contains a subsequent element that is not a valid code point, such as an atom or an out-of-range integer. This causes the list to be misclassified as a charlist, leading to an `ArgumentError`. In `List.to string/1` and `List.to charlist/1`, the rescue clause attempts to build an error message by calling `inspect(list)`, which re-triggers the same error path. Because this recursion is not in tail position, the process stack grows until the node runs out of memory or the process is killed by `max heap size`. **Recommendations** Update Elixir to version 1.18.5 or later. Update Elixir to version 1.19.6 or later. Update Elixir to version 1.20.4 or later. As a temporary workaround, install a global inspect function via the application start callback using `Inspect.Opts.default inspect fun/1` with `fn term, opts -> Inspect.inspect(term, %{opts | charlists: :as lists}) end` to prevent the charlist branch from being entered.

**Name of the Vulnerable Software and Affected Versions** phoenix live view versions 0.5.0 through 1.0.18 phoenix live view versions 1.1.0-rc.0 through 1.1.32 phoenix live view versions 1.2.0-rc.0 through 1.2.8 **Description** An Open Redirect issue exists where an attacker can redirect a victim's browser to an arbitrary origin. This occurs because the `redirect/2` function uses `validate local url!/2` to ensure the target is a local path, but it fails to reject ASCII tab, LF, or CR characters. Since browsers strip these characters before parsing the URL, a value like `/<TAB>/example.com` bypasses validation and is interpreted as a scheme-relative URL. The `push patch/2` function is also affected in versions prior to 0.7.0. The issue is triggered when the application passes an externally influenced value as the `:to` parameter, such as a `return to` parameter during sign-in or a navigation target from a `handle event/3` payload. **Recommendations** Update phoenix live view to version 1.0.19 or later. Update phoenix live view to version 1.1.33 or later. Update phoenix live view to version 1.2.9 or later. Reject any untrusted value containing ASCII tab, LF, or CR before passing it as the `:to` parameter to `redirect/2` or `push patch/2` (for versions prior to 0.7.0). Map client-supplied navigation targets to a fixed set of known-good paths instead of forwarding the value directly.

**Name of the Vulnerable Software and Affected Versions** postgrex versions 0.19.3 through 0.22.3 **Description** An SQL Injection issue exists in the postgrex library used by elixir-ecto. The flaw occurs when the `:comment` option is used within the `Postgrex.stream/4` function or the `Ecto.Repo.stream/2` function. An attacker capable of influencing the value of the `:comment` variable can use the `*/` sequence to close the comment delimiter and append unauthorized SQL clauses that execute with the privileges of the connection's role. This happens because the software concatenates the comment into the statement text sent in the Parse message without escaping or rejecting the `*/` sequence, and the `stream/4` function fails to call the `comment not present!/1` validation function used elsewhere. The injection is limited to the streamed statement as the Parse message only accepts a single command. **Recommendations** Update postgrex to version 0.22.4 or later. As a temporary workaround, reject any `:comment` value containing `*/` or a null byte before passing it to `Postgrex.stream/4` or `Ecto.Repo.stream/2`. Ensure that comments are built only from trusted values.

**Name of the Vulnerable Software and Affected Versions** livebook versions 0.5.0 through 0.18.6 livebook versions 0.19.0 through 0.19.8 **Description** An origin validation error allows untrusted notebook output JavaScript to trigger session-wide keyboard shortcuts. The JS-view feature renders JavaScript in a sandboxed, cross-origin iframe. However, the iframe shell in `iframe/priv/static/iframe/v5.html` forwards `keydown` events to the parent page without verifying `Event.isTrusted`. Consequently, events synthesized via `window.dispatchEvent` are treated as genuine keystrokes. The relay in `assets/js/hooks/js view.js` re-dispatches these events, which are then processed by the global shortcut handler in `assets/js/hooks/session.js` during the capture phase. This allows sandboxed scripts to execute shortcuts in `LivebookWeb.SessionLive`, such as forcing the evaluation of all cells in the notebook or restarting the runtime, which discards in-memory state. A third shortcut can delete the focused cell. The most critical impact is the forced full evaluation, which executes the notebook's Elixir code without user consent. This can occur when a user opens a notebook from a third party or published documentation, and the effect is mirrored to all connected collaborators. **Recommendations** Update livebook versions 0.5.0 through 0.18.6 to version 0.18.7. Update livebook versions 0.19.0 through 0.19.8 to version 0.19.9.

**Name of the Vulnerable Software and Affected Versions** livebook versions 0.13.0 through 0.18.6 livebook versions 0.19.0 through 0.19.8 **Description** An OS Command Injection issue exists where deployment setup commands are generated without proper shell escaping of environment variable values. The functions `docker instructions/2` and `fly instructions/4` in `lib/livebook web/live/hub/teams/deployment group agent component.ex` interpolate these values, which are processed through `online docker info/3`. Because values are placed within double-quoted shell words, an attacker with privileges to set deployment group environment variables can use command substitution (such as `$(...)` or backticks) or double quotes to inject arbitrary commands. These commands are then executed on the local machine of any user who copies and runs the generated setup instructions from the web interface. Kubernetes instructions are not affected as they use YAML manifest escaping. **Recommendations** Update livebook versions 0.13.0 through 0.18.6 to version 0.18.7. Update livebook versions 0.19.0 through 0.19.8 to version 0.19.9.

**Name of the Vulnerable Software and Affected Versions** livebook versions 0.11.0 through 0.18.6 livebook versions 0.19.0 through 0.19.8 **Description** A Relative Path Traversal issue allows an attacker to write a file with controlled content to an arbitrary path on the system. This occurs because the import path in `Livebook.LiveMarkdown.Import.file entry metadata to attrs/1` takes the name from the notebook source verbatim without validation. For URL-type file entries, the function `Livebook.Session.file entry cache file/2` resolves the name beneath the session temporary directory without verifying if the result remains within that directory. Additionally, `Livebook.FileSystem.Utils.resolve unix like path/2` collapses parent-directory segments but only clamps at the filesystem root. Consequently, when content is requested and no cache exists, the system writes the response body to the resolved path, creating parent directories as needed. This allows an attacker to control both the destination and content of the written file anywhere the process has write permissions. A similar lack of containment check exists in `Livebook.Session.to attachment file entry/2`. A victim triggers this by opening an attacker-supplied notebook and causing the entry to be fetched within their authenticated session. **Recommendations** Update livebook versions 0.11.0 through 0.18.6 to version 0.18.7. Update livebook versions 0.19.0 through 0.19.8 to version 0.19.9.

**Name of the Vulnerable Software and Affected Versions** livebook versions 0.15.0 through 0.18.6 livebook versions 0.19.0 through 0.19.8 **Description** A Cross-Site Request Forgery (CSRF) issue exists when Livebook is configured to use Livebook Teams for identity. The `handle request/4` function in `lib/livebook/zta/livebook teams.ex` processes OAuth-style callbacks containing a `teams identity` marker and a `code` parameter. Because the `create auth request/1` function in `lib/livebook/teams/requests.ex` does not generate a state or nonce, the system fails to verify if the callback corresponds to the session that initiated the login. An attacker within the same Livebook Teams organization can initiate a login flow, capture the authorization code, and trick a victim into opening a URL containing that code. This causes the victim's session to be bound to the attacker's identity. Consequently, any work, secrets, or data produced by the victim are attributed to and accessible by the attacker, while the victim believes they are using their own account. **Recommendations** Update livebook versions 0.15.0 through 0.18.6 to version 0.18.7. Update livebook versions 0.19.0 through 0.19.8 to version 0.19.9.

**Name of the Vulnerable Software and Affected Versions** livebook versions 0.19.7 through 0.19.8 **Description** A failing open issue in livebook allows an unauthenticated network client to gain full access to a server that enforces identity through Livebook Teams. This occurs when a Livebook Agent or App Server caches a deployment group identifier that becomes unresolvable, such as when the group is deleted while the agent is disconnected. The function `handle call/3` in `lib/livebook/hubs/team client.ex` fails to distinguish between an unresolvable group and one where identity enforcement is disabled, leading the system to report enforcement as switched off. Consequently, the `authenticate/3` function in `lib/livebook/zta/livebook teams.ex` returns empty identity metadata, which `build current user/3` in `LivebookWeb.UserPlug` merges into a new user with default full access. This is then granted access by `authorized?/1` in `LivebookWeb.AuthPlug`. An attacker can exploit this to read notebooks and secrets, execute code on the server's runtime, and disrupt operations. **Recommendations** Update livebook to version 0.19.9 or later.

**Name of the Vulnerable Software and Affected Versions** phoenix live view versions 1.2.2 through 1.2.6 **Description** A cross-site scripting issue exists in phoenix live view due to improper URL scheme validation. The functions `valid destination!/2` and `valid live navigation destination!/2` use an internal `uri scheme/1` helper that fails to detect schemes if the input begins with a space or an ASCII control character. Because standard browsers strip these leading characters before parsing, an attacker can provide a payload like " javascript:alert(1)" that bypasses validation and is treated as a safe relative path. When rendered via `<.link href={...}>`, the browser executes the script in the victim's session. This affects applications that render user-supplied URLs, such as redirect targets or profile links. **Recommendations** Update phoenix live view to version 1.2.7 or later.

**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** plug versions 1.15.0 through 1.15.4 plug version 1.16.4 plug version 1.17.2 plug version 1.18.3 plug version 1.19.3 **Description** Inefficient algorithmic complexity in the nested-parameter decoder allows an unauthenticated remote attacker to cause a denial of service. The functions `Plug.Conn.Query.decode/4` and `Plug.Conn.Query.decode each/2` parse query strings and application/x-www-form-urlencoded request bodies. When a key contains numerous bracketed segments, the decoder performs a map operation for each nesting level using an ever-growing binary prefix of the key, resulting in a quadratic decode cost. With a default body limit of 1,000,000 bytes, a single request can contain approximately 333,000 nesting levels, saturating a BEAM scheduler for several minutes. A small number of concurrent requests can saturate all schedulers, rendering the server unresponsive. This issue involves the file lib/plug/conn/query.ex and the routines `Plug.Conn.Query.decode/4`, `Plug.Conn.Query.decode each/2`, `Plug.Conn.Query.split keys/6`, `Plug.Conn.Query.insert keys/3`, and `Plug.Conn.Query.finalize pointer/2`. **Recommendations** Update plug versions 1.15.0 through 1.15.4 to version 1.15.5. Update plug version 1.16.4 to a non-vulnerable version. Update plug version 1.17.2 to a non-vulnerable version. Update plug version 1.18.3 to a non-vulnerable version. Update plug version 1.19.3 to a non-vulnerable version.

**Name of the Vulnerable Software and Affected Versions** Elixir versions 1.5.0 through 1.20.0 **Description** Uncontrolled Resource Consumption in the standard library's Version module allows an attacker to cause a denial of service via CPU and memory exhaustion. The version parser converts numeric components to integers without bounding their length, forcing a super-linear, non-yielding base-10 to arbitrary-precision integer conversion through `String.to integer/1` (also known as `:erlang.binary to integer/1`). This process pins a BEAM scheduler, and larger components can trigger an uncaught `SystemLimitError` that crashes the calling process. A string of approximately one megabyte is sufficient to trigger this issue, and no authentication is required. The issue is reachable via the `parse digits/2` routine in `lib/version.ex` and public entry points including `Version.parse/1`, `Version.parse!/1`, `Version.match?/3`, `Version.compare/2`, and `Version.parse requirement/1`. **Recommendations** Update to version 1.20.1.