CVE-2026-103503 in Hex
Summary
by MITRE • 10/12/2026
Improper Certificate Validation vulnerability in hexpm hex allows an attacker who can intercept HTTPS connections, and holds a certificate for a Hex host issued by a CA in Hex's bundled CA store, to impersonate that host to users who set cacerts_path to a CA store that leaves that CA out.
cacerts_path (HEX_CACERTS_PATH) is documented as the path to the CA certificate store, used instead of the CA bundle that ships with Hex. Hex.HTTP.SSL.ssl_opts/1 passes the configured store as the cacerts option, but builds the partial_chain callback from the bundled store whether cacerts_path is set or not. Hex.HTTP.SSL.partial_chain/2 accepts a server chain when any certificate in it has the same public key as a bundled CA certificate, so a chain that leads to a bundled CA passes verification although the configured store doesn't contain that CA. Hostname verification still applies.
This issue affects hex: from 0.20.2 before 2.5.2.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/12/2026
The vulnerability identified in hexpm Hex represents a critical flaw in certificate validation logic, specifically categorized under CWE-295 Improper Certificate Validation. This security defect arises from an inconsistency between the configured CA store and the internal partial chain verification mechanism used by the software during HTTPS connections. The core issue lies within the implementation of the ssl_opts function, which is responsible for configuring SSL/TLS options. While this function correctly passes the user-specified certificate authority path via the cacerts option when the HEX_CACERTS_PATH environment variable or configuration setting is defined, it fails to update the partial_chain callback accordingly. Instead, the system continues to rely on the bundled CA store that ships with Hex for validating intermediate certificates and chain completeness.
This architectural inconsistency creates a specific attack vector where an adversary capable of intercepting HTTPS traffic can exploit this discrepancy if they possess a valid certificate issued by a Certificate Authority present in Hex's default bundled store but absent from the user-configured custom CA store. When such an attacker presents a server certificate signed by one of these excluded CAs, the partial_chain callback will accept it because it matches a public key found in the bundled bundle. Consequently, the TLS handshake proceeds successfully despite the fact that the explicitly configured trust anchor does not recognize this authority. This effectively bypasses the intended security boundary established by the user's choice to use a custom CA store, allowing for potential man-in-the-middle attacks where the attacker can decrypt and inspect encrypted traffic without triggering certificate validation errors in standard scenarios.
The operational impact of this vulnerability is significant for organizations that rely on Hex.HTTP.SSL.ssl_opts/1 to enforce strict PKI policies using non-default or private Certificate Authorities. By setting cacerts_path, administrators typically intend to restrict trust exclusively to specific internal or custom CAs, thereby rejecting certificates from public or untrusted third-party authorities. However, due to the partial_chain callback ignoring this configuration for chain validation purposes, any certificate issued by a CA included in Hex's default bundle remains trusted even if it is explicitly excluded from the operational store. This undermines the principle of least trust and can lead to unauthorized access, data exfiltration, or injection of malicious code under the guise of legitimate software updates or package downloads hosted on compromised Hex hosts.
Mitigation strategies must address both immediate remediation and long-term architectural corrections. The primary solution is to upgrade hexpm hex to version 2.5.2 or later, where this logic has been corrected to ensure that the partial_chain callback respects the cacerts_path configuration. Until an upgrade can be performed, administrators should avoid setting cacerts_path if they require strict enforcement of a custom CA store against all possible intermediates, as doing so currently provides a false sense of security. Alternatively, organizations may consider disabling automatic package installation verification or manually validating checksums and signatures for critical dependencies to mitigate the risk of compromised packages being accepted through this flawed validation path.
From an industry standard perspective, this vulnerability aligns with ATT&CK technique T1078 Valid Accounts if used in conjunction with credential theft, but more directly relates to MITM techniques where valid certificates are abused to establish trusted connections without user awareness. The flaw exemplifies CWE-295 as the system fails to properly validate the certificate chain against the intended trust anchor set by the administrator. Security teams should audit their Hex configurations and ensure that all instances of the software are updated to patched versions to prevent exploitation of this logic error in production environments relying on custom PKI infrastructures.