hackneyの独自CA指定時に公開CAの証明書チェーンを受け入れる不備（CVE-2026-115693、CVSS 9.1）。影響バージョン、攻撃成立条件、4.9.0への更新を整理。
30秒でわかる / THE SIGNAL
独自CAを指定したhackney接続でも、公開CAの証明書チェーンが信頼され得る問題。攻撃者が通信経路上にいて、対象ホスト名の有効な公開CA証明書を保有する場合にサーバーを偽装できる恐れがある。
何が公表されたか
2026年10月26日にErlang Ecosystem FoundationのCNAがCVE-2026-115693を公表。hackney_sslの証明書検証不備で、CVSS 9.1（Critical）。独自CAのみに信頼を限定したつもりの通信でも、公開CAを信頼するpartial_chainコールバックが残る場合がある。一次情報：https://cna.erlef.org/cves/CVE-2026-115693.html
影響バージョンと攻撃条件
影響するのはhackney 1.24.0以上4.9.0未満。呼び出し側がssl_optionsでcacertsまたはcacertfileを指定して独自CAに信頼を限定し、独自のpartial_chainを指定していない構成が対象。既定のcertifi信頼ストアを使う接続はこの問題の対象外。ホスト名検証は維持されるため、攻撃者は通信経路上の位置に加え、対象ホスト名に対する公開CA発行の有効な証明書を必要とする。
原因と修正
hackneyはTLS verify_peer設定にcertifiの公開ルート証明書を認めるpartial_chainを追加する。呼び出し側がcacerts/cacertfileを上書きしても、このコールバックが残り、指定した独自CAより先に公開ルートが信頼される可能性があった。修正版は4.9.0。公式リリース：https://github.com/benoitc/hackney/releases/tag/4.9.0
推奨対応と悪用状況
hackney 4.9.0以降へ更新し、独自CAを利用する接続の証明書検証を再確認する。更新できない場合は、独自のpartial_chainコールバックでunknown_caを返して指定したCAストアで検証する回避策が公式CNAに記載されている。2026年10月27日時点で一次情報から実環境での悪用が確認されたとは断定できない。
WORK SIGNALの視点
TLSの『独自CAのみ信頼する』という設定意図が、ライブラリの既定コールバックによって崩れる例。依存ライブラリの更新に加え、実際の接続先証明書で検証境界をテストすることが重要だ。