Skip to content

EEF-CVE-2026-115693 CVE-2026-115693

Custom cacerts or cacertfile do not restrict trust to the pinned CA in hackney

Not rated yet Hex
Severity
0.0 / 10
Unknown · CVSS 4.0
Exploit chance (EPSS)
0.27%
Chance of exploitation in the next 30 days. Higher than 18.91% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-295 Improper Certificate Validation
Fix
4.9.0
Upgrade hackney to this version or later

Description

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.

Affected versions

Hex

PackageVulnerableFixed in
hackney
>= 1.24.0, < 4.9.0
4.9.0

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

hackney Hex → 4.9.0

mix
{:hackney, "~> 4.9.0"} # then: mix deps.update hackney

Severity breakdown

CVSS 4.0 0.0

CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

Attack vector
Network
Attack complexity
High
Attack requirements
Present
Privileges required
None
User interaction
None
Confidentiality (vulnerable system)
High
Integrity (vulnerable system)
High
Availability (vulnerable system)
None
Confidentiality (subsequent systems)
None
Integrity (subsequent systems)
None
Availability (subsequent systems)
None

Weakness

CWE-295: Improper Certificate Validation

The product does not validate, or incorrectly validates, a certificate.

How to prevent it
  • Architecture and Design, Implementation: Certificates should be carefully managed and checked to assure that data are encrypted with the intended owner's public key.
  • Implementation: If certificate pinning is being used, ensure that all relevant properties of the certificate are fully validated before the certificate is pinned, including the hostname.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
EEF-CVE-2026-97200
Unbounded response body buffering and decompression in hackney
Not rated yet Also affects hackney
EEF-CVE-2026-113440
HTTP/1.1 and HTTP/2 redirects resend basic_auth and cookie to a different scheme or port in hackney
Not rated yet Also affects hackney
EEF-CVE-2026-115700
SSRF allowlist bypass via percent-encoded bracketed IPv6 or trailing-dot IP literal in hackney
Not rated yet Also affects hackney
EEF-CVE-2026-112880
CRLF injection in Proxy-Authorization header built from proxy_auth_fun in hackney
Not rated yet Also affects hackney
EEF-CVE-2026-47073
Unbounded memory consumption in WebSocket client in hackney
High Also affects hackney
EEF-CVE-2026-47067
Atom table exhaustion via unrecognized URL schemes in hackney
High Also affects hackney
EEF-CVE-2026-47072
CRLF injection in WebSocket upgrade request in hackney
High Also affects hackney
EEF-CVE-2026-47076
SSRF allowlist bypass via percent-encoded host in hackney
Medium Also affects hackney

Credits: Jonatan Männchen / EEF, Martin Karrer

Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor