CVE-2026-115693

criticalpriority · track · 0EPSS 0.003 · 19 %ileUS
grimoire priorityP2 · Scheduled
Exploitable?
—
no known exploitation
Likely / severe?
0.27% (19th) EPSS
CVSS 9.1 · critical
Is it mine?
1 products
Check your exposure
Who says so?
1 sources
osv

EPSS · scored 2026-10-27

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.

01

cvss

Technical severity, 0–10. One row per scoring source.

9.1
010

base score 0–10 · higher = more severe · hover a vector to decode⚠ sources disagree · medium–critical · 6.9–9.1

v4.09.1criticalCVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:Xsecondary
v4.06.9mediumCVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:U/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:Xsecondary · CVSS-BT (t0sche)
02

weaknesses

The CWE weakness classes this flaw belongs to.

03

affected products (1)

Products and version ranges known to be affected.

04

advisories (1)

Vendor and ecosystem advisories describing this.

  • EEF-CVE-2026-115693Custom cacerts or cacertfile do not restrict trust to the pinned CA in hackney2026-10-26vendor · osvUS

    ## 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.

05

sources

Which sources assert this record, and when.

published 2026-10-26modified 2026-10-26
06

references (6) nvd

External citations — patches, advisories, analysis.

scry

Attackers weaponise vulnerabilities like this against internet-exposed services. See what is exposed on your perimeter with a free passive scan.

Free scan