Apache Thriftに5件の脆弱性、通信の盗み見や機能停止の恐れ CVE-2026-48144

多くのシステムの裏側で「ソフト同士の会話」を担う通信基盤ソフトApache Thriftに、まとめて5件の脆弱性（ソフトの弱点）が見つかりました。最も危険なものは、本来暗号化されているはずの通信を第三者に盗み見・書き換えされる恐れがあり、深刻度は10点満点中9.1（CVE-2026-48144）と評価されています。

残りの4件は、わざと細工したデータを送りつけてサービスを応答不能にする「サービス妨害」型が中心です。開発元のApacheソフトウェア財団は、すべての不具合を修正した新バージョン0.24.0を公開しています。対策はこのバージョンへの更新です。今のところ、実際に攻撃に使われたという報告（後述する米政府の攻撃リスト入り）はありません。まず「自分の使っているシステムが対象か」を落ち着いて確認するのが先決です。

見つかった5件の脆弱性の早見表

今回の5件は、Apache Thriftが対応するプログラミング言語ごとの部品（言語バインディング）のどこに穴があるかで影響先が分かれます。まず全体像を整理します。深刻度の数値はCVSS 4.0（脆弱性の危険度を10点満点で表す国際的な指標）です。

ざっくり分けると、通信の盗み見につながる「なりすまし」型が2件（c_glibとC++）、サービスを止める「妨害」型が3件（Python・Go・PHP・Java）です。5件すべてが0.24.0で修正されているため、対処のゴールは共通しています。各番号の詳しい中身はこの後で1件ずつ説明します。

Apache Thriftとは何か、なぜ広く使われているのか

Apache Thriftは、もともとFacebook（現Meta）が社内で作り、その後Apacheソフトウェア財団に寄贈されたオープンソースの通信基盤ソフトです。役割を一言でいうと、「別々のプログラミング言語で書かれたソフト同士が、同じルールでデータをやり取りできるようにする翻訳係」です。

たとえば、C++で書かれた在庫管理の部品と、Pythonで書かれた画面表示の部品と、Javaで書かれた集計の部品を、1つのサービスの中で連携させたい場面があります。Apache Thrift公式サイトによれば、C++・Java・Python・PHP・Ruby・Go・C#・Node.jsなど十数種類の言語に対応しており、データの形式と通信の手順を一度決めれば、各言語向けの通信コードを自動で生成してくれます。

この「自動生成された通信コード」が、多くのシステムの土台として静かに動いています。大規模なデータ処理基盤やマイクロサービス（機能を小さな部品に分けて連携させる作り方）で採用例が多く、利用者はふだんThriftを直接意識しません。だからこそ厄介で、「自分のサービスがThriftを使っている」という自覚がないまま影響を受けるケースが起こり得ます。今回の脆弱性が広い読者に関係し得るのは、この「土台ゆえの見えにくさ」が理由です。

誰が、何を狙う脆弱性なのか

数値や専門用語だけでは「自分に関係あるのか」が判断しづらいので、今回の穴を狙う相手と、その狙いをかみ砕いて整理します。

まず、盗み見型（CVE-2026-48144・CVE-2026-48145）で警戒すべきなのは、通信の通り道に割り込める立場の第三者です。具体的には、社内ネットワークにすでに侵入している攻撃者、公衆Wi‑Fiや通信経路を管理できる立場の者などが該当します。遠くから無差別に攻撃するというより、「通信の間に入り込める位置」にいる相手が対象です。

その相手は、Thriftが通信相手の身元（サーバー証明書）をきちんと確認しきれていない甘さを突いて、正規のサーバーになりすまし、暗号化されているはずのやり取りを盗み見たり、中身をこっそり書き換えたりします。利用者からは正しい相手と話しているように見えるのに、実際には偽物を経由している、という状態です。

被害の出方は立場によって違います。サービスを使うエンドユーザーから見れば、ログイン用のIDや認証の合言葉（トークン）が抜き取られたり、返ってくる応答を差し替えられたりする恐れがあります。システムを運用する企業や組織から見れば、内部の通信をのぞかれること自体が情報漏えいであり、後述する妨害型の穴と組み合わされればサービスそのものを止められます。だからこそ、この後の対策セクションで示す0.24.0への更新が要になります。

なお、同じApache製の通信ライブラリでは、受信データの扱いを突かれる穴が繰り返し見つかっています。少し前にはApache MINAでログイン不要でサーバーを乗っ取られる脆弱性が報じられました。「外から届くデータをどこまで信じるか」という共通の難所が、今回のThriftでも形を変えて現れています。

各脆弱性の詳しい中身

5件を1件ずつ見ていきます。番号で検索してたどり着いた方のために、危険度の高い順に並べます。

CVE-2026-48144：c_glib版で通信相手のなりすましを許す（最も危険）

C言語系の部品「c_glib」で、暗号化通信（TLS）を使う際に接続先の証明書のホスト名を正しく突き合わせていなかった問題です。証明書は「この相手は本物です」という身分証のようなものですが、その名義（ホスト名）が実際の接続先と一致しているかの確認が甘く、別人の正規証明書でもすり抜けてしまいます。これが、通信の間に割り込む「中間者攻撃」を成立させます。分類は証明書のホスト名不一致（CWE-297）で、CVSS 4.0で9.1（緊急）と、5件で最も高い評価です。0.24.0より前のc_glibが対象です。

CVE-2026-43871：Python・Go・PHP・Java版が無限ループで止まる

Python・Go・PHP・Javaと4つの言語部品にまたがる、抜け出せない繰り返し処理（無限ループ、CWE-835）の問題です。攻撃者が細工したデータを送ると、Thriftがそれを処理しようとして終わらないループに入り、サービスが応答を返せなくなります。ログイン不要で外から発火させられる点が危険で、CVSS 4.0で8.7（高）。影響する言語の数が最も多く、Python（PyPI）・Go・PHP（Packagist）・Java（Maven）のいずれの配布経路で導入していても対象になり得ます。

CVE-2026-48145：C++版でも証明書の確認が甘い

CVE-2026-48144と同じ種類の問題が、今度はC++の部品で起きます。暗号化通信の際に証明書のホスト名を検証しきれず（CWE-297）、なりすましを許します。攻撃を成立させる条件がやや厳しいぶん評価はわずかに低く、CVSS 4.0で8.2（高）ですが、通信の盗み見・改ざんという結果は同じです。C++で自前のサーバー・クライアントを組んでいる場合は要注意です。

CVE-2026-45112：Java版がメモリを使い果たして止まる

Javaの部品（org.apache.thrift:libthrift）で、受信データに対して使うメモリの上限を設けていなかった問題です（CWE-770）。大量にメモリを要求するようなデータを送りつけられると、サーバーがメモリを使い果たして停止します。影響するのは0.19.0から0.23系までのバージョンで、CVSS 4.0で6.9（中）。単体では乗っ取りにはつながりませんが、サービス停止の材料になります。

CVE-2026-41608：Python版が圧縮データの膨張で止まる

Pythonの部品で、極端に圧縮されたデータを展開する際の膨張を想定していなかった問題です（CWE-409）。小さく圧縮したデータが展開時に巨大化する性質を悪用され、少ないデータ量でサーバーの処理能力を食いつぶされます。いわゆる「解凍爆弾」に近い手口です。現時点でCVSSは未評価ですが、Apacheは0.24.0での修正を案内しています。危険度の数値がまだ付いていないだけで、対処が不要というわけではありません。

自分のシステムが対象か、言語別の早見表で確認する

「どの言語でThriftを使っているか」で、関係する脆弱性が変わります。自社のサービスが使っている言語部品を思い浮かべながら、下の表で該当する行を確認してください。いずれの場合も、対策は0.24.0への更新で共通です。

複数の言語部品を併用している場合は、その分だけ関係する脆弱性が増えます。特に暗号化通信を使うc_glib・C++の構成は、盗み見型の緊急・高リスクにあたるため優先度が高くなります。

対策はどうすればよいか

根本的な対策は、Apache Thriftを0.24.0以降へ更新することです。5件すべてがこのバージョンで修正されています。Apache Thriftの配布ページから入手できるほか、多くの現場は言語ごとのパッケージ管理から導入しているため、次のように更新するのが早道です。

• Python：pip install "thrift>=0.24.0" で更新
• Java：Maven / Gradleのorg.apache.thrift:libthriftを0.24.0へ
• Go：go get で該当モジュールを0.24.0以降へ
• PHP：Composerでapache/thriftを0.24.0へ
• C++ / c_glib：0.24.0のソースから再ビルド

すぐに更新できない場合の当座の緩和策としては、Thriftの通信口を信頼できないネットワークに直接さらさないこと、外部から届くデータのサイズや処理時間に上限を設けることが挙げられます。ただしこれらは時間稼ぎに過ぎず、根本解決は更新です。自分たちのソフトがどの部品に依存しているかを洗い出す作業には、オープンソース部品の依存関係を点検する考え方が役立ちます。土台ソフトは「使っている自覚がない」ことが最大の穴なので、依存の棚卸しから始めるのが確実です。

なお、今回の5件は現時点で、米政府の担当機関CISAが公開する「実際に攻撃されている脆弱性リスト（KEV）」には登録されていません。CISA KEVの最新状況は随時変わるため、リスト入りした場合は緊急度が一段上がると考えてください。今は過度に慌てる段階ではありませんが、放置してよい理由もありません。

技術的に見ると：なぜ同じ種類の穴が繰り返されるのか

今回の5件は、大きく2つの「よくある落とし穴」に分かれます。1つは暗号化通信での証明書検証、もう1つは受信データの処理量の制御です。どちらも、複数の言語に同じ機能を横展開して実装する多言語対応ライブラリならではの弱点を映しています。

証明書のホスト名検証（CVE-2026-48144・CVE-2026-48145）は、暗号化そのものが効いていても、相手の名義を突き合わせなければ「暗号化された偽物との通信」になってしまう、という古典的な穴です。言語ごとにTLSの実装が異なるため、ある言語では正しく検証していても、別の言語部品では抜けが残る、ということが起こります。今回c_glibとC++で個別に番号が振られたのは、その典型です。

残る3件（無限ループ・メモリ枯渇・解凍爆弾）は、いずれも「外から届くデータを、どこまでの量まで受け入れて処理するか」の上限設計の甘さです。Thriftのように不特定の相手からデータを受け取る通信基盤では、正しいデータの処理だけでなく、悪意ある極端なデータを送られたときに自分を守れるかまでが品質になります。同じApache製ライブラリで受信データ処理の穴が繰り返されているのは、この難しさの表れです。関連する事例はオープンソースの依存を点検する記事でも整理しています。

まとめ

Apache Thriftに見つかった5件の脆弱性は、通信の盗み見につながる「なりすまし」型が2件、サービスを止める「妨害」型が3件という内訳でした。最も危険なのはc_glib版のCVE-2026-48144（深刻度9.1）ですが、影響が最も広いのは4言語にまたがるCVE-2026-43871です。いずれも0.24.0への更新で解消します。

Thriftは表に出ないぶん、使っている自覚のないまま影響を受けやすい土台ソフトです。実際に攻撃されている報告はまだありませんが、まずは自社のサービスがどの言語部品でThriftに依存しているかを確認し、0.24.0への更新を計画してください。KEVへの登録や新たな脆弱性の追加があれば、本記事に追記します。

参照元

• ▸ NVD - CVE-2026-48144（c_glib 証明書検証不備、CVSS 9.1）
• ▸ NVD - CVE-2026-43871（Python/Go/PHP/Java 無限ループ、CVSS 8.7）
• ▸ NVD - CVE-2026-48145（C++ 証明書検証不備、CVSS 8.2）
• ▸ NVD - CVE-2026-45112（Java リソース枯渇、CVSS 6.9）
• ▸ NVD - CVE-2026-41608（Python データ増幅、CVSS未評価）
• ▸ Apache Thrift 公式サイト
• ▸ Apache Thrift ダウンロード（0.24.0）