Know every vulnerabilitybefore it knows you.
DevGuard continuously monitors your dependencies and alerts you when CVEs like this one affect your stack — with real-time threat intelligence built for developers.
EEF-CVE-2026-115693
Summary
Improper Certificate Validation vulnerability in hackney_ssl in benoitc hackney allows an on-path attacker to impersonate a server pinned to a private certificate authority via a certificate chain that ends in a publicly trusted root. hackney adds {partial_chain, fun hackney_ssl:partial_chain/1} to every verify_peer configuration. The callback returns any certificate in the peer chain whose public key matches a root in the bundled certifi store as the trust anchor, and OTP honours that callback over the configured cacerts. hackney_ssl:merge_ssl_opts/3 kept the callback when the caller replaced the trust store with cacerts or cacertfile in ssl_options, so a connection pinned to a private CA still accepted any chain that carried a publicly trusted root.
The hostname check still applies, so the attacker needs a publicly trusted certificate for the pinned hostname.
This issue affects hackney: from 1.24.0 before 4.9.0.
Details
1. Default trust options. hackney_ssl:check_hostname_opts/1 builds the verify_peer options for every TLS connection: the certifi cacerts, a hostname verify_fun, and {partial_chain, fun hackney_ssl:partial_chain/1}. The callback walks the peer chain and returns {trusted_ca, Cert} for the first certificate whose public key matches a root in the bundled certifi store, which lets OTP accept chains that end in a cross-signed root.
2. Merge keeps the callback. When the caller passes ssl_options, hackney_ssl:merge_ssl_opts/3 merges them over the defaults with the caller's values winning per key. cacerts or cacertfile replace the trust store, and a cacertfile removes the default cacerts, but partial_chain has no counterpart in the caller's options and stays.
3. Validation. OTP consults partial_chain before the configured trust store. A peer chain that carries any publicly trusted root therefore gets that root as its trust anchor, and the pinned cacerts are never consulted. Only the hostname verify_fun still constrains the attacker.
Impact
An attacker positioned between the client and a server pinned to a private CA, holding a publicly trusted certificate for the pinned hostname, can impersonate the server and read or modify the traffic the client sends and receives.
Workarounds
Pass your own {partial_chain, Fun} in ssl_options alongside cacerts or cacertfile. A caller-supplied partial_chain replaces hackney's in the merge, and a callback that returns unknown_ca makes OTP validate against the configured cacerts only.
Configurations
The caller passes cacerts or cacertfile in ssl_options to restrict trust to a private CA, without a partial_chain of its own. Connections that use hackney's default certifi trust store are not affected.
Upload your own SBOM in CycloneDX 1.6 or higher (JSON) directly here to check your vulnerabilities.
Drag and drop some file here, or click to select
The vulnerability can be exploited over the network without needing physical access. It is difficult for an attacker to exploit this vulnerability and may require special conditions. An attacker does not need any special privileges or access rights. No user interaction is needed for the attacker to exploit this vulnerability.
Exploitation attempts have been detected. Elevated vigilance and prompt remediation are advised.
The exploit probability is very low. The vulnerability is unlikely to be exploited in the next 30 days.
We did not find any exploit available. Neither in GitHub repositories nor in the Exploit-Database.
Browse More
Continuously monitor your dependencies and get alerted when vulnerabilities like this one affect your stack.
Checkout DevGuard