https://github.com/hexpm/hex/releases/tag/v2.5.2 lists: Bug fixes ---------

Fail with the download error instead of crashing in mix hex.package fetch when the version isn't in the registry but a copy of it is cached hex.docs fetch. They were requested from an organization named after the repository, such as hexpm:myorg, and never found. Packages from other repositories are skipped with a warning and invalid versions in mix hex.docs. A version such as 1.0.0/../../x on the command line or in mix.lock made mix hex.docs fetch write docs outside the docs directory

Security fixes --------------

Trust only the CA certificates in cacertspath (HEXCACERTSPATH) when it's set. Hex also accepted a server certificate chain that led to a CA in its bundled store, so every bundled CA could still authenticate Hex's servers (GHSA-rw8q-hg7m-cxgr, CVE-2026-103503)

Don't trust copies of CA certificates sent by the server. Hex accepted a server-sent certificate with the same public key as a CA in the CA store in place of that CA, so a server could send a copy of an expired CA certificate with a later expiry date (GHSA-rw8q-hg7m-cxgr, CVE-2026-103503)

Verify the registry checksum of the package tarball that mix hex.package fetch PACKAGE VERSION --output - writes to standard output, so a mirror can't substitute the package, and print the command's messages to standard error, so standard output only carries the tarball. Error responses and warnings from the mirror were printed to standard output before the tarball. With --output DIR the tarball is no longer written when its checksum doesn't match (GHSA-98jr-23pm-vj7c, CVE-2026-105280)

Keep applying the release-age cooldown to a package when its locked release is retired. Retiring a release takes the same package owner permission as publishing one, so retiring the locked release let a new release skip the cooldown. A locked release with a security advisory still lifts the cooldown for its package and for the direct dependencies of the locked release. When newer versions of a retired locked release are filtered by the cooldown, mix deps.get and mix deps.update say that the locked release is retired and show the command to update without the cooldown, and mix hex.outdated marks the update with (cooldown) and no longer exits with a non-zero status for it (GHSA-pqhp-5x9x-69h7, CVE-2026-105668)

Only lift the release-age cooldown for a locked package in the repository it's locked from. A locked package also lifted the cooldown for packages with the same name in other repositories, such as an organization repository and hexpm (GHSA-pqhp-5x9x-69h7, CVE-2026-105668)

Stop downloading a registry file, package, docs tarball or other file from a repository or mirror once it's larger than 16 MiB, including after decompressing a gzip-encoded response. A package mirror could make Hex use any amount of memory or disk before the registry signature or package checksum was checked. Responses with a status other than 200 are limited the same way on OTP 27.3.4.17, 28.5.0.6, 29.0.6, 29.1 or later when they have a Content-Length header or chunked encoding, and are otherwise still read in full (GHSA-gf42-pg2f-63jp, CVE-2026-96618)

Stop decompressing a gzip-encoded API response once it's larger than 64 MiB. A small response could make Hex use any amount of memory (GHSA-gf42-pg2f-63jp, CVE-2026-96618)

Check a package against the registry checksum before writing it to the package cache and before unpacking a cached copy, including in offline mode and when fetching the package fails. A cached package that doesn't match the registry is removed instead of being unpacked (GHSA-gf42-pg2f-63jp, CVE-2026-96618)

Apply the 16 MiB compressed and 128 MiB uncompressed size limits for docs to mix hex.docs fetch and mix hex.docs offline (GHSA-gf42-pg2f-63jp, CVE-2026-96618)

Stop decompressing a registry file once its contents are larger than 16 MiB, before its signature is checked, and reject compressed Erlang terms in API responses. A mirror could send a small registry file, and an API server a small response, that decompressed to any size (GHSA-7c4r-cgf9-9jmq, CVE-2026-105274)

Skip package releases that give a dependency an application name other than a letter followed by letters, digits, and -, such as ../name, and warn about them when resolving dependencies. Resolution fails if no other release of the package fits the requirements. Hex used the application name as the dependency's directory, so such a release could make mix deps.get delete and replace a directory outside deps/ (GHSA-2vjj-c5hr-6xc3, CVE-2026-96612)

Escape terminal control characters in text from hex.pm and the registry before printing it, such as package descriptions and links, retirement messages, security advisories, search results and error messages. A package publisher could otherwise send escape sequences that clear the screen, rewrite earlier output or set the clipboard in terminals that support it. A dependency in the registry whose package or repository name isn't a valid name is now rejected (GHSA-fpmj-3cxg-p766, CVE-2026-81856) The listed GHSA ids can be found on: https://github.com/hexpm/hex/security/advisories

-- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris

Insufficient Verification of Data Authenticity vulnerability in hexpm hex (Hex.RemoteConverger module) allows dependency integrity bypass via unverified lockfile checksums.

Hex stores checksums for dependencies in the mix.lock file to ensure reproducible and integrity-checked builds. However, Hex.RemoteConverger.verifyresolved/2 never executes checksum verification because the lock data returned by Hex.Utils.lock/1 uses string-based dependency names, while the verification logic compares against atom-based names. This type mismatch causes the verification code path to be silently skipped. Checksums are still validated when packages are initially downloaded from the registry, but mismatches between the lockfile and resolved dependencies are not detected.

An attacker who can influence cached packages (e.g., via local cache poisoning or a compromised registry) can provide modified dependency contents that will be accepted without detection. The mix.lock file is silently rewritten with the checksum values from the registry, erasing evidence of tampering.

This issue affects hex: from 0.16.0 before 2.4.2.

Impact

The Hex client (hexcore) deserializes Erlang terms received from the Hex API using binarytoterm/1 without sufficient restrictions.

If an attacker can control the HTTP response body returned by the Hex API, this allows denial-of-service attacks such as atom table exhaustion, leading to a VM crash. No released versions are known to allow remote code execution.

Patches

https://github.com/hexpm/hexcore/commit/cdf726095bca85ad2549d146df1e831ae93c2b13 https://github.com/hexpm/hex/commit/636739f3322514e9303ca335fb630696fcbb3c95 https://github.com/erlang/rebar3/commit/1d4478f527e373de0b225951e53115450e0d9b9d

Workarounds

Ensure that the Hex API URL (HEXAPIURL) points only to trusted endpoints. There is no client-side workaround that fully mitigates this issue without applying the patch.

Resources

hexcore Module: https://github.com/hexpm/hexcore/blob/main/src/hexapi.erl Hex Vendored Module: https://github.com/hexpm/hex/blob/main/src/mixhexapi.erl Rebar3 Vendored Module: https://github.com/erlang/rebar3/blob/main/apps/rebar/src/vendored/r3hexapi.erl hexcore Patch: https://github.com/hexpm/hexcore/commit/cdf726095bca85ad2549d146df1e831ae93c2b13 Hex Vendored Patch: https://github.com/hexpm/hex/commit/636739f3322514e9303ca335fb630696fcbb3c95 Rebar3 Vendored Patch: https://github.com/erlang/rebar3/commit/1d4478f527e373de0b225951e53115450e0d9b9d