Eric Meadows-Jönsson

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

An infinite loop issue exists in the `erl tar` module (and its variants `hex erl tar`, `mix hex erl tar`, and `r3 hex erl tar`) when extracting tar archives. An attacker can cause a denial of service by providing a crafted GNU sparse member where the sparse map ends before the actual size of the member. During extraction, the `erl tar:extract/1,2` function uses `erl tar:stream to file loop/3` to read data in chunks. In affected versions, the `erl tar:do sparse read/3` function matches a trailing-hole clause before a zero-length clause, leading to unbounded recursion that consumes a scheduler and keeps the process busy indefinitely. This can be triggered with an archive as small as 2048 bytes. The `{max size, N}` option only prevents this if N is smaller than the real size of the member. Extraction using the `memory` option is not affected.

A path traversal issue exists where a malicious package publisher can delete a directory outside the project's ` build` directory and extract package files into it when a developer fetches dependencies. This occurs because rebar3 uses the `app` field from a Hex registry dependency to name the dependency without validation. Specifically, the `rebar packages:parse deps/1` function assigns the name, and `rebar app utils:dep to app/7` builds the directory path. Subsequently, `rebar fetch:download source online/2` deletes the resolved directory using `rm -rf` and moves the fetched package into it. If a publisher sets the `app` field to a value containing path traversal sequences like `../../../../target`, rebar3 will delete and overwrite the directory that the path resolves to. This process happens before the dependency's `rebar.config.script` is evaluated. Replacing a directory whose contents are later executed or loaded can lead to remote code execution.

Improper validation of integrity check values allows a package mirror to substitute a tarball when using the `mix hex.package fetch PACKAGE VERSION --output -` command. Hex typically compares a fetched tarball's inner and outer checksums with the repository's signed registry; however, the standard output branch writes bytes returned by the `Hex.SCM.fetch/3` function without this comparison. Additionally, `Hex.SCM.fetch/3` does not verify freshly downloaded tarballs. When a mirror configured via `HEX MIRROR URL` or `mirror url` serves altered bytes, the command prints them and exits successfully. Furthermore, Hex prints diagnostics to standard output, including the body of failed HTTP responses or API warnings from the `x-hex-message` header. A mirror can respond to these requests with an error containing a tar archive, which is then written to standard output before the verified tarball. This allows a pipeline unpacking the standard output to extract files provided by the mirror, even if the checksum check subsequently fails.

A protection mechanism failure allows a package owner or an attacker with account access to bypass the release-age cooldown. The cooldown, configured via `cooldown` or `HEX COOLDOWN`, normally withholds versions younger than a specific age during dependency resolution. However, when a release locked in `mix.lock` is retired or has a security advisory, the functions `Hex.RemoteConverger.build cooldown bypass/3` and `Hex.RemoteConverger.unsafe lock bypass/1` lift the cooldown for that package and its dependencies to allow `mix deps.update` to move to a safe release. Because `Hex.Registry.Cooldown.versions/2` checks the bypass by package name alone, an attacker can publish a malicious release and retire the currently locked version, forcing the system to select the new malicious release regardless of its age. This bypass also extends to packages with the same name in other repositories. This issue does not affect cooldowns configured through organization dependency policies.

Improper neutralization of escape, meta, or control sequences allows a malicious package publisher or a hostile repository server to inject terminal control sequences into the output of Mix tasks. The software prints strings from the package repository and documentation search service directly to the terminal via `Hex.Shell.info/1` and `Hex.Shell.error/1` without neutralizing control characters. This affects package metadata, configuration snippets in `mix hex.info`, search results in `mix hex.package search` and `mix hex.search`, owner and organization listings, publish and sponsor URLs, the authenticated username in `mix hex.user`, policy identities in `mix hex.policy`, and API error bodies rendered by `Hex.Utils.print error result/1`. An attacker can embed ANSI escape sequences—such as cursor movement, line erase, carriage returns, and OSC 52 clipboard writes—or Unicode bidirectional overrides to forge displayed URLs, package descriptions, and suggested commands, conceal real output, or write to the clipboard. This can be triggered by any developer running a documentation search that surfaces a malicious package.

An improper handling of highly compressed data, known as data amplification, allows an untrusted package mirror to exhaust the memory or disk space of a machine running `mix deps.get`, `mix deps.update`, `mix hex.package fetch`, or `mix hex.docs fetch`. This occurs when a mirror is configured via `HEX MIRROR URL`, `HEX MIRROR`, or `mirror url`. Technical details include: - The function `Hex.HTTP.request/5` reads the entire response body into memory and decompresses it using `:zlib.gunzip/1` if the `Content-Encoding` contains `gzip`, without limits on compressed or decompressed size. This affects registry, package, docs, and API responses. - Package tarballs lack download size limits. In version 2.5.1, the entire tarball is held in memory and written to cache before the 16 MiB limit is checked during unpacking. - The commands `mix hex.docs fetch` and `mix hex.docs offline` write docs tarballs to disk and extract them using `:mix hex erl tar.extract/2` without applying the 16 MiB compressed and 128 MiB decompressed limits used by `mix hex tarball:unpack docs/3`. - Registry responses are decompressed before their signatures are verified.

Improper handling of highly compressed data leads to a data amplification issue where an untrusted repository mirror or a server responding to API requests can exhaust the memory of the Erlang VM. In the `hex repo` module, the functions `get names()`, `get versions()`, `get package()`, and `get policy()` decompress registry responses using `zlib:gunzip/1` and decode the signed envelope before the signature is verified. This allows a mirror to provide a small compressed response that expands into an envelope of arbitrary size. Additionally, `hex api` decodes responses with the `application/vnd.hex+erlang` content type via `hex safe binary to term:safe binary to term/1`, which utilizes `binary to term(Binary, [safe])`. While the safe option prevents atom creation, it does not limit the size of the decoded term, and the validation to reject functions and ports occurs only after the term has been constructed.

A path traversal issue exists where a malicious package publisher can cause the deletion of directories outside the project build directory. This occurs because Gleam reads the `app` field from the hex.pm release API and uses it as the package build directory name without proper validation. If a dependency fails to compile, Gleam uses the `remove dir all` function to delete the directory associated with that name. A publisher could set the `app` field to an absolute path or a relative path containing `..` components to target arbitrary directories. This can be triggered by commands such as `gleam build`, `gleam check`, `gleam run`, `gleam test`, or `gleam export` when a project depends on a malicious release. The issue is specifically linked to the `hex manifest package` function in `compiler-cli/src/dependencies.rs` and the `ProjectPaths::build directory for package` function.

A path traversal issue exists where a malicious package publisher can delete a directory outside the project's `deps` directory and extract package files into it when a developer fetches dependencies. This occurs because Hex uses an `app` label from the repository's signed registry as the dependency's application name without proper validation in the `Hex.RemoteConverger.deps/2` and `Hex.Mix.to lock/1` functions. Mix determines the checkout directory as `deps/<app>`, and the `Hex.SCM.update/1` function executes `File.rm rf!/1` on that directory before unpacking the package. Since hex.pm only validates the label's length, a publisher can use values like `../../target` to target directories outside the intended scope. This process happens during `mix deps.get` or `mix deps.update` before any dependency code is compiled, potentially allowing an attacker to overwrite files in directories the developer's account can write to, which could lead to code execution.

Improper certificate validation in hex core allows an attacker capable of intercepting HTTPS connections to impersonate hex.pm, repo.hex.pm, or other repository and API servers. This occurs when programs use the default HTTP adapter on Erlang/OTP 24, or on OTP 25 when the operating system's CA certificates cannot be loaded. The issue stems from the `hex core:default config/0` function selecting the `hex http httpc` adapter. When `hex http httpc:http options/2` attempts to verify the server certificate using `public key:cacerts get/0`, a failure in that call (which happens by default on OTP 24 or when no CA store is found on OTP 25) causes the adapter to send the request without `ssl` options. Consequently, the `ssl` application uses defaults that do not verify the server certificate on versions prior to OTP 26. Versions of hex core before 0.11.0 are affected on all OTP versions prior to 26 regardless of CA store availability because they never set `ssl` options. An attacker on the network path can complete the TLS handshake with any certificate, allowing them to intercept API keys, OAuth tokens, and repository keys, as well as alter API requests and responses.

Improper certificate validation allows an attacker capable of intercepting HTTPS connections to impersonate a Hex host. This occurs when users configure `cacerts path` (or `HEX CACERTS PATH`) to a specific CA store that excludes certain CAs, yet the software continues to trust the bundled CA store. Specifically, the `Hex.HTTP.SSL.ssl opts/1` function builds a `partial chain` callback using the bundled store regardless of the `cacerts path` setting. Consequently, the `Hex.HTTP.SSL.partial chain/2` function may accept a server chain if any certificate matches a public key in the bundled store, bypassing the user's restricted CA store. An attacker possessing a certificate for the host issued by a bundled CA can intercept API keys, OAuth tokens, and repository keys, and modify API responses. Hostname verification and package checksums remain active.

A memory allocation issue exists in the `Decimal.round/3` function that allows for a Denial of Service. The function builds the full result for the requested number of decimal places before applying context precision, causing memory consumption to grow based on the `places` argument rather than the result size. For positive `places`, the software appends zero digits to the coefficient as a charlist; for negative `places`, it builds a charlist of zero digits. A large value, such as -50,000,000, can allocate approximately 5.5 GB of memory, potentially exhausting available resources and causing the BEAM VM to be killed. In older releases, this issue manifests as high CPU consumption due to looping once per decimal place. Applications are exposed if they pass user-supplied values to `Decimal.round/2` or `Decimal.round/3` without proper bounding.

An inconsistent interpretation of HTTP requests, known as HTTP Request/Response Smuggling, allows a malicious HTTP/1 server to desynchronize an intermediary and the Mint client on a pooled connection. This can lead to response poisoning for subsequent requests sharing the same connection. The issue occurs because the `message body/1` function in `lib/mint/http1.ex` selects chunked framing if `chunked` is the first coding listed in a response's `Transfer-Encoding` field, whereas RFC 9112 requires chunked framing only when `chunked` is the final coding. Additionally, Mint incorrectly keeps connections open after an HTTP/1.0 response that carries `Transfer-Encoding` and `Connection: keep-alive`, which violates RFC 9112 requirements to treat such framing as faulty and close the connection.

A malicious HTTP/2 server can cause a denial of service by exhausting memory on the client host. The issue occurs because `Mint.HTTP2` only enforces the `max header list size` setting on the compressed size of an inbound header block, rather than the decoded header list as required by RFC 9113. An attacker can use HPACK indexed fields to create a small compressed block that expands into a very large decoded list. Specifically, the `join cookie headers/1` function in `lib/mint/http2.ex` copies every `cookie` value of a response into a single new binary, which can lead to the allocation of approximately 1 GB for a single response under default settings. This memory exhaustion can crash the process owning the connection or the entire BEAM virtual machine.

A resource allocation issue allows a malicious HTTP/2 server to force a client to buffer up to approximately 16 MiB per connection in frames that should be rejected, leading to excessive client memory consumption. This occurs because the function `decode next/2` in `lib/mint/http2/frame.ex` only validates the frame against the `max frame size` variable after the entire declared payload has been received. Until the payload is complete, the system returns `:more`, causing `Mint.HTTP2` to store all received bytes in the connection buffer. A server can declare a frame length up to 16,777,215 bytes and withhold the final byte to maintain this buffer for as long as the connection remains open. This can lead to memory exhaustion for clients maintaining numerous connections to untrusted origins, such as proxies, crawlers, or webhook senders.

An insufficient session expiration issue in OAuth token issuance allows users whose organization membership or session has ended to continue reading private packages and documentation tarballs. This occurs because the `generate refresh token/4` function in `lib/hexpm/oauth/jwt.ex` signs refresh tokens with the same `iss`, `aud`, and `scope` claims as access tokens, including the `repository:<org>` scope. The CDN service serving private repositories authorizes access based on the `scope` claim after verifying the signature and time claims, without performing a database lookup. Consequently, the CDN cannot distinguish between access tokens and refresh tokens. While access tokens expire in 30 minutes, refresh tokens remain valid for 30 days, extending unauthorized read-only access to organizations the account belonged to at the time the token was granted.

An inconsistent interpretation of HTTP requests, known as HTTP Request/Response Smuggling, allows a malicious HTTP/1 server to desynchronize a strict intermediary and the Mint client on a pooled connection. This can lead to response-queue poisoning, where bytes from one response are attributed to subsequent requests sharing the same connection. The issue occurs because the `chunk size/1` function in `Mint.HTTP1.Parse` stops at the first non-hexadecimal byte of a chunked response's chunk-size line and returns the remainder unexamined. Subsequently, the `decode body/5` function in `Mint.HTTP1` discards all bytes up to the CRLF using `Parse.ignore until crlf/1`. This results in the acceptance of hex digits followed by arbitrary bytes, whereas RFC 9112 only permits chunk extensions introduced by a `;`. Consequently, an RFC-strict intermediary may reject a line that Mint accepts, causing a disagreement on chunk boundaries and the end of the response body.

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.