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.

Uncontrolled Resource Consumption vulnerability in hexpm hexpm/hexpm allows Excessive Allocation.

Publishing an oversized package can cause Hex.pm to run out of memory while extracting the uploaded package tarball. This can terminate the affected application instance and result in a denial of service for package publishing and potentially other package-processing functionality.

This issue affects hex.pm: before 2026-03-10.

Insufficient Session Expiration vulnerability in hexpm hexpm/hexpm ('Elixir.Hexpm.Accounts.PasswordReset' module) allows Account Takeover.

Password reset tokens generated via the "Reset your password" flow do not expire. When a user requests a password reset, Hex sends an email containing a reset link with a token. This token remains valid indefinitely until used. There is no time-based expiration enforced.

If a user's historical emails are exposed through a data breach (e.g., a leaked mailbox archive), any unused password reset email contained in that dataset could be used by an attacker to reset the victim's password. The attacker does not need current access to the victim's email account, only access to a previously leaked copy of the reset email.

This vulnerability is associated with program files lib/hexpm/accounts/passwordreset.ex and program routines 'Elixir.Hexpm.Accounts.PasswordReset':canreset?/3.

This issue affects hexpm: from 617e44c71f1dd9043870205f371d375c5c4d886d before bb0e42091995945deef10556f58d046a52eb7884.

Incorrect Authorization vulnerability in hexpm hexpm/hexpm ('Elixir.HexpmWeb.API.OAuthController' module) allows Privilege Escalation.

An API key created with read-only permissions (domain: "api", resource: "read") can be escalated to full write access under specific conditions.

When exchanging a read-only API key via the OAuth clientcredentials grant, the resource qualifier is ignored. The resulting JWT receives the broad "api" scope instead of the expected "api:read" scope. This token is therefore treated as having full API access.

If an attacker is able to obtain a victim's read-only API key and a valid 2FA (TOTP) code for the victim account, they can use the incorrectly scoped JWT to create a new full-access API key with unrestricted API permissions that does not expire by default and can perform write operations such as publishing, retiring, or modifying packages.

This vulnerability is associated with program files lib/hexpmweb/controllers/api/oauthcontroller.ex and program routines 'Elixir.HexpmWeb.API.OAuthController':validatescopesagainstkey/2.

This issue affects hexpm: from 71829cb6f6559bcceb1ef4e43a2fb8cdd3af654b before 71c127afebb7ed7cc637eb231b98feb802d62999.

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

Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in hexpm hexpm/hexpm ('Elixir.Hexpm.Store.Local' module) allows Relative Path Traversal. This vulnerability is associated with program files lib/hexpm/store/local.ex and program routines 'Elixir.Hexpm.Store.Local':get/3, 'Elixir.Hexpm.Store.Local':put/4, 'Elixir.Hexpm.Store.Local':delete/2, 'Elixir.Hexpm.Store.Local':deletemany/2.

This issue does NOT affect hex.pm the service. Only self-hosted deployments using the Local Storage backend are affected.

This issue affects hexpm: from 931ee0ed46fa89218e0400a4f6e6d15f96406050 before 5d2ccd2f14f45a63225a73fb5b1c937baf36fdc0.

Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in hexpm hexpm/hexpm ('Elixir.HexpmWeb.SharedAuthorizationView' modules) allows Cross-Site Scripting (XSS). This vulnerability is associated with program files lib/hexpmweb/views/sharedauthorizationview.ex and program routines 'Elixir.HexpmWeb.SharedAuthorizationView':rendergroupedscopes/3.

This issue affects hexpm: from 617e44c71f1dd9043870205f371d375c5c4d886d before c692438684ead90c3bcbfb9ccf4e63c768c668a8; hex.pm: from 2025-10-01 before 2026-01-19.

Hex package manager version 0.14.0 through 0.18.2 contains a Signing oracle vulnerability in Package registry verification that can result in Package modifications not detected, allowing code execution. This attack appears to be exploitable via victim fetches packages from malicious/compromised mirror. This vulnerability appears to have been fixed in 0.19.

Hex package manager hexcore version 0.3.0 and earlier contains a Signing oracle vulnerability in Package registry verification that can result in Package modifications not detected, allowing code execution. This attack appears to be exploitable via victim fetches packages from malicious/compromised mirror. This vulnerability appears to have been fixed in 0.4.0.