本文へ移動
English version →
重大 9.1 急ぎ度: 早めに

ssl_verify_funに証明書照合の脆弱性、1.1.8で修正

ErlangとElixirで使われるTLS検証ライブラリssl_verify_funに、ワイルドカード証明書のホスト名を誤って受け入れる脆弱性が公表されました。依存関係に含まれていないかを調べ、1.1.8以降へ更新してください。

CVE-2026-117666 公開 更新 執筆・監修: 佐々木 航 人が監修しながらAIを活用して執筆
画像は生成 AI で作成したイメージです

急ぎ度: 早めに

CVSS v4は9.1と高い一方で、悪用には通信経路への割り込みと限られた設定が必要で、修正版1.1.8が公開済みのため、早めの更新が妥当と見ています。

関係があるか

ErlangやElixirで作ったサービスやクライアントのうち、ssl_verify_funをTLSの証明書検証に使っているものが対象です。ただしErlang/OTP 20.0以降でserver_name_indicationを設定したままのクライアントは、sslがホスト名の不一致を先に拒否するため影響を受けません。影響を受けるのは、SNIを無効にしているクライアント、このライブラリでクライアント証明書のホスト名を検証しているサーバー、verify_cert_hostname/2を直接呼んでいるコードです。

製品影響を受ける版修正版
ssl_verify_fun(Hexパッケージ) 1.0.1以上、1.1.8より前 1.1.8
ssl_verify_fun(GitHubのdeadtrickster/ssl_verify_fun.erlを直接参照している場合) コミットa49ca56923356c7a3981692b23c42ef32c2990e0以降、ca34031299cd2e0c98794c0da4ba556b94e39aadより前 コミットca34031299cd2e0c98794c0da4ba556b94e39aad

確かめ方

  1. 1プロジェクトのmix.lockやrebar.lockにssl_verify_funがあるかを調べ、版が1.0.1以上1.1.8未満かを確認します。直接依存に書いていなくても、HTTPクライアントなどの依存先を通じて入っていることがあります。
  2. 2ソースコードでserver_name_indicationをfalseにしている箇所や、verify_cert_hostname/2を呼んでいる箇所がないかを検索します。
  3. 3サーバーでクライアント証明書を検証している場合は、verify_funにssl_verify_funを指定しているかを設定から確認します。
  4. 4本番環境にデプロイ済みのリリースやコンテナイメージに含まれる版が、ロックファイルと一致しているかも確かめます。

何が起きたか

ssl_verify_funは、TLSの証明書に書かれたホスト名と接続先が一致するかの照合を誤り、本来は別のホスト名にしか使えない証明書を受け入れることがあります。接続先になりすました相手を、正しい相手として扱ってしまう脆弱性です。2026年10月30日に公表されました。

原因はワイルドカードの照合処理です。src/ssl_verify_hostname.erlのtry_match_wildcard/4が、*の前後の文字列だけを照合し、*がドットまで飲み込んでしまいます。RFC 6125はワイルドカードを最も左のラベルの中に限ると定めていますが、実装はこれを守っていませんでした。

同じ照合処理のせいで、*.168.1.1のような証明書がIPアドレスの192.168.1.1にも一致します。ラベル全体をワイルドカードにした通常の形式は、正しく照合されています。

攻撃の流れ

  1. 1

    通信に割り込む

    攻撃者が、クライアントやサーバーの通信経路上に入り込みます。

  2. 2

    証明書を提示

    ラベルの一部にだけワイルドカードを含む証明書を、通信相手として差し出します。

  3. 3

    照合をすり抜け

    ssl_verify_funがホスト名の不一致を見逃し、証明書を受け入れます。

  4. 4

    相手になりすます

    TLS接続が成立し、攻撃者が正規の相手として振る舞います。

公開されている情報をもとにした流れの例です。

どう悪用されるか

認証は要らず、利用者の操作も必要ありません。ただし、攻撃者が通信経路に割り込める位置にいること(中間者攻撃)と、条件に合う証明書を用意することが前提です。CVSS v4で攻撃条件の複雑さが高く評価されているのは、このためです。

成立すると、通信相手になりすまされ、やり取りするデータの盗み見や改ざんにつながります。評価でも、機密性と完全性への影響が高いとされています。可用性への影響はありません。

今すぐやること

  1. 1

    利用の有無と版を調べる

    ロックファイルでssl_verify_funの版を確認します。直接の依存に書いていなくても、依存先から入っている場合があります。

    grep ssl_verify_fun mix.lock
  2. 2

    1.1.8へ更新する

    ssl_verify_funを1.1.8以降に更新し、テストを通したうえで本番に反映します。GitHubのリポジトリを直接参照している場合は、修正コミット以降を指定します。

    mix deps.update ssl_verify_fun
  3. 3

    リリースを作り直して配備する

    ロックファイルを更新しただけでは、稼働中のリリースやコンテナイメージは変わりません。再ビルドして入れ替えます。

  4. 4

    SNIの設定を見直す

    クライアントでserver_name_indicationを無効にしている箇所があれば、理由を確認し、有効にできるものは戻します。更新までのあいだ、影響を小さくできます。

  5. 5

    ベンダーの告知を確認する

    ssl_verify_funのGitHubセキュリティアドバイザリで、影響範囲と修正内容の最新情報を確かめます。

すぐ更新できないとき

すぐに更新できない場合は、クライアントでserver_name_indicationを設定したままにして、Erlang/OTP 20.0以降で動かしてください。sslがホスト名の不一致を先に拒否します。サーバーでのクライアント証明書のホスト名検証と、verify_cert_hostname/2の直接呼び出しは、この方法では防げません。該当する場合は、修正版への更新を優先します。

背景

ssl_verify_funは、Erlang/OTPのsslが証明書を検証するときに呼ぶverify_funの実装を、ライブラリとして提供するものです。証明書の期限や発行元に加えて、ホスト名の照合もここで行えます。HTTPクライアントのhackneyなど、ほかのパッケージの依存として入っていることが多く、開発チームが存在を意識していないケースもあります。

今回の問題は、ワイルドカードを含む証明書の扱いに絞られています。ホスト名の照合を自前で持つライブラリは、RFCの規則を実装の細部まで写す必要があり、その細部の一つで誤っていました。Erlang/OTP 20.0以降はsslがホスト名を先に確認するため、通常のクライアント構成では、このライブラリの誤りが表に出にくくなっています。

よくある質問

Q.上位のライブラリが版を固定していて、ssl_verify_funだけ更新できないときはどうしますか。
A.まず、上位ライブラリ側で1.1.8以降を許す版が出ていないかを確認します。ない場合は、Elixirならmix.exsでssl_verify_funの依存にoverride: trueを付けて版を指定する方法があります。互換性を確認するため、更新後に通信のテストを行ってください。

この記事は、取得元の公開情報をもとに、人が監修しながらAIを活用して執筆しています。執筆と監修は佐々木 航が担い、公開したあとも人が内容を確認しています。誤りに気づいたときは直し、記事の末尾に訂正の行を残します。対応を決める前に、下の原文と参照先も確認してください。

影響パッケージ

種類パッケージ影響を受ける版修正版
deadtrickster ssl_verify_fun
a49ca56923356c7a3981692b23c42ef32c2990e0 以上 ca34031299cd2e0c98794c0da4ba556b94e39aad 未満
ca34031299cd2e0c98794c0da4ba556b94e39aad
Hex ssl_verify_fun
1.0.1 以上 1.1.8 未満
1.1.8
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。

Improper Validation of Certificate with Host Mismatch vulnerability in deadtrickster ssl_verify_fun allows an adversary in the middle to impersonate a TLS peer via a certificate that carries a partial-label wildcard. try_match_wildcard/4 in src/ssl_verify_hostname.erl anchors only the text before and after the * of an identifier such as f*.example.net, so the wildcard also consumes dots and the certificate is accepted for f.evil.example.net. RFC 6125 confines a wildcard to the left-most label. The same matcher lets *.168.1.1 match the IP literal 192.168.1.1. Whole-label wildcards are matched correctly.

Erlang/OTP 20.0 and later check the hostname in ssl before a user verify_fun sees valid_peer, so a client that keeps server_name_indication set rejects the mismatch regardless. Exposed are clients that disable SNI, servers that verify client certificate hostnames with this library, and direct callers of verify_cert_hostname/2.

This issue affects ssl_verify_fun: from 1.0.1 before 1.1.8.

出典: CVE.org (CVE Program・cvelistV5) NVD GitHub Advisory

参照URL

当サイトでは、アクセス解析と広告の効果測定のために Cookie を使います。株式会社Game のサイト共通の設定です。 詳しく