Hex audit reports deserialization RCE risk and CI/CD weaknesses

TL;DR — A third-party security audit of the Hex.pm ecosystem found exploitable issues (including unsafe deserialization that could lead to RCE under certain conditions) and reports most findings were remediated; teams running Hex infrastructure should review scope and apply vendor fixes.

What happened

Hex is the package manager/registry infrastructure for the BEAM ecosystem (Erlang, Elixir, and Gleam) and is widely used to distribute dependencies and documentation.

On April 12, 2026 (UTC), an oss-security mailing list post summarized a recently completed third-party security audit and penetration testing effort for Hex and its surrounding ecosystem, citing findings that ranged from high-severity vulnerabilities to low-severity hardening gaps. The post highlights realistic supply-chain attack scenarios the auditors focused on (e.g., cross-account package tampering, integrity-check bypass, injection in public-facing features, and CI/CD compromise).

The post also states that most findings were remediated during the engagement and confirmed in re-tests, and it calls out a set of CVEs tied to fixes, including unsafe deserialization (CVE-2026-21619), OAuth/device-flow XSS (CVE-2026-21618), API key privilege escalation (CVE-2026-21621), password reset token issues (CVE-2026-21622), and package-upload DoS (CVE-2026-23940).

From an AppSec perspective, this is “ecosystem infrastructure” risk: compromises or logic flaws in package registries, auth flows, or build pipelines routinely become blast-radius multipliers across thousands of downstream services.

Who is impacted

• Organizations that operate Hex-related infrastructure (self-hosted registries, internal mirrors, or HexDocs-like documentation hosting) and may not automatically benefit from fixes deployed on hex.pm.
• Teams using BEAM tooling that vendors or embeds Hex API interactions, especially where network paths to the Hex API could be influenced.

The oss-security post calls out that multiple CVEs appear to be server-side concerns, but it also highlights one client-side issue (unsafe deserialization in hex_core) with affected/patched ranges quoted from the referenced GitHub advisory:

Note: the quoted ranges include endpoints that match the quoted patched version in some cases; treat this as a source-quoted detail and validate against the vendor advisory text for your specific build artifacts.

What to do now

• Follow vendor remediation guidance for the referenced advisories and apply the latest patched releases available at the time of writing (especially if you run any Hex ecosystem components outside hex.pm).
• Inventory where Hex ecosystem components exist in your environment (CI runners, build images, developer toolchains, and any self-hosted registry/documentation services) and confirm exact deployed versions.
• If you rely on the Hex client side, review the unsafe-deserialization advisory guidance; the oss-security post quotes the following workaround direction:

  "Ensure that the Hex API URL (HEX_API_URL) points only to trusted endpoints."

• As a supply-chain hygiene step aligned with the audit themes, review your CI/CD posture for the BEAM toolchain (credential exposure paths, GitHub Actions hardening, and dependency update controls), since the audit explicitly considered CI/CD compromise as a realistic attack scenario.