Eric Meadows-Jönsson

**اسم البرنامج المصاب والإصدارات المتأثرة** Erlang OTP الإصدارات من 29.0 إلى 29.1.1 stdlib الإصدارات من 8.0 إلى 8.1.0 hex الإصدارات من 2.4.2 إلى 2.5.2 hex core الإصدارات من 0.14.0 إلى 0.20.0 rebar3 الإصدارات 3.27.1 وما بعدها **Description** توجد مشكلة حلقة مفرغة (Infinite Loop) في وحدة `erl tar` (وبدائلها `hex erl tar` و `mix hex erl tar` و `r3 hex erl tar`) عند استخراج أرشيفات tar. يمكن للمهاجم التسبب في حالة حجب الخدمة عن طريق تقديم عضو GNU sparse مصمم خصيصاً حيث تنتهي خريطة التباعد قبل الحجم الفعلي للعضو. أثناء الاستخراج، تستخدم الدالة `erl tar:extract/1,2` الدالة `erl tar:stream to file loop/3` لقراءة البيانات في كتل. في الإصدارات المتأثرة، تطابق الدالة `erl tar:do sparse read/3` بند trailing-hole قبل بند الطول الصفري، مما يؤدي إلى تكرار غير محدود يستهلك المجدول (scheduler) ويجعل العملية مشغولة إلى أجل غير مسمى. يمكن تفعيل ذلك باستخدام أرشيف بحجم 2048 بايت فقط. يمنع خيار `{max size, N}` ذلك فقط عندما تكون قيمة N أقل من الحجم الفعلي للعضو. أما الاستخراج باستخدام خيار `memory` فلا يتأثر بهذه المشكلة. **Recommendations** تحديث Erlang OTP إلى الإصدار 29.1.2 أو أحدث. تحديث stdlib إلى الإصدار 8.1.1 أو أحدث. تحديث hex إلى الإصدار 2.5.3 أو أحدث. تحديث hex core إلى الإصدار 0.20.1 أو أحدث. تحديث rebar3 إلى إصدار يتضمن الإصلاح. كإجراء مؤقت، قم بتمرير `{chunks, N}` و `{max size, N}` بنفس القيمة N إلى `erl tar:extract/2` لضمان رفض أي عضو أكبر من N وقراءة الأعضاء المتبقية في استدعاء واحد. بدلاً من ذلك، استخدم خيار `memory` للاستخراج ثم قم بكتابة الملفات الناتجة إلى القرص يدوياً.

**Name of the Vulnerable Software and Affected Versions** hex core versions 0.1.0 through 0.19.9 **Description** 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. **Recommendations** Upgrade hex core to version 0.20.0 or later. As a temporary workaround, pass `ssl` options that verify the server certificate in the adapter config, such as `{hex http httpc, #{http options => [{ssl, SslOpts}]}}`. As a temporary workaround, use an alternative HTTP adapter instead of the default `hex http httpc` adapter. As a temporary workaround, run the application on OTP 26 or later.

**Name of the Vulnerable Software and Affected Versions** hexpm hex versions 0.20.2 through 2.5.1 **Description** 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. **Recommendations** Upgrade hexpm hex to version 2.5.2 or later.

**Name of the Vulnerable Software and Affected Versions** erlang rebar3 versions 3.7.0-rc1 through 3.27.1 **Description** 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. **Recommendations** Upgrade rebar3 to version 3.27.2 or later.

**Name of the Vulnerable Software and Affected Versions** hexpm hex versions 0.20.2 through 2.5.1 **Description** 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. **Recommendations** Update hexpm hex to version 2.5.2 or later. As a temporary workaround, write the tarball to a file using `--output FILE` instead of standard output to ensure checksums are verified.

**Name of the Vulnerable Software and Affected Versions** hexpm hex versions 2.5.0 through 2.5.1 **Description** 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. **Recommendations** Update hexpm hex to version 2.5.2 or later using `mix local.hex`. Enforce the cooldown through an organization dependency policy instead of the local `cooldown` setting. Run `mix hex.audit` before `mix deps.update` and avoid updating packages whose locked release was retired until the replacement has been reviewed.

**Name of the Vulnerable Software and Affected Versions** hex versions 0.6.0 through 2.5.1 **Description** 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. **Recommendations** Upgrade hex to version 2.5.2 or later using `mix local.hex`. As a temporary mitigation, before running `mix deps.get` on a `mix.lock` from an untrusted source, verify that every key in `mix.lock` is a plain application name and does not contain `/`, ``, or `..` characters.

**Name of the Vulnerable Software and Affected Versions** hexpm hex versions 0.11.2 through 2.5.1 **Description** 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. **Recommendations** Upgrade hexpm hex to version 2.5.2 or later using `mix local.hex`. As a temporary workaround, fetch packages only from repo.hex.pm or a mirror you operate. Run Mix under operating system memory and disk limits, such as container limits, to confine the impact.

**Name of the Vulnerable Software and Affected Versions** rebar3 versions 3.9.1 through 3.27.2 hex versions 2.1.0 through 2.5.1 hex core versions 0.1.0 through 0.19.9 **Description** 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. **Recommendations** Update rebar3 to version 3.27.3 or later. Update hex to version 2.5.2 or later. Update hex core to version 0.20.0 or later.

**Name of the Vulnerable Software and Affected Versions** gleam versions 0.32.4 through 1.19.1 **Description** 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. **Recommendations** Upgrade gleam to version 1.19.2 or later.

**Name of the Vulnerable Software and Affected Versions** hexpm hex versions 0.0.1 through 2.5.1 **Description** 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. **Recommendations** Update hexpm hex to version 2.5.2 or later using `mix local.hex`.

**Name of the Vulnerable Software and Affected Versions** decimal versions 0.1.0 through 3.1.1 **Description** 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. **Recommendations** Update decimal to version 3.1.2 or later. As a temporary workaround, bound the `places` argument before calling `Decimal.round/2` or `Decimal.round/3`, for example, restricting it to a range such as `-34..34` or to the specific scales supported by the application.

**Name of the Vulnerable Software and Affected Versions** elixir-mint versions 0.1.0 through 1.10.x **Description** 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. **Recommendations** Update elixir-mint to version 1.11.0 or later.

**Name of the Vulnerable Software and Affected Versions** mint versions 1.1.0 through 1.10.x **Description** 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. **Recommendations** Update to version 1.11.0 or later. As a temporary mitigation, lower the `max header list size` value within `client settings` in the `Mint.HTTP.connect/4` function to a small value (e.g., 4,096) to bound the response size. Restrict connections to untrusted servers to HTTP/1 by setting `protocols: [:http1]` to avoid the HTTP/2 receive path. Avoid setting `max header list size` to `:infinity`.

**Name of the Vulnerable Software and Affected Versions** elixir-mint versions 0.1.0 through 1.10.x **Description** 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. **Recommendations** Update elixir-mint to version 1.11.0 or later. As a temporary workaround, connect to untrusted origins using HTTP/1 only by setting `protocols: [:http1]` in the `Mint.HTTP.connect/4` function to avoid the HTTP/2 frame decoder.

**Name of the Vulnerable Software and Affected Versions** hex.pm versions 2025-10-10 through 2026-09-21 **Description** 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. **Recommendations** Update hex.pm to a version released on or after 2026-09-22.

**Name of the Vulnerable Software and Affected Versions** mint versions 0.1.0 through 1.10.0 **Description** 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. **Recommendations** Update mint to version 1.10.1 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 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** 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.