Eric Meadows-Jönsson

**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** hexpm versions 2025-10-18 through 2026-08-23 **Description** An incorrect authorization issue exists in the OAuth token endpoint. An API key with the `repositories` permission can be used to read private packages belonging to another organization. This occurs during the OAuth `client credentials` grant process within the `validate scopes against key/2` function in `lib/hexpm web/controllers/api/oauth controller.ex`, which allows a requested scope if the key has `repositories` permission and the scope string starts with `repository:`. Because the organization name is not resolved against the principal and the `expand repositories scope/3` function only rewrites the literal `repositories` scope, an explicit `repository:<name>` scope is accepted. Consequently, CDN edges authorize access based on the token claim without database verification, granting read access to the specified organization's private packages until the token expires. **Recommendations** Update hexpm to a version released on or after 2026-08-24.

**Name of the Vulnerable Software and Affected Versions** hex.pm versions 2025-10-10 through 2026-08-23 **Description** An insufficient session expiration issue exists in the OAuth token refresh grant. The `expand repositories scope/3` function in `lib/hexpm/permissions.ex` only rewrites the literal repositories scope, allowing explicitly granted `repository:<org>` or `docs:<org>` scopes to remain unchanged. During the refresh grant process, a new token is derived from the stored `granted scopes` without re-verifying organization membership. Since CDN edges authorize access based on the token claim without querying the database, users removed from an organization can maintain read access to private packages for up to 30 days, which is the refresh token lifetime, instead of the intended 30-minute access token lifetime. **Recommendations** Update hex.pm to a version released on or after 2026-08-24.

**Name of the Vulnerable Software and Affected Versions** elixir-mint versions 0.1.0 through 1.9.2 **Description** An HTTP response smuggling issue exists due to the inconsistent interpretation of HTTP requests. A malicious HTTP/1 server can desynchronize a strict intermediary and the Mint client on a pooled connection, leading to response-queue poisoning for subsequent requests sharing that connection. The `decode body()` function in `lib/mint/http1.ex` uses `Integer.parse(data, 16)` to parse the chunk-size line of a Transfer-Encoding: chunked response. While RFC 7230 forbids sign prefixes for chunk-size, `Integer.parse/2` accepts leading + or - signs. Consequently, a chunk-size line of +5 is treated as a five-byte chunk, and +0 or -0 are treated as terminating zero-length chunks, ending the message body prematurely. An RFC-strict intermediary rejects these forms, causing a disagreement on response boundaries. On pooled keep-alive connections, an attacker-influenced origin can inject bytes that the client attributes to the next legitimate response, corrupting responses for unrelated in-flight requests. This requires a topology where an RFC-strict HTTP/1 intermediary (such as a proxy, load balancer, or WAF) is positioned between the Mint client and the origin, and connections are reused. **Recommendations** Update elixir-mint to version 1.9.3 or later.

**Name of the Vulnerable Software and Affected Versions** elixir-mint versions 0.1.0 through 1.9.1 **Description** A remote HTTP server can cause a denial of service by exhausting memory on the client host. The `Mint.HTTP1.decode headers/5` and `Mint.HTTP1.decode trailer headers/4` functions accumulate parsed response headers and chunked-trailer fields into a per-request list `request.headers buffer` that persists across TCP segments. Because there is no cap on the number of headers or total bytes, and the `:erlang.decode packet(:httph bin, binary, [])` parser is used with unlimited default size limits, a malicious server can stream header or trailer lines indefinitely without sending the terminating blank line. This causes the connection state to grow without bound until the BEAM node is terminated by the operating system's out-of-memory handler. **Recommendations** Update elixir-mint to version 1.9.2 or later.

**Name of the Vulnerable Software and Affected Versions** elixir-mint versions 0.1.0 through 1.9.1 **Description** A remote HTTP/2 server can cause memory exhaustion and a denial of service on the client host. The `handle continuation/3` function in `lib/mint/http2.ex` accumulates header-block fragments from HTTP/2 CONTINUATION frames into a nesting structure that only releases upon receiving a frame with the END HEADERS flag. While there is a size limit check via `assert header block within max size/2`, the protocol allows CONTINUATION frames to have zero-length payloads. An attacker can send an unbounded chain of these zero-length frames, which bypasses the size cap and continuously increases memory consumption by adding one cons cell per frame, eventually leading to out-of-memory termination of the BEAM node. **Recommendations** Update elixir-mint to version 1.9.2 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** 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** 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** mint versions 0.2.0 through 1.8.x **Description** An issue exists where attacker-controlled HTTP/2 servers can exhaust memory in a client via PUSH PROMISE flooding. In the file lib/mint/http2.ex, the function `decode push promise headers and add response/5` inserts a `:reserved remote` entry into `conn.streams` for every promised stream ID. The function `assert valid promised stream id/2` only verifies that the promised ID is even and not already present, failing to consult `client settings.max concurrent streams` at the time of the promise. Because the concurrency cap is only checked when response HEADERS arrive, a server that sends PUSH PROMISE frames but withholds the matching HEADERS can pin entries in `conn.streams` without an upper bound, leading to memory exhaustion. This is possible because HTTP/2 server push is enabled by default via `client settings.enable push`. **Recommendations** Update to version 1.9.0 or later. As a temporary workaround, disable HTTP/2 server push on connections to untrusted servers by passing `client settings: [enable push: false]` to the `connect/4` function.

**Name of the Vulnerable Software and Affected Versions** mint versions 0.1.0 through 1.8.x **Description** Improper Neutralization of CRLF Sequences, also known as CRLF Injection, allows HTTP Request Splitting and HTTP Request Smuggling. In the `encode request line/2` function within `lib/mint/http1/request.ex`, the `method` and `target` arguments are spliced directly into the HTTP/1 request line without character validation. Applications forwarding attacker-controlled input as the HTTP method or target to the `Mint.HTTP.request/5` function are exposed to request-line CRLF injection. This enables an attacker to terminate the request line prematurely, inject arbitrary headers, and smuggle a separate pipelined HTTP request over the same TCP connection. While the `validate request target/2` function introduced in version 1.7.0 rejects CRLF and control characters in the `target` by default, the `method` field remains unvalidated across all versions. **Recommendations** Update to version 1.9.0 or later.

**Name of the Vulnerable Software and Affected Versions** elixir-mint versions 0.1.0 through 1.8.x **Description** An issue exists where attacker-controlled HTTP/2 servers can cause memory exhaustion in a client. This occurs because the HTTP/2 receive path does not cap the accumulator when a HEADERS frame is observed without the END HEADERS flag. Subsequent CONTINUATION frames are appended to `conn.headers being processed` without per-stream size limits or frame-count limits. Additionally, `max header list size` is only enforced on outgoing requests and not on inbound header blocks. A malicious server can stream an endless sequence of CONTINUATION frames, driving the client's iolist to an arbitrary size, which leads to memory exhaustion and BEAM process death. **Recommendations** Update to version 1.9.0 or later. Restrict connections to untrusted servers to HTTP/1 by passing `protocols: [:http1]` to the `Mint.HTTP.connect/4` function to avoid the vulnerable HTTP/2 receive path.

**Name of the Vulnerable Software and Affected Versions** mint versions 0.1.0 through 1.8.x **Description** An inconsistent interpretation of HTTP requests, known as HTTP Request/Response Smuggling, allows attacker-controlled HTTP/1 servers to desynchronize response framing on shared connections. The issue occurs because the HTTP/1 Content-Length parser, specifically the `content length header/1` function in `lib/mint/http1/parse.ex`, uses `Integer.parse/1` to process header values. This allows optional plus (+) or minus (-) sign prefixes; while negative values are rejected, inputs like `+0` or `+123` are accepted as valid lengths, contradicting RFC 7230 which permits only digits. A fronting proxy or load balancer enforcing strict grammar may reject or reframe such headers while Mint treats them as valid. When sockets are reused via keep-alive, pipelining, or pooled connections shared across requesters, this disagreement allows bytes from one response to be attributed to the next, potentially leaking data into a different consumer's response stream if the connection is shared across trust boundaries. **Recommendations** Update to version 1.9.0 or later.

**Name of the Vulnerable Software and Affected Versions** ericmj decimal versions 0.1.0 through 2.x **Description** Uncontrolled Resource Consumption allows unauthenticated remote Denial of Service. The library does not bound the exponent on parsed input, meaning a decimal with an excessively large exponent can be stored without error. Subsequent calls to functions such as `Decimal.add/2`, `Decimal.sub/2`, `Decimal.div/2`, `Decimal.to integer/1`, `Decimal.round/3`, `Decimal.compare/3` with a threshold, or `Decimal.to string/2` using :normal or :xsd formats allocate memory proportional to the exponent value. This can exhaust available memory and crash the BEAM VM (the Erlang Virtual Machine). Any application accepting user-supplied decimal input for arithmetic, rounding, integer conversion, or string formatting is exposed, as a single malicious request can cause an out-of-memory crash. **Recommendations** Update to version 3.0.0 or later.