Most severe vulnerabilities for "hexpm/hex"

hexpm/hexLockfile checksums not verified in Hex allows dependency integrity bypass

Risk 78

Severity

8.9

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

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.

1 / 2

Source: MITRE

First published (updated )

CVE-2026-32148

hexpm/hexPath traversal in Hex via unvalidated dependency app names

Risk 77

Severity

7.5

Path Traversal

AV:N/AC:L/AT:P/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in hexpm hex allows a malicious package publisher to delete a directory outside the project's deps directory and extract package files into it when a developer fetches dependencies.

A package release's requirements carry an app label that names the dependency's OTP application. Hex takes this label from the repository's signed registry and uses it as the dependency's application name without validating it (Hex.RemoteConverger.deps/2, Hex.Mix.tolock/1). Mix derives the dependency's checkout directory as deps/<app>, and Hex.SCM.update/1 runs File.rmrf!/1 on that directory and unpacks the package into it. hex.pm only checks the label's length, so a publisher can set it to a value such as ../../target. When a project depends on such a release directly or transitively, mix deps.get or mix deps.update deletes the directory the label resolves to and writes the labelled package's files there. This happens before any dependency code is compiled.

This issue affects hex: from 0.6.0 before 2.5.2.

1 / 2

Source: MITRE

First published (updated )

CVE-2026-96612

hexpm/hexHex release-age cooldown is lifted package-wide when the locked release is retired

Risk 67

Severity

7.1

AV:N/AC:L/AT:P/PR:H/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Protection Mechanism Failure vulnerability in hexpm hex allows the owner of a package, or an attacker who has taken over the owner's account, to get a newly published release past the release-age cooldown. The cooldown (cooldown config, HEXCOOLDOWN) withholds versions younger than the configured age during dependency resolution. When the release of a package locked in mix.lock is retired or has a security advisory, Hex.RemoteConverger.buildcooldownbypass/3 and Hex.RemoteConverger.unsafelockbypass/1 lift the cooldown for every version of that package and of every package the locked release depends on, so that mix deps.update can move off the unsafe release. Retiring a release needs the same package owner permission as publishing one. An attacker who publishes a malicious release can retire the currently locked release, and the next mix deps.update that unlocks the package selects the new release regardless of its age. Hex.Registry.Cooldown.versions/2 checks the bypass by package name alone, so the bypass also covers packages with the same name in other repositories. Cooldown configured through an organization dependency policy is not affected. This issue affects hex: from 2.5.0 before 2.5.2.

1 / 5

Source: Ubuntu

First published (updated )

CVE-2026-105668

Erlang OTPerl_tar:extract/2 loops forever on a GNU sparse member with a trailing hole

Risk 33

Severity

5.9

AV:L/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in Erlang OTP stdlib (erltar module), hexpm hexcore (hexerltar module), hexpm hex (mixhexerltar module) and erlang rebar3 (r3hexerltar module) allows an attacker who supplies a tar archive to cause a denial of service via a crafted GNU sparse member.

When erltar:extract/1,2 writes a member to disk, erltar:streamtofileloop/3 reads it in chunks of 65536 bytes by default. For a GNU sparse member whose sparse map ends before its real size, erltar:dosparseread/3 matches its trailing-hole clause before its zero-length clause. After the chunk is used up, the trailing-hole clause reads zero bytes, does not advance the position, and recurses forever. A 2048-byte archive keeps the extracting process and one scheduler busy until the process is killed. The {maxsize, N} option prevents this only when N is below the real size of the member. Extraction with the memory option is not affected.

hexcore ships its own copy of erltar as hexerltar, and Hex and rebar3 ship hexcore with prefixed module names (mixhexerltar and r3hexerltar). These copies contain the same code and do not call stdlib's erltar, so they are affected on any OTP version. OTP 28 is not affected, but an application running on OTP 28 is affected if it extracts archives through an affected version of hexcore, Hex or rebar3.

This issue affects OTP from OTP 29.0 before OTP 29.1.2, corresponding to rebar3 from 3.27.1 before 3.28.0, and stdlib from 8.0 before 8.1.1, and hex from 2.4.2 before 2.5.3; hexcore: from 0.14.0 before 0.20.1.

1 / 4

Source: MITRE

First published (updated )

CVE-2026-96596

hexpm/hex_coreUnsafe Deserialization of Erlang Terms in hex_core

Risk 46

Severity

2

CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:A/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

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

1 / 2

Source: GitHub

First published (updated )

CVE-2026-21619

oss-secSecurity Audit of Hex, the Erlang package manager

https://hex.pm/blog/security-audit announces the completion of a security audit & penetration testing of Hex, the Erlang package manager, funded by the OpenSSF and overseen by the Erlang Ecosystem Foundation.

This work was done by two independent security firms, Paraxial.io and zentrust partners GmbH, who each produced their own reports: - https://hex.pm/reports/2026/paraxial.pdf - https://hex.pm/reports/2026/zentrust.pdf

The announcement reports: What was found --------------

Across both audits, a number of issues were identified, ranging from high severity vulnerabilities to low-severity hardening gaps.

Examples include:

Unsafe deserialization in hexcore that could lead to RCE under certain conditions A denial of service condition during package uploads Weaknesses in authentication flows and API key handling Gaps in CI/CD hardening (GitHub Actions) Missing or incomplete security controls in some areas

Importantly, the audits focused on realistic attack scenarios such as:

cross-account package tampering bypassing integrity checks injection in public-facing features CI/CD compromise

What we fixed -------------

Most findings have been remediated during the engagement and confirmed in re-tests.

Highlights:

Fixed unsafe deserialization in hexcore (CVE-2026-21619) Fixed API key privilege escalation (CVE-2026-21621) Fixed password reset issues (CVE-2026-21622) Fixed XSS in OAuth device flow (CVE-2026-21618) Fixed denial of service in package upload (CVE-2026-23940) Removed sensitive credentials from repositories Hardened authentication flows (including "sudo mode" for sensitive actions) Disabled legacy TLS versions Improved CSP and other browser security controls

Re-tests by both firms confirmed that the majority of vulnerabilities were successfully remediated.

Several remaining items are either:

accepted risks with clear rationale (for example UX trade-offs or staged migrations), or dependent on ecosystem-wide changes (for example client updates)

What we decided not to change (yet) -----------------------------------

Some findings reflect intentional trade-offs or transitional states rather than vulnerabilities.

Examples:

Basic authentication and optional 2FA are still supported for compatibility with existing clients. Both will be phased out once all clients support the OAuth2 device flow. Certain features (like documentation hosting) intentionally allow user-provided content and are being isolated rather than restricted.

These decisions were reviewed jointly by the Hex.pm team and the EEF. These issues appear to be reported against the hexpm server side, not the client side that end users & distros are likely to be running:

- Cross-site scripting (XSS) in OAuth Device Authorization screen (CVE-2026-21618) https://github.com/hexpm/hexpm/security/advisories/GHSA-6cw9-5gg4-rhpj

- Improper Scope Enforcement in OAuth clientcredentials Flow Allows Read-Only API Key to Escalate to Full Access with Valid 2FA Code (CVE-2026-21621) https://github.com/hexpm/hexpm/security/advisories/GHSA-739m-8727-j6w3

- Password Reset Tokens Do Not Expire (CVE-2026-21622) https://github.com/hexpm/hexpm/security/advisories/GHSA-6r94-pvwf-mxqm

- Path Traversal in Local File Store Backend (Development and Self-Hosted Registry Setups) (CVE-2026-23939) https://github.com/hexpm/hexpm/security/advisories/GHSA-42mv-r64p-4869

- Publishing Oversized Package Can Trigger Denial of Service (CVE-2026-23940) https://github.com/hexpm/hexpm/security/advisories/GHSA-jp8w-gxf6-8hcr

That leaves one CVE for distros and end users to worry about - https://github.com/hexpm/hexcore/security/advisories/GHSA-hx9w-f2w9-9g96 reports: Unsafe Deserialization of Erlang Terms in hexcore --------------------------------------------------

maennchen published GHSA-hx9w-f2w9-9g96 Feb 27, 2026

Package: hex (otp) Affected versions: >= 2.3.0 and <= 2.3.2 Patched versions: 2.3.2

Package: hexcore (Erlang) Affected versions: <= 0.12.1 Patched versions: 0.12.1

Package: rebar3 (otp) Affected versions: >= 3.9.1 and <= 3.27.0 Patched versions: 3.27.0

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.

References ---------- - 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: cdf7260 - Hex Vendored Patch: hexpm/hex@636739f - Rebar3 Vendored Patch: erlang/rebar3@1d4478f

Severity: Low - 2.0 / 10 CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:A/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N CVE ID: CVE-2026-21619 Weaknesses: - CWE-400: Uncontrolled Resource Consumption - CWE-502: Deserialization of Untrusted Data

First published (updated )

https://seclists.org/oss-sec/2026/q2/109

oss-secSecurity Audit of Hex, the Erlang package manager

Hello Alan,

How am I, as a user, supposed to authenticate these PDFs as materials really produced by the parties Hex claims they are from? The PDFs are offered for download from the audited-party domain, not from the auditors' domains, and do not contain any digital signatures.

On Mon, Apr 13, 2026 at 4:16 AM Alan Coopersmith < alan.coopersmith () oracle com> wrote: https://hex.pm/blog/security-audit announces the completion of a security audit & penetration testing of Hex, the Erlang package manager, funded by the OpenSSF and overseen by the Erlang Ecosystem Foundation.