CVE-2026-21619: 
NixOS vulnerability analysis and mitigation

CVE-2026-21619 is an unsafe deserialization of Erlang terms vulnerability affecting the Hex package manager ecosystem, specifically hexpm/hex_core, hexpm/hex, and erlang/rebar3. The flaw exists in the request/4 routines (hex_core:request/4, mix_hex_api:request/4, r3_hex_api:request/4) within the files src/hex_api.erl, src/mix_hex_api.erl, and apps/rebar/src/vendored/r3_hex_api.erl. Affected versions are hex_core 0.1.0 through <0.12.1, hex 2.3.0 through <2.3.2, and rebar3 3.9.1 through <3.27.0. It was published on February 27, 2026, with a CVSS v3.1 score of 7.5 (High) and a CVSS v4.0 score of 2.0 (Low) (Github Advisory, GHSA Advisory).

The root cause is the use of Erlang's binary_to_term/1 without the safe option or term validation when deserializing HTTP response bodies from the Hex API (CWE-502: Deserialization of Untrusted Data; CWE-400: Uncontrolled Resource Consumption). When the Hex API returns a response with an Erlang binary content type, the client blindly deserializes the body, allowing a malicious or compromised API endpoint to inject crafted Erlang terms. This enables atom table exhaustion — since Erlang atoms are never garbage collected, flooding the VM with new atoms causes memory exhaustion and a VM crash (denial of service). The fix introduced a safe_binary_to_term wrapper that uses binary_to_term(Binary, [safe]) to prevent new atom creation and validates deserialized terms to reject executable types such as functions and ports (GHSA Advisory, hex_core patch).

Successful exploitation results in a denial-of-service condition through Erlang VM crash caused by atom table exhaustion or excessive memory allocation. There is no known impact to confidentiality or integrity — no released versions are known to allow remote code execution. The vulnerability affects the availability of package management operations for developers and CI/CD pipelines using hex_core, the Elixir hex mix task, or rebar3 for Erlang dependency management (Github Advisory, GHSA Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at this time (Github Advisory). Exploitation requires the attacker to control or intercept the HTTP response from the Hex API endpoint (e.g., via a man-in-the-middle attack, a rogue mirror, or a misconfigured HEX_API_URL), and also requires a developer or automated process to trigger a package operation. The EPSS score is approximately 0.068% (21st percentile), indicating low near-term exploitation probability. The vulnerability is not listed in the CISA KEV catalog. Detection plugins are available via Qualys (ID 288225) and Nessus (ID 302196) (Github Advisory).

1. Position for interception: Gain the ability to control or spoof HTTP responses from the Hex API — for example, by setting up a rogue Hex mirror, performing a DNS/BGP hijack, or exploiting a misconfigured HEX_API_URL environment variable pointing to an attacker-controlled server.
2. Trigger a package operation: Wait for or induce a developer or CI/CD pipeline to run a package management command (e.g., mix deps.get, rebar3 get-deps) that causes the vulnerable client to make an HTTP request to the Hex API.
3. Craft a malicious response: Serve an HTTP response with the Erlang binary content type (application/vnd.hex+erlang) and a body containing a crafted Erlang binary term — for example, a large number of unique atoms encoded via term_to_binary/1 — designed to exhaust the Erlang atom table.
4. Trigger deserialization: The vulnerable request/4 function calls binary_to_term/1 on the response body without restrictions, deserializing the malicious term and flooding the atom table.
5. Achieve denial of service: The Erlang VM crashes due to atom table exhaustion, disrupting the package manager and any dependent build or deployment processes (GHSA Advisory, hex_core patch).

• Network: Unexpected HTTP responses with Content-Type: application/vnd.hex+erlang from non-official or misconfigured Hex API endpoints; DNS queries or connections to unknown hosts when HEX_API_URL is set to a non-default value.
• Logs: Erlang VM crash reports or erl_crash.dump files generated during or after package manager operations; error messages referencing binary_to_term or atom table limits in build/CI logs.
• Process: Sudden termination of mix, rebar3, or related Erlang/Elixir build processes during dependency resolution; abnormally high memory consumption by the Erlang VM process during package operations.
• Configuration: HEX_API_URL environment variable set to a non-standard or unexpected endpoint in build environments.

Update all affected packages to their patched versions: hex_core to 0.12.1 or later, hex (mix task) to 2.3.2 or later, and rebar3 to 3.27.0 or later (Github Advisory). As a workaround prior to patching, ensure the HEX_API_URL environment variable points only to the official, trusted Hex API endpoint; the advisory notes there is no client-side workaround that fully mitigates the issue without applying the patch. Additionally, restrict network access from build environments to only trusted package repository sources to reduce exposure to malicious API responses (GHSA Advisory).

The vulnerability was discovered by researcher realcorvus and remediated by maennchen (hex_core maintainer). The Hex.pm team published a security audit blog post referencing the issue (Hex Security Audit). The issue was also discussed on the oss-security mailing list and received coverage from Linux security advisories for Fedora and CentOS packages. Community reaction has been measured given the low CVSS v4 score and limited exploitation potential, with the primary concern being supply-chain risk in CI/CD environments.