---
id: "CVE-2026-115693"
kind: "vulnerability"
aliases: ["CVE-2026-115693"]
title: "hackney (Erlang): pinned private CA certificate checks can be bypassed by MITM"
severity: "critical"
cvss: 9.1
epss: null
exploited: false
status: "open"
category: "package"
products: []
ecosystems: []
tags: ["elixir", "erlang", "hackney", "package", "tls"]
not_affected_if: ["default-trust-store", "no-hackney"]
published_at: "2026-10-26T14:16:31+00:00"
first_seen_at: "2026-10-26T14:30:36+00:00"
updated_at: "2026-10-26T14:32:04+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-115693", "first_seen_at": "2026-10-26T14:30:36+00:00"}]
---

# hackney (Erlang): pinned private CA certificate checks can be bypassed by MITM

hackney is an Erlang HTTP client, and versions from 1.24.0 before 4.9.0 keep a partial-chain callback even when callers replace the trust store with cacerts or cacertfile. An on-path attacker holding a publicly trusted certificate for the pinned hostname can impersonate that server and read or alter the traffic.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Check the locked hackney version in `rebar.lock` or `rebar.config`, or run `rebar3 deps` and look for hackney.
- Look for `ssl_options` passing `cacerts` or `cacertfile` to hackney connections.

## Fix

- Upgrade hackney to `4.9.0` or later.

## Timeline

- 2026-10-26T14:30:36+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-115693

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_