Jonatan Männchen

**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 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.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 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** 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.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** 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 0.9.0 through 4.0.0 **Description** Improper Neutralization of CRLF Sequences, also known as CRLF Injection, allows HTTP Response Splitting. The `setcookie/3` function in `src/hackney cookie.erl` validates Name and Value arguments against CRLF and control characters but concatenates the domain and path options into the output iolist without equivalent checks. An attacker controlling these options, such as by providing a Host header value as the cookie domain or a request path as the cookie path, can inject literal CRLF sequences and arbitrary additional Set-Cookie headers into the HTTP response. **Recommendations** Update to version 4.0.1.

**Name of the Vulnerable Software and Affected Versions** hackney versions 2.0.0-beta.1 through 4.0.0 **Description** An infinite loop exists in the Alt-Svc response header parser within `src/hackney altsvc.erl`. When the `parse token/2` function receives a byte that is not a token, whitespace, or comma (such as !, @, =, or ;), it returns the input unchanged. Similarly, the `skip comma/1` function returns the buffer unchanged if the first byte is not a comma. This causes the `parse entries/2` function to recurse with identical data, creating a tight infinite tail-recursive loop that consumes 100% of the CPU scheduler and prevents the calling process from returning. The entry point `parse and cache/3` is called synchronously during every HTTP response, meaning a single-byte `Alt-Svc: !` response header from any HTTP origin can trigger the hang. **Recommendations** Update hackney to version 4.0.1.

**Name of the Vulnerable Software and Affected Versions** hackney versions 2.0.0 through 4.0.0 **Description** An issue in the URL parser within `src/hackney url.erl` allows for resource exhaustion. The parser uses the `binary to atom/2` function to convert unrecognized URL schemes into permanent BEAM atoms. Since BEAM atoms are not garbage-collected and the atom table has a hard limit of 1,048,576 entries, an attacker can exhaust this table by providing URLs with custom scheme prefixes. This can be achieved through request targets, configured webhook URLs, or Location headers during redirects, leading to a crash of the entire BEAM VM with a `system limit` error. **Recommendations** Update to version 4.0.1.

**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 0.10.0 through 4.0.0 **Description** Uncontrolled Resource Consumption in the SOCKS5 transport within `src/hackney socks5.erl` allows flooding. While the caller-supplied timeout is applied during the SOCKS5 negotiation phase, the connection upgrade to TLS via the `ssl:connect/2` function defaults to an infinite timeout because the `Timeout` variable is not forwarded. Consequently, a hostile SOCKS5 proxy that completes the handshake and then stalls or sends a partial TLS ServerHello can cause the connecting process to block indefinitely, ignoring the `connect timeout` or `recv timeout` options. **Recommendations** Update hackney to version 4.0.1.

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

**Name of the Vulnerable Software and Affected Versions** hackney versions 0 through 4.0.0 **Description** Improper Neutralization of CRLF Sequences allows HTTP Request Splitting. The software fails to percent-encode carriage return (`r`) or line feed (` `) characters in the URL query component before constructing the HTTP/1.1 request target. Specifically, the `hackney url:make url/3` function passes the query binary directly without validation or escaping, violating RFC 3986 Section 3.4. An attacker controlling part of a URL can inject raw CRLF sequences into the query string, enabling the injection of arbitrary HTTP headers or the splitting of the HTTP request. **Recommendations** Update to version 4.0.1.

**Name of the Vulnerable Software and Affected Versions** benoitc hackney versions 0.13.0 through 4.0.0 **Description** An interpretation conflict allows Server Side Request Forgery (SSRF), a flaw where an attacker can induce the server to make requests to an unintended location. The function `hackney url:normalize/2` URL-decodes the host component after the URL has been parsed into a `#hackney url{}` record. Since OTP's `uri string:parse/1` and `inet:parse address/1` do not decode percent-escapes in the host, a URL containing percent-encoded characters can bypass allowlist validators that do not recognize the encoded string as an IP address. Subsequently, the normalizer decodes the host (e.g., converting `%31%32%37%2E%30%2E%30%2E%31` to `127.0.0.1`), enabling TCP connections to the loopback interface, cloud instance metadata services (169.254.169.254), RFC1918 networks, and local admin interfaces. This occurs because `hackney:request/5` always invokes `hackney url:normalize/2` without an opt-out mechanism for requests using binary or list URLs. **Recommendations** Update benoitc hackney 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`.