CVE-2026-103502 in hex_core
Summary
by MITRE • 10/12/2026
Improper Certificate Validation vulnerability in hexpm hex_core allows an attacker who can intercept HTTPS connections to impersonate hex.pm, repo.hex.pm or any other repository or API server to programs that use hex_core's default HTTP adapter on Erlang/OTP 24, or on OTP 25 when the operating system's CA certificates can't be loaded.
hex_core:default_config/0 selects the built-in hex_http_httpc adapter. For an HTTPS request whose adapter config has no ssl option, hex_http_httpc:http_options/2 builds options that verify the server certificate against public_key:cacerts_get/0. When that call raises, the adapter prints a warning and sends the request without ssl options, so httpc uses the defaults of the ssl application, which before OTP 26 don't verify the server certificate. public_key:cacerts_get/0 doesn't exist on OTP 24, so every HTTPS request falls back there, and on OTP 25 it raises when no CA store is found. hex_core versions before 0.11.0 never set ssl options, so they don't verify the server certificate on OTP 25 and earlier whether or not a CA store is found.
The fallback was intended and documented, but the documentation didn't make clear that it meant no certificate verification. Since hex_core 0.8.2 the README has warned that the built-in httpc adapter "has insecure default settings" and recommended other HTTP clients, and the adapter prints "using default ssl options which are insecure" on every request that falls back. hex_core 0.11.0 added certificate verification with the changelog entry "Use secure SSL defaults for OTP 25+". Neither the README nor the warning says that the server certificate isn't verified, the README doesn't say which OTP versions the warning applies to, and on OTP 25 without CA certificates the warning tells users to upgrade to OTP 25 or later, which they already run. This advisory is published so that users who took those notices as general advice know their HTTPS requests weren't authenticated.
This issue affects hex_core: from 0.1.0 before 0.20.0.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/12/2026
The vulnerability identified in the hexpm hex_core library represents a critical failure in certificate validation that exposes users to man-in-the-middle attacks when interacting with Hex package repositories and API servers. This flaw specifically impacts systems running Erlang/OTP versions 24 or 25, particularly under conditions where the operating system's Certificate Authority (CA) certificates cannot be loaded by the application environment. The core issue stems from the default configuration of hex_core, which selects a built-in HTTP adapter based on the httpc module. When an HTTPS request is initiated without explicit SSL options in its configuration, the library attempts to verify the server certificate against the system's CA store using public_key:cacerts_get/0. However, if this function fails or raises an error due to missing certificates, the adapter does not abort the connection as a secure implementation should. Instead, it prints a warning and proceeds with the request using default SSL options that do not enforce server certificate verification. This behavior effectively strips away TLS authentication, allowing any attacker capable of intercepting network traffic to impersonate hex.pm or other repository endpoints without detection by the client application.
The technical root cause is deeply tied to version-specific behaviors in Erlang/OTP and historical design decisions within hex_core prior to version 0.11.0. On OTP versions earlier than 26, specifically including OTP 24 where public_key:cacerts_get/0 does not exist at all, every HTTPS request falls back to insecure defaults that lack certificate verification. Similarly, on OTP 25, if the CA store is unavailable or cannot be loaded, the same fallback mechanism triggers, resulting in unverified connections. Although hex_core versions before 0.11.0 never set SSL options by default, leading to this vulnerability regardless of whether a CA store exists, subsequent updates attempted to address the issue with limited success. Starting from version 0.8.2, documentation warned that the built-in httpc adapter has insecure defaults and recommended alternative HTTP clients. Additionally, the code began printing warnings indicating the use of insecure default SSL options during requests that fall back. Despite these measures, the communication remained ambiguous; neither the README nor the runtime warning explicitly stated that server certificate verification was disabled, nor did they clarify which OTP versions were affected or why upgrading to a newer OTP version might not resolve the issue if CA certificates are still missing on OTP 25 systems.
The operational impact of this vulnerability is severe for developers and automated build systems relying on Hex.pm for package management. An attacker with network access can perform sophisticated man-in-the-middle attacks, injecting malicious code into downloaded packages or intercepting sensitive data transmitted to the API servers. Because the connection appears successful from a TLS perspective—albeit without authentication—the compromise goes unnoticed by standard security monitoring tools that rely solely on certificate validity rather than verification logic. This undermines the integrity of the software supply chain, as users may unknowingly install compromised dependencies. The vulnerability affects hex_core versions ranging from 0.1.0 up to but not including 0.20.0, meaning a vast majority of existing deployments remain at risk if they have not explicitly configured secure SSL options or migrated to more robust HTTP client libraries that enforce strict certificate validation by default.
Mitigation strategies must address both the immediate configuration gaps and long-term architectural improvements. Users currently running affected versions should immediately configure their applications to use explicit, secure SSL options rather than relying on defaults. This involves passing a custom ssl option list to hex_core configurations that explicitly enables peer verification and specifies trusted CA certificates manually if system loading fails. Alternatively, migrating away from the built-in httpc adapter to third-party HTTP clients such as hackney or ibrowse is strongly recommended, as these libraries often have more rigorous default security postures. For organizations managing large fleets of Erlang/OTP systems, auditing configurations for explicit SSL verification settings and ensuring that CA certificates are correctly installed at the OS level can prevent fallback scenarios. Furthermore, upgrading to OTP 26 or later provides a stronger baseline where public_key:cacerts_get/0 is available and default behaviors may differ, though manual configuration remains essential given the historical context of this flaw.
From a classification perspective, this vulnerability aligns with CWE-295 Improper Certificate Validation, as the application fails to properly validate the certificate presented by the remote server against trusted authorities. It also maps directly to MITRE ATT&CK technique T1078 Valid Accounts and potentially T1499 Endpoint Denial of Service if used for disruption, but most critically it facilitates T1505 Server Software Component which allows attackers to insert malicious components into legitimate software distribution channels. The failure is not merely a coding error but a systemic design flaw where fallback mechanisms prioritize connectivity over security without adequate user notification about the loss of authentication guarantees. Addressing this requires both immediate configuration changes and a broader shift toward explicit security configurations in dependency management tools within the Erlang ecosystem to prevent similar trust issues in future releases.