{"id":"CVE-2026-115693","aliases":["EEF-CVE-2026-115693","EUVD-2026-109836","GHSA-g7gg-9jhv-68h6"],"status":"published","title":"Custom cacerts or cacertfile do not restrict trust to the pinned CA in hackney","description":"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.\n\nThe hostname check still applies, so the attacker needs a publicly trusted certificate for the pinned hostname.\n\nThis issue affects hackney: from 1.24.0 before 4.9.0.","severity":{"version":"4.0","score":9.1,"vector":"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","level":"critical","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-11","score":0.00267,"percentile":0.19034,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-295"],"published":"2026-10-26T13:49:29Z","modified":"2026-11-04T02:30:24Z","fixes":[{"ecosystem":"Hex","package":"hackney","fixed_in":["4.9.0"],"sources":["osv"]}],"affected":[{"source":"osv","ecosystem":"Hex","package":"hackney","ranges":[{"type":"SEMVER","events":[{"introduced":"1.24.0"},{"fixed":"4.9.0"}]}],"versions":["1.24.0","1.24.1","1.25.0","2.0.0","2.0.0-beta.1","2.0.1","3.0.0","3.0.1","3.0.2","3.0.3","3.1.0","3.1.1","3.1.2","3.2.0","3.2.1","4.0.0","4.0.1","4.0.2","4.0.3","4.1.0","4.2.0","4.2.1","4.2.2","4.2.3","4.3.0","4.4.0","4.4.1","4.4.2","4.4.3","4.4.5","4.5.0","4.5.1","4.5.2","4.6.0","4.6.1","4.7.0","4.7.1","4.7.2","4.7.3","4.7.4","4.8.0","4.8.1","4.8.2","4.8.3","4.8.4","4.8.5","4.8.6","4.8.7"]}],"products":[{"vendor":"benoitc","product":"hackney"},{"vendor":"hackney","product":"hackney"}],"references":[{"url":"https://github.com/benoitc/hackney/pull/978","tags":["related","fix","web"]},{"url":"https://cna.erlef.org/cves/CVE-2026-115693.html","tags":["related","web"]},{"url":"https://osv.dev/vulnerability/EEF-CVE-2026-115693","tags":["related","web"]},{"url":"https://github.com/benoitc/hackney/releases/tag/4.9.0","tags":["vendor-advisory","related","advisory"]},{"url":"https://github.com/benoitc/hackney/commit/d8a9afcf5c3849904274e2eba1df56c63d1a1a0c","tags":["related","fix","web"]},{"url":"https://github.com/benoitc/hackney/commit/915eb5737e9c489d8fc22eec8cdae30e9b027be4","tags":["patch","fix"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-115693","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-g7gg-9jhv-68h6"},{"url":"https://github.com","tags":["web"]},{"url":"https://repo.hex.pm","tags":["web"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/115xxx/CVE-2026-115693.json","tags":["advisory"]},{"url":"https://github.com/benoitc/hackney","tags":["package"]},{"url":"https://hex.pm/packages/hackney","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-115693","title":"Custom cacerts or cacertfile do not restrict trust to the pinned CA in hackney","description":"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.\n\nThe hostname check still applies, so the attacker needs a publicly trusted certificate for the pinned hostname.\n\nThis issue affects hackney: from 1.24.0 before 4.9.0.","status":"published","published":"2026-10-26T13:49:29.374Z","modified":"2026-11-02T19:43:07.244Z","cvss":[{"version":"4.0","score":9.1,"vector":"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","level":"critical","assessor":"cna"}],"cwes":["CWE-295"],"updated_at":"2026-11-02T20:51:24.336573Z"}],"euvd":[{"id":"EUVD-2026-109836","description":"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.\n\nThe hostname check still applies, so the attacker needs a publicly trusted certificate for the pinned hostname.\n\nThis issue affects hackney: from 1.24.0 before 4.9.0.","status":"published","published":"2026-10-26T13:49:29Z","modified":"2026-11-02T19:43:07Z","cvss":[{"version":"4.0","score":9.1,"vector":"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","level":"critical"}],"updated_at":"2026-11-03T05:08:38.228652Z"}],"ghsa":[{"id":"GHSA-g7gg-9jhv-68h6","title":"Improper Certificate Validation vulnerability in hackney_ssl in benoitc hackney allows an on-path...","description":"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.\n\nThe hostname check still applies, so the attacker needs a publicly trusted certificate for the pinned hostname.\n\nThis issue affects hackney: from 1.24.0 before 4.9.0.","status":"published","published":"2026-10-26T15:34:42Z","modified":"2026-10-26T15:34:47Z","cvss":[{"version":"4.0","score":9.1,"vector":"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/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:X","level":"critical"}],"cwes":["CWE-295"],"updated_at":"2026-11-02T15:14:23.996006Z"}],"nvd":[{"id":"CVE-2026-115693","description":"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.\n\nThe hostname check still applies, so the attacker needs a publicly trusted certificate for the pinned hostname.\n\nThis issue affects hackney: from 1.24.0 before 4.9.0.","status":"published","published":"2026-10-26T14:16:31.853Z","modified":"2026-11-02T20:17:30.66Z","cvss":[{"version":"4.0","score":9.1,"vector":"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/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:X","level":"critical","assessor":"secondary"}],"cwes":["CWE-295"],"updated_at":"2026-11-03T00:02:35.749072Z"}],"osv":[{"id":"CVE-2026-115693","title":"Custom cacerts or cacertfile do not restrict trust to the pinned CA in hackney","description":"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.\n\nThe hostname check still applies, so the attacker needs a publicly trusted certificate for the pinned hostname.\n\nThis issue affects hackney: from 1.24.0 before 4.9.0.","status":"published","published":"2026-10-26T13:49:29.374Z","modified":"2026-11-04T02:30:24.783977688Z","cvss":[{"version":"4.0","score":9.1,"vector":"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","level":"critical"}],"cwes":["CWE-295"],"updated_at":"2026-11-04T02:55:01.518827Z"},{"id":"EEF-CVE-2026-115693","title":"Custom cacerts or cacertfile do not restrict trust to the pinned CA in hackney","description":"## Summary\n\nImproper 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.\n\nThe hostname check still applies, so the attacker needs a publicly trusted certificate for the pinned hostname.\n\nThis issue affects hackney: from 1.24.0 before 4.9.0.\n\n## Details\n\n**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.\n\n**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.\n\n**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.\n\n## Impact\n\nAn 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.\n\n## Workarounds\n\nPass 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.\n\n## Configurations\n\nThe 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.","status":"published","published":"2026-10-26T13:49:29.374Z","modified":"2026-10-26T14:00:04.842588289Z","cvss":[{"version":"4.0","score":9.1,"vector":"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","level":"critical"}],"cwes":["CWE-295"],"updated_at":"2026-11-02T15:46:33.047032Z"}]}}