José Valim

An unauthenticated remote attacker can cause memory exhaustion in both the application and the database server. This occurs when the application interpolates user-supplied data into `json extract path/2`, `field[^key]`, or `splice/1`. Ecto caches prepared queries in an ETS table without size limits or eviction policies. Because interpolated JSON path elements and `splice/1` expansions become part of the query expression rather than parameters, every unique key or list length creates a new cache entry. When using ecto sql, each entry also generates a new prepared statement on the database connection. This memory is not released until the processes restart.

An insecure temporary file issue in Mix `deps.partition` allows a local user to execute arbitrary code as another user. During partitioned dependency compilation, the project configuration is passed to partition VMs via a file in a fixed-name directory within the shared system temporary directory. The function `Mix.Tasks.Deps.Partition.server/4` in `lib/mix/lib/mix/tasks/deps.partition.ex` uses `File.mkdir p/1` to create this directory, which does not verify the directory owner if it already exists. A local attacker can pre-create the directory and replace the configuration file before the `client/0` function reads it. The client then decodes the malicious file using `:erlang.binary to term/1` and executes injected shell commands via the `compile:` option of dependencies. Additionally, the world-readable nature of the partition file may disclose project configurations to other local users. This issue requires partitioned compilation to be enabled via the `MIX OS DEPS COMPILE PARTITION COUNT` variable and a shared system temporary directory.

An improper validation of input quantity in the `URI` module of the Elixir standard library allows an attacker to cause a denial of service through CPU exhaustion by supplying a URL with an excessively long port component. The `URI.parse/1` function uses `String.to integer/1` within `split authority/1` to convert the port without bounding its length, allowing the creation of a bignum (a large integer) of up to 1,262,592 decimal digits. When this parsed URI is rendered back to text via `URI.to string/1`, `inspect/1`, logging, or error formatting, it utilizes `:erlang.integer to binary/1`. On Erlang/OTP 27, 28, and 29.0, this conversion process is quadratic, meaning the CPU time required increases significantly as the number of digits grows. For example, a port with 400,000 digits can take approximately 2.6 seconds to render, while a 1 MB port can take about 18 seconds. This can lead to CPU exhaustion on servers that parse and subsequently log or echo user-supplied URLs provided in form or JSON body fields.

Improper validation of specified quantity in input within the Elixir standard library's `JSON` module allows an unauthenticated attacker to cause a denial of service through CPU and memory exhaustion by supplying a specially crafted JSON document. The functions `JSON.decode/1` and `JSON.decode!/1` use `erlang:binary to integer/1` to convert integer literals without bounding their length. Consequently, an integer literal with one million digits consumes 100 to 300 times more CPU than a string of the same length, and literals exceeding approximately 1.29 million digits trigger a `SystemLimitError`. Applications generated by `phx.new` are particularly susceptible as they decode request bodies using `Plug.Parsers` before routing and authentication occur.

An unauthenticated remote attacker can expose the secret key base or other sensitive secrets through application logs by providing wrong-typed arguments. This occurs because public functions in `Plug.Crypto` use function-head guards for argument validation. When a guard fails, the Erlang VM raises a `FunctionClauseError` that includes the actual argument values in the top stack frame. Since the library's `rescue` blocks and the `Plug.Crypto.prune args from stacktrace/1` function only handle exceptions raised within a function body, they do not catch guard failures. Consequently, Plug.Cowboy and Bandit write this frame to the error log and attach it as `crash reason` metadata, which may be forwarded to error trackers. Two primary entry points are affected: - `Plug.Crypto.verify/4` exposes the secret key base when the token is neither a binary nor nil. - `Plug.Crypto.secure compare/2` exposes the server-side secret when one operand is not a binary, such as when a missing request header results in a nil value. Accessing the leaked information requires separate access to the application logs or the error tracker.

An issue exists where improper neutralization of input during web page generation allows mutation Cross-site Scripting (XSS). This occurs during a parse and serialize round-trip of attacker-supplied HTML. The functions `LazyHTML.to html/2` and `LazyHTML.Tree.to html/2` determine whether to escape an element's text based solely on its tag name. Consequently, a `style` or `script` element within SVG or MathML foreign content is parsed with decoded character references but serialized as an HTML raw-text element, causing the text to be emitted unescaped. This allows encoded markup to close the element upon re-parsing and become active markup. Applications that parse untrusted HTML, filter the document or tree, and then serialize it for display are affected because the payload remains a plain text node that bypasses element or attribute filters.

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.

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.

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.

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.

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`.

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.

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.

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.

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.

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.

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.

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.

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.

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`.