hex_core EUVD-2026-97450

Exploitation requires an attacker who can intercept the victim's HTTPS traffic (on-path/MITM position) AND a target using hex_core's built-in hex_http_httpc adapter via hex_core:default_config/0 with no ssl option set. The vulnerable configurations are: hex_core 0.1.0 through before 0.11.0 on OTP 25 and earlier (ssl options never set); OR hex_core 0.11.0-before 0.20.0 running on Erlang/OTP 24 (public_key:cacerts_get/0 does not exist, so every request falls back to insecure defaults); OR on OTP 25 when the operating system's CA certificate store cannot be loaded (cacerts_get/0 raises and the adapter sends the request without ssl options). Key limiting factors: the attacker must already hold a privileged network position, a Hex fetch must be actively triggered, and OTP 26+ verifies certificates by default even without the fix, which substantially narrows the exposed population.

This is a genuine but conditional MITM vulnerability (CWE-295) rather than a remotely-triggerable code-exec issue, and the signals are internally consistent at a Medium level. The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:A, score 5.9) correctly encodes the two real gates: AT:P reflects the passive precondition that the attacker must already be positioned to intercept the victim's HTTPS traffic, and UI:A reflects that a user/CI job must actively trigger a Hex fetch. VC:H/VI:L is appropriate because a successful impersonation lets an attacker feed forged package metadata/tarballs (confidentiality of the channel is fully broken; integrity impact is bounded because tarball checksums/registry signatures still provide some protection). No EPSS score was provided in the input, so probabilistic exploitation likelihood cannot be quantified. The product is NOT on CISA KEV and no public exploit code is referenced, so exploitation status is 'no public exploit identified at time of analysis.' Net judgment: this is a real but lower-urgency hygiene fix for most defenders - it requires an on-path/MITM attacker AND a vulnerable OTP configuration (OTP 24, OTP 25 without loadable CA certs, or any hex_core < 0.11.0 on OTP 25 and earlier) AND use of the default httpc adapter - so it is not a drive-by internet-wide threat, but it is high-value for supply-chain attackers targeting Elixir/Erlang build pipelines over untrusted networks.

An attacker on a shared or compromised network path (e.g. hostile Wi-Fi, a malicious proxy, or a compromised CI egress) intercepts a developer's or CI job's HTTPS request to repo.hex.pm made through hex_core's default httpc adapter on a vulnerable OTP configuration. Because the server certificate is not verified, the attacker presents a forged certificate, impersonates hex.pm, and returns malicious registry metadata or a tampered package tarball. No public exploit code is identified, but the technique is standard TLS interception and requires no authentication to the victim.