Apache Thrift の c_glib で TLS 証明書のホスト名を検証しない

Critical（CVSS 9.1）に分類されるApache Apache Thriftの脆弱性です。Apache Thrift の c_glib バインディングが、TLS で接続した相手の証明書とホスト名の対応を適切に検証しない。証明書そのものは正しく署名されていても、接続先のホスト名と証明書の名前が一致しているかを確かめないため、正当な証明書を持つ別のホスト（あるいは経路上の攻撃者）を本来の相手だと思い込んで通信してしまう。暗号化はされているのに相手が誰かを確かめていない状態で、中間者攻撃で通信内容を読まれ、書き換えられる余地が生まれる。影響範囲は 0.24.0 より前のすべてのバージョンで、修正版は 0.24.0 である。NVD の CPE も 0.24.0 未満として同じ範囲を示す。CVSS は NVD（Primary、nvd@nist.gov）が CVSS 3.1 で 9.1 Critical（AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N）、CNA の Apache（security@apache.org）が CVSS 4.0 で 9.1 Critical（AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N）で、スコアは一致しており、機密性と完全性の両方に高い影響があるという見立ても揃っている。違いは攻撃の難易度の扱いで、Apache 側は経路に割り込む必要がある点を AC:H としている。CWE は CWE-297（ホスト不一致の証明書の不適切な検証）。CISA KEV には未収載で、悪用が確認されたという公表情報も無い。NVD の vulnStatus は Analyzed。

この欠陥は c_glib バインディングで TLS を使っているクライアント側が対象で、C 実装の Thrift クライアントが暗号化ありで外部やネットワーク越しの相手に接続している箇所を洗い出すのが判定作業になる。Java や Python など他の言語のバインディングだけを使っているなら対象外である。確認は、実行ファイルが libthrift_c_glib をリンクしているか（ldd）、ビルド時に c_glib を有効化していたか、その上で TLS 対応のトランスポート（SSL ソケット）を使っているかの三段で絞る。見落としやすいのは、社内ネットワークだから平文でよいと考えて TLS を使っていない箇所ではなく、その逆、つまり「TLS にしたから安全だ」と整理して監査項目から外してしまった通信である。証明書の検証をしていないので、TLS を使っていること自体が安全の根拠にならない。すぐに 0.24.0 へ上げられない場合は、経路に第三者が割り込めないところまで通信を閉じ込めるのが緩和になる。具体的には、Thrift の通信をプライベートサブネットや VPC 内に限定する、接続先を IP アドレス指定ではなく管理下の DNS と固定経路で解決させる、相互 TLS を強制して双方向で相手を確かめる、といった形である。これらは根本対策ではないので、更新の予定は残す。完了条件は、（1）c_glib で TLS を使っている全バイナリが 0.24.0 以降でビルドされていること、（2）同じ 0.24.0 で修正された c_glib の境界外読み取り（CVE-2026-58023）も併せて解消していること、（3）更新後に想定外のホストへ接続していた痕跡がないかログで確認したこと、この 3 点である。証明書検証をしていなかった期間の通信は盗聴・改ざんされていた可能性を否定できないため、その経路で流していた認証情報があるなら再発行を検討する。

Apache Apache Thrift を利用している場合、稼働バージョンが影響範囲に含まれるかを一次情報（https://nvd.nist.gov/vuln/detail/CVE-2026-48144）で確認してください。AWS・GCP・Azure・Linux それぞれの対応状況は本ページの「クラウド／OS 別の対応状況」表にまとめています。確認できていない項目は「情報確認中」と明記しており、存在しないパッチ番号・バージョンは記載していません。