The vulnerability arises because hex_core’s default HTTP adapter does not verify TLS certificates when running on OTP 24 or OTP 25 if the operating system’s CA store cannot be accessed. In these cases, the adapter falls back to the Erlang ssl defaults, which prior to OTP 26 do not enforce certificate validation. An attacker who can observe or modify HTTPS traffic can therefore pose as the hex.pm registry, any user‑supplied repository, or arbitrary API servers and supply malicious packages or data. This impersonation can result in the execution of code that originates from a trusted source but has been tampered with, compromising confidentiality, integrity, and availability of the affected systems.

The issue affects hexpm’s hex_core library in all releases from 0.1.0 up to, but not including, 0.20.0. Users running OTP 24 or OTP 25 with a missing or inaccessible OS CA certificate store are especially vulnerable, as hex_core never sets ssl verification options for HTTPS requests in these environments. Systems that use the default hex_http_httpc adapter without explicitly configuring ssl options inherit the insecure behavior of older OTP releases.

The CVSS score of 5.9 indicates medium severity, and the vulnerability is not listed in the CISA KEV catalog. The EPSS score is not available, so the historical exploitation probability is unknown. The most likely attack vector is a network or local MITM that can intercept traffic to the registry or API endpoint; an attacker only needs to present an forged certificate that will be accepted by the vulnerable client. In environments where hex_core is used without additional verification, an exploitation can lead to tampered packages being installed or malicious data being communicated to an application.