hackney EUVD-2026-109836

Exploitation requires a specific non-default pinning configuration: the application must call hackney with verify_peer and replace the trust store by passing cacerts or cacertfile in ssl_options to pin a private certificate authority, WITHOUT supplying its own partial_chain callback (a caller-supplied partial_chain is preserved and is not vulnerable). The attacker additionally must hold an on-path/MITM position and must possess a certificate for the pinned hostname that is both publicly trusted (chaining to a certifi-bundled root) and passes the still-enforced hostname check. Connections relying on hackney's default certifi trust store are not the target of this flaw. Limiting factors: config-dependent (private-CA pinning only), restricted to hackney 1.24.0 through 4.8.x, and the need for both network interception and a valid publicly trusted certificate for the exact pinned host.

This is a genuine high-priority issue for the specific population that uses it, but its real-world blast radius is narrower than the 9.1 CVSS 4.0 score suggests. The vuln.today Decision label is act_now and a vendor patch exists (hackney 4.9.0), which should drive urgency. The CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N) correctly captures that no privileges or user interaction are needed but that meaningful attack requirements apply: the AC:H/AT:P metrics reflect that the attacker must already hold an on-path (MITM) position AND must obtain a publicly trusted certificate valid for the pinned hostname (the hostname check is still enforced per the description). The high impact (VC:H/VI:H) is justified because successful exploitation yields full server impersonation - read and modify of TLS-protected traffic. However, exploitation is strictly conditional on a non-default deployment: the caller must pin to a private CA via cacerts/cacertfile under verify_peer without supplying its own partial_chain. No EPSS score, KEV status, or POC/exploit reference was provided in the input; the only code references are the fix PR and patch commits, so there is no public exploit identified. The absence of EPSS/KEV is not evidence of low risk, but combined with the specific configuration prerequisite this reads as a 'serious-but-targeted' flaw rather than a mass-exploitation event.

An Erlang/Elixir application uses hackney to reach an internal service and pins trust to a private CA by passing cacerts (or cacertfile) in ssl_options under verify_peer. An on-path attacker who holds a publicly trusted certificate for that exact hostname presents a chain ending in a root bundled in hackney's certifi store; hackney's retained partial_chain callback picks that root as the trust anchor over the operator's pinned CA, so the handshake succeeds and the attacker impersonates the server to intercept and alter traffic. No public exploit was identified at time of analysis; the mechanism is confirmed only by the fix diff in PR #978.