CVE-2026-115693 Custom cacerts or cacertfile do not restrict trust to the pinned CA in hackney
- Published
- Updated
- Exploit status
- No public exploit known
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.
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.
Affected products
| Product | Affected versions | Fixed in |
|---|---|---|
| benoitc hackney | >= 1.24.0, < 4.9.0 | 4.9.0 |
| benoitc hackney | >= d8a9afcf5c3849904274e2eba1df56c63d1a1a0c, < 915eb5737e9c489d8fc22eec8cdae30e9b027be4 | 915eb5737e9c489d8fc22eec8cdae30e9b027be4 |
References
- Drop the certifi partial_chain when the caller pins cacerts or cacertfile (benoitc/hackney#978) related
- EEF CNA record for CVE-2026-115693 related
- OSV record EEF-CVE-2026-115693 related
- hackney 4.9.0 release notes related vendor-advisory
- Introducing commit d8a9afc in benoitc/hackney related
- Fix commit 915eb57 in benoitc/hackney patch