Jonatan Männchen

**Name of the Vulnerable Software and Affected Versions** Erlang OTP versions 27.1 through 27.3.4.14 Erlang OTP versions 28.0 through 28.5.0.3 Erlang OTP versions 29.0 through 29.0.3 **Description** A relative path traversal issue in the stdlib zip module allows writing files outside the intended extraction directory when processing a crafted zip archive. The functions `zip:unzip/1,2` and `zip:extract/1,2` use `zip:check dir level/2` to validate entry paths by tracking directory depth with an integer counter. Because the validation only rejects paths where the final counter value is negative, a path like `../x/y` can cause the counter to go negative during traversal and then return to zero, bypassing the check and resolving to a location outside the extraction directory via `add cwd`. This issue is located in the `lib/stdlib/src/zip.erl` file. **Recommendations** Update Erlang OTP to version 27.3.4.15 or later. Update Erlang OTP to version 28.5.0.4 or later. Update Erlang OTP to version 29.0.4 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** 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** 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** elixir-grpc versions 0.8.0 through 0.9.x **Description** Authenticated attackers can access or modify resources belonging to other users by smuggling a conflicting value for any path-bound field via the query string or request body. This occurs in the `map request/5` function within `Elixir.GRPC.Server.Transcode` (lib/grpc/server/transcode.ex), where `Map.merge/2` is used with path bindings as the first argument, granting them the lowest merge precedence. Consequently, a request such as 'GET /users/me/profile?user id=victim' or a POST request containing `user id` in the body results in a decoded protobuf struct where the path-bound field is overwritten by the attacker-supplied value. This allows the bypass of handlers using these fields for authorization, ownership checks, or multi-tenancy scoping. This issue requires HTTP-to-gRPC transcoding to be enabled. **Recommendations** Update to version 1.0.0 or later.

**Name of the Vulnerable Software and Affected Versions** grpc versions 0.3.1 through 0.9.x **Description** Unauthenticated attackers can exhaust the BEAM memory and crash the server by streaming a large or slow-trickle unary request body. The function `read full body/3` in 'Elixir.GRPC.Server.Adapters.Cowboy.Handler' accumulates every received chunk into a single growing binary without a size cap. Furthermore, if the client omits the `grpc-timeout` header, the per-chunk read timeout is set to infinity, enabling a slow-trickle client to maintain the connection indefinitely while memory consumption increases. A single connection is enough to exhaust server memory and crash the node. **Recommendations** Update to version 1.0.0 or later.

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

**Name of the Vulnerable Software and Affected Versions** tesla versions 1.3.0 through 1.18.2 **Description** An issue in Tesla.Adapter.Mint allows for a denial of service via atom table exhaustion. The function `open conn/2` converts the URL scheme of outgoing requests into a BEAM atom using `String.to atom(uri.scheme)` without allow-list validation. BEAM atoms are permanent entries that are not garbage-collected and are limited to a bounded table of approximately 1,048,576 entries. An attacker capable of influencing the request URL—through application-level URL-forwarding features like webhooks, proxies, or importers, or via a Location header when `Tesla.Middleware.FollowRedirects` is active—can create a new atom for each request by varying the scheme string. Once the atom table is full, the virtual machine crashes, resulting in a complete application shutdown. **Recommendations** Update to version 1.18.3.

**Name of the Vulnerable Software and Affected Versions** tesla versions 0.6.0 through 1.18.2 **Description** Improper handling of highly compressed data allows a denial of service via a decompression bomb in HTTP response bodies. When `Tesla.Middleware.DecompressResponse` or `Tesla.Middleware.Compression` is included in a middleware pipeline, response bodies are decompressed eagerly without a size limit. Specifically, the `decompress body/2` function passes the entire response body to `:zlib.gunzip/1` or `:zlib.unzip/1` without capping the output size. Furthermore, the `compression algorithms/1` function splits the `content-encoding` header on commas, and `decompress body/2` recurses for each token. A server providing multiple gzip layers in the `content-encoding` header can cause exponential amplification, where a small payload inflates to gigabytes of BEAM heap, exhausting memory and crashing or freezing the process. **Recommendations** Update to version 1.18.3. As a temporary workaround, avoid including `Tesla.Middleware.DecompressResponse` or `Tesla.Middleware.Compression` in the Tesla middleware pipeline.

**Name of the Vulnerable Software and Affected Versions** tesla versions 0.8.0 through 1.18.2 **Description** Improper Neutralization of CRLF Sequences in HTTP Headers, also known as HTTP Request/Response Splitting, allows HTTP header injection. The function `add content type param/2` within the `Tesla.Multipart` module appends caller-supplied strings to the `content type params` list without validating for Carriage Return (`r`) or Line Feed (` `) characters. Subsequently, the `headers/1` function in `Tesla.Multipart` joins these parameters verbatim to construct the outgoing Content-Type header. If a parameter contains `r `, it splits the header line, enabling the injection of arbitrary headers into the outbound HTTP request. This occurs when an application forwards untrusted input, such as a user-supplied charset or parameter string, into the `add content type param/2` function. **Recommendations** Update to version 1.18.3 or later. As a temporary workaround, validate content-type parameter strings before passing them to the `add content type param/2` function, rejecting any value that contains `r` or ` `.

**Name of the Vulnerable Software and Affected Versions** tesla versions 0.8.0 through 1.18.2 **Description** Improper encoding or escaping of output allows multipart part header injection through unescaped `Content-Disposition` parameter values. The function `part headers for disposition()` interpolates disposition parameters without validating carriage return (`r`), line feed (` `), or double-quote characters. These values are received from the caller via `add field()` (the `name` parameter), `add file()` (the `filename` parameter), and `add file content()` (the `filename` parameter and other disposition options). A double-quote character can close a quoted parameter prematurely, while `r ` sequences can terminate the `Content-Disposition` header to start a new forged header or end the header block to prepend bytes to the part body. Additionally, the default filename path in `add file()` uses `Path.basename()`, which does not strip carriage returns or line feeds. **Recommendations** Update to version 1.18.3. Validate disposition parameter values before passing them to `add field()`, `add file()`, or `add file content()`, rejecting any value containing `r`, ` `, or double-quotes.

**Name of the Vulnerable Software and Affected Versions** tesla versions 1.4.0 through 1.18.2 **Description** Improper handling of case sensitivity in the `Tesla.Middleware.FollowRedirects` middleware allows credential leakage to third-party origins during cross-origin redirects. The system uses a case-sensitive string comparison against a lowercase filter list containing `authorization` and `host` to strip security-sensitive headers. However, because HTTP header names are case-insensitive per RFC 7230 and Tesla preserves header keys verbatim, headers using canonical casing, such as `Authorization`, do not match the lowercase filter and are forwarded to the redirect destination. An attacker capable of influencing a `Location:` response can capture bearer tokens or other authorization material. **Recommendations** Update to version 1.18.3. Normalize all header keys to lowercase before passing them to the software, specifically using `authorization` instead of `Authorization` when setting headers via `Tesla.put header/3` or `Tesla.Middleware.Headers`.

**Name of the Vulnerable Software and Affected Versions** oban web versions 2.12.0 through 2.12.4 **Description** Uncontrolled Resource Consumption in the `Elixir.Oban.Web.CronExpr` module allows memory exhaustion through unbounded cron range expansion. An attacker with permissions to schedule cron jobs can submit a malicious cron expression. When a user with dashboard access views the cron job list, the `describe/1` function is called to render the expression. The `parse range/1` function parses range endpoints using `Integer.parse/1` without bounds checks, and the `expand dom parts/1` and `expand dow parts/1` helpers eagerly materialize the range via `Enum.to list/1`. This process can lead to the allocation of approximately 2.4 GB of memory, resulting in the stalling or crashing of the BEAM node (the Erlang Virtual Machine). **Recommendations** Update oban web to version 2.12.5.

**Name of the Vulnerable Software and Affected Versions** oban web versions 2.12.0 through 2.12.4 **Description** A missing authorization issue in the `Elixir.Oban.Web.Jobs.DetailComponent` module allows unauthorized job worker substitution. The `handle event("save-job", ...)` handler fails to perform authorization checks, whereas other handlers like cancel, delete, and retry verify privileges using `can?/2`. An authenticated user with `:read only` access can send a forged `save-job` LiveView WebSocket event to overwrite a job's worker field with any other existing `Oban.Worker` module in the application. Consequently, during the next execution attempt, Oban will invoke the `perform/1` function on the module chosen by the attacker instead of the intended one. This occurs when the Oban.Web dashboard is deployed and accessible to users with limited job-management privileges. **Recommendations** Update to version 2.12.5.

**Name of the Vulnerable Software and Affected Versions** hackney versions 2.0.0 through 4.0.0 **Description** Improper Neutralization of CRLF Sequences, also known as CRLF Injection, allows HTTP Request/Response Splitting. The WebSocket upgrade code in `src/hackney ws.erl` copies the host, path, headers (`ExtraHeaders`), and protocols options from the caller-supplied opts map into the internal `#ws data{}` record in `init/1` and then splices them verbatim into the raw HTTP/1.1 upgrade request by binary concatenation in `do handshake/1`. Because no CRLF or NUL stripping is performed at these four injection sites, an attacker controlling these options—such as by forwarding URL components or header values from untrusted input into `hackney ws:start link/1`—can inject arbitrary HTTP headers into the outbound WebSocket upgrade request. This can lead to header injection, credential spoofing toward the upstream server, log and cache poisoning, or request smuggling via intermediary proxies. **Recommendations** Update to version 4.0.1.

**Name of the Vulnerable Software and Affected Versions** hackney versions 2.0.0 through 4.0.0 **Description** An allocation of resources without limits or throttling allows flooding. The function `await response loop/6` in `hackney h3` accumulates the HTTP/3 response body in memory without a size cap. Because the timeout clause acts as a per-message inactivity timer that resets upon receiving chunks, housekeeping messages, or settings frames rather than a fixed deadline, a malicious HTTP/3 server can keep the loop active indefinitely. By emitting small chunks just before the timeout expires with `Fin` set to false and omitting a final frame, the server causes the accumulation buffer to grow linearly, exhausting the BEAM process heap and leading to an out-of-memory condition. This issue occurs when the application uses the HTTP/3 transport via `hackney h3` or by passing `{transport, h3}` to `hackney:request/5`. **Recommendations** Update to version 4.0.1. As a temporary mitigation, avoid using the HTTP/3 transport by not calling `hackney h3` directly and avoiding the `{transport, h3}` option in `hackney:request/5`.

**Name of the Vulnerable Software and Affected Versions** benoitc hackney versions 3.1.1 through 4.0.0 **Description** A sensitive data exposure issue exists where the HTTP/3 redirect handler in `src/hackney h3.erl` passes original request headers to a redirect target without performing cross-origin checks. If a client makes an HTTP/3 request with `follow redirect` enabled and includes `Authorization` or `Cookie` headers, a server responding with a 3xx redirect to a different host will cause the client to forward these credentials verbatim to the new origin. This occurs because `hackney h3.erl` lacks the protection provided by the `maybe strip auth on redirect()` function found in the main `hackney.erl` module. **Recommendations** Update to version 4.0.1.

**Name of the Vulnerable Software and Affected Versions** hackney versions 2.0.0 through 4.0.0 **Description** The WebSocket client in `src/hackney ws.erl` lacks upper bounds on memory consumption across three code paths, allowing for flooding. First, the `read handshake response/3` function accumulates received bytes into a buffer without a size cap; a server streaming bytes without the required termination sequence causes the buffer to grow until memory is exhausted. Second, the `parse payload/9` and `parse active payload/8` functions do not validate declared frame payload lengths, which can be up to 2^63-1 bytes per RFC 6455, leading to Out-of-Memory (OOM) conditions when a server announces a very large frame. Third, the `frag buffer` field in `#ws data{}` accumulates continuation frames indefinitely if a server sends a stream of non-final fragmented frames without a final frame. An attacker only needs to control the WebSocket server the client connects to, requiring no authentication or special configuration. **Recommendations** Update to version 4.0.1.