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.
Published: 2026-10-26
Score: 9.1 Critical
EPSS: n/a
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Analysis and contextual insights are available on OpenCVE Cloud.

Remediation

Vendor Workaround

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.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Mon, 26 Oct 2026 14:00:00 +0000

Type Values Removed Values Added
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.
Title Custom cacerts or cacertfile do not restrict trust to the pinned CA in hackney
First Time appeared Benoitc
Benoitc hackney
Weaknesses CWE-295
CPEs cpe:2.3:a:benoitc:hackney:*:*:*:*:*:*:*:*
Vendors & Products Benoitc
Benoitc hackney
References
Metrics cvssV4_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'}


cve-icon MITRE

Status: PUBLISHED

Assigner: EEF

Published:

Updated: 2026-10-26T13:49:29.374Z

Reserved: 2026-10-25T10:45:02.327Z

Link: CVE-2026-115693

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-10-26T14:16:31.853

Modified: 2026-10-26T14:16:31.853

Link: CVE-2026-115693

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-10-26T15:30:15Z

Weaknesses