CVE-2026-34486｜Tomcat の暗号化迂回と影響する 3 バージョン

はじめに

2026 年 8 月 4 日、CISA が Apache Tomcat の CVE-2026-34486 を KEV カタログへ追加しました。脆弱性自体は 4 月に公表されていたもので、今回の追加は悪用が確認されたことを示すものです。脆弱性スキャナーの検出結果や社内からの照会を受けて、自環境が対象かどうかの切り分けを求められている方も多いと思われます。

結論から述べると、影響を受けるのは Apache Tomcat 11.0.20、10.1.53、9.0.116 の 3 バージョンのみです。

さらに、実際に問題となるのは Tomcat のクラスタリング機能を有効にしている環境に限られます。単一構成で運用している場合、対象バージョンであっても影響を受けません。

対処は 11.0.21、10.1.54、9.0.117 のいずれかへのアップグレードです。すぐに更新できない場合は、クラスター通信のポートを到達可能な範囲から切り離すことが緩和につながります。なお、Apache が付与している深刻度は「important」で、CVSS スコアは Apache からは提供されていません。

CVE-2026-34486 の概要と KEV 登録の経緯

CVE-2026-34486 は、Apache Tomcat のクラスタリング基盤である Tribes において、通信を暗号化するための EncryptInterceptor が迂回され得る脆弱性です。CWE 分類は CWE-311（機微データの暗号化の欠如）で、Apache による深刻度表記は important です。

Apache Tomcat のセキュリティチームへの報告は 2026 年 3 月 26 日、公表は 4 月 9 日でした。そこから約 4 か月を経た 8 月 4 日に、CISA が KEV カタログへ追加しています。KEV への追加は、悪用の証拠が確認されたことを意味します。公表当初から複数の PoC が公開されていた経緯を踏まえると、実環境での悪用に至るまでに一定の時間を要したことになります。

なお、KEV への追加は「現在も悪用が継続している」ことを直接示すものではありません。CISA は、CVE ID が付与され、実環境での悪用について信頼できる証拠があり、明確な修正が存在する脆弱性を、年代を問わず追加対象としています。

CVE-2026-29146 の修正が生んだ回帰

本脆弱性を理解するには、前段にあたる CVE-2026-29146 との関係を押さえる必要があります。

CVE-2026-29146 は、EncryptInterceptor が既定構成でパディングオラクル攻撃に対して脆弱であるという問題でした。影響範囲は広く、11.0.0-M1 から 11.0.18、10.0.0-M1 から 10.1.52、9.0.13 から 9.0.115、8.5.38 から 8.5.100、7.0.100 から 7.0.109 が対象とされています。修正版として提示されたのが 11.0.19、10.1.53、9.0.116 です。

この修正の過程で混入した誤りが、CVE-2026-34486 です。 Apache は次のように説明しています。

参考: Apache Tomcat 11 vulnerabilities（Apache Software Foundation）
“An error in the fix for CVE-2026-29146 allowed the EncryptInterceptor to be bypassed.”
（CVE-2026-29146 の修正における誤りにより、EncryptInterceptor の迂回が可能になった）
https://tomcat.apache.org/security-11.html

ここに、この脆弱性の特徴があります。広範囲に影響するパディングオラクルの脆弱性を修正したバージョンが、そのまま次の脆弱性の対象になっているという構造です。前段の対処としてアップグレードを実施した環境が、結果として今回の対象バージョンに到達している可能性があります。

影響範囲の広さは対照的です。CVE-2026-29146 が 7.0 系から 11.0 系まで長期にわたるバージョンを含んでいたのに対し、CVE-2026-34486 の対象は 3 バージョンに限られます。修正リリースにのみ混入した回帰であるため、当然の帰結といえます。

復号失敗時に処理が継続する仕組み

迂回が成立する理由は、例外処理における制御フローの扱いにあります。

EncryptInterceptor は、クラスターノード間でやり取りされるメッセージを受信した際に復号を試みます。本来であれば、復号に失敗したメッセージは不正なものとして破棄されるべきです。ところが対象バージョンでは、復号失敗時に例外を捕捉してログへ記録したうえで、後続の処理をそのまま継続する実装になっていました。

流れを簡略化すると次のようになります。

メッセージ受信
  ↓
復号を試行
  ↓ 失敗（例外発生）
例外を捕捉してログ出力
  ↓
後続の処理へ進む  ← 本来はここで破棄されるべき

この結果、暗号化されていないメッセージであっても受信側が受け付けてしまい、EncryptInterceptor による保護が実質的に働かない状態になります。セキュリティ分野では、異常時に処理を通してしまう挙動を fail-open と呼びます。本来は fail-closed、すなわち異常時に処理を止める設計が求められる箇所です。

修正版では、復号が成功した場合にのみ後続処理へ進むよう制御フローが改められています。

ここで注意したい点があります。EncryptInterceptor はクラスター通信を保護するために追加する機能であり、既定で有効になっているものではありません。 つまり、通信を暗号化するというセキュリティ上の措置を講じていた環境が、この脆弱性の対象になります。設定を行っていない環境には EncryptInterceptor 自体が存在しないため、この迂回は問題になりません。対策を実施していた側が影響を受けるという点で、判断を誤りやすい脆弱性といえます。

影響を受ける対象バージョンと成立条件

対象かどうかの判断は、バージョンと構成の 2 段階で行います。バージョンが一致していても、構成条件を満たさなければ影響を受けません。

影響は 3 つのバージョンに限定される

CVE レコードの CNA コンテナ（採番元は Apache Software Foundation）では、既定の状態を unaffectedとし、影響を受けるバージョンを個別に列挙する形で記載されています。

範囲指定ではなく、各系列 1 バージョンずつの指定です。前段の CVE-2026-29146 が 7.0 系から 11.0 系まで広範囲を対象としていたのとは対照的で、修正リリースにのみ混入した回帰であることがバージョン指定にも表れています。8.5 系と 7.0 系は、Apache の記録において対象として挙げられていません。

ここで、情報源によって記述が割れている点に触れておきます。一部の解説記事や検証用リポジトリでは「11.0.19 以降」「10.1.53 以降」のように下限を示す範囲表記が用いられていますが、これは Apache の記載と一致しません。 Apache が示しているのは上表の 3 バージョンのみです。

判断が難しいのが 11.0.19 の扱いです。CVE-2026-29146 の修正版として提示されたのは 11.0.19、10.1.53、9.0.116 の 3 つでした。10.1.53 と 9.0.116 はそのまま CVE-2026-34486 の対象になっている一方、11.0 系については 11.0.20 のみが対象として記載されています。この差が生じた理由を、公式の記録から確認することはできませんでした。 11.0.19 を運用している場合、対象である可能性を積極的に否定できる材料がないため、11.0.21 への更新を検討することをおすすめします。

攻撃成立に必要な前提条件

バージョンが一致していても、次の条件が揃わなければ問題は顕在化しません。

• クラスタリングが有効になっていること: server.xmlに <Cluster>要素が定義されている
• EncryptInterceptor が設定されていること: チャネルのインターセプターとして明示的に追加されている
• Tribes のレシーバーポートに到達できること: 攻撃者がクラスター通信用のポートへ接続できる位置にいる
• （コード実行に至る場合）classpath にガジェットチェーンが存在すること

EncryptInterceptor は既定で有効になっている機能ではありません。 Tomcat 9.0.13 で追加されたもので、クラスターノード間でやり取りされるセッションデータを暗号化するために、管理者が明示的に設定する必要があります。したがって、クラスター通信の暗号化という措置を講じていた環境が対象となり、設定していない環境や単一構成の環境は影響を受けません。

4 つ目の条件は、影響の度合いに関わります。復号されていないメッセージが受け付けられた場合、そのメッセージは Java のデシリアライゼーション処理へ渡されます。classpath 上に悪用可能なライブラリの組み合わせが存在すると、コード実行につながる可能性が指摘されています。デシリアライゼーションとガジェットチェーンの一般的な仕組みについては、関連記事『Apache CXF の JNDI 注入と暫定回避策』でも扱っています。

ただし、CISA の SSVC 判定における技術的影響は Total control ではなく Partial control です。 また Apache の分類も「機微データの暗号化の欠如」であり、コード実行を前提とした位置づけにはなっていません。前提条件が揃った場合に限り深刻な影響に至り得る、という理解が実態に近いと考えられます。

自環境が該当するかを確認する手順

確認は、バージョン、クラスター設定、ポートの公開状況の順に進めると効率的です。バージョンが対象外であれば、以降の確認は不要です。

バージョンとクラスター設定の確認

バージョンの確認には、Tomcat の binディレクトリに含まれるスクリプトを使用します。サーバーが停止していても実行できます。

# Linux / macOS
./bin/version.sh

# Windows
bin\version.bat

出力に含まれる Server number:の行が対象の 3 バージョンに一致するかを確認します。catalina.sh versionでも同じ情報が得られます。

アプリケーションに組み込まれた Tomcat や、再パッケージされた環境でスクリプトが見当たらない場合は、catalina.jarから直接確認する方法があります。

java -cp lib/catalina.jar org.apache.catalina.util.ServerInfo

バージョンが一致した場合、次に server.xmlでクラスタリングと EncryptInterceptor の設定を確認します。確認するのは次の 2 点です。

• <Engine>または <Host>配下に <Cluster>要素が存在するか
• <Channel>配下に EncryptInterceptor が定義されているか

該当する記述はおおむね次の形になります。

<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster">
  <Channel className="org.apache.catalina.tribes.group.GroupChannel">
    <Interceptor
      className="org.apache.catalina.tribes.group.interceptors.EncryptInterceptor"
      encryptionKey="..." />
  </Channel>
</Cluster>

<Cluster>要素がコメントアウトされている、あるいは EncryptInterceptor の <Interceptor>要素が存在しない場合、この脆弱性の対象にはなりません。

なお、EncryptInterceptor には既定のアルゴリズムに関する注意点があります。公式リファレンスでは、後方互換性のために AES/CBC/PKCS5Paddingが既定値となっている一方、別のモードの使用が推奨されています。

参考: Apache Tomcat 9 Configuration Reference – The Channel Interceptor object
“it is recommended that AES/GCM/NoPadding is used”
（AES/GCM/NoPadding の使用が推奨される）
https://tomcat.apache.org/tomcat-9.0-doc/config/cluster-interceptor.html

前段の CVE-2026-29146 がパディングオラクルの脆弱性であったことを踏まえると、encryptionAlgorithmを明示せず既定値のまま運用している環境は、この機会にあわせて見直す価値があります。

Tribes レシーバーポートの公開状況の確認

3 つ目の条件である到達可能性を確認します。ここで注意が必要なのは、実際に待ち受けているポート番号が設定値と一致するとは限らない点です。

公式リファレンスによると、Receiver の port属性の既定値は 4000 ですが、autoBind属性の既定値が 100 であるため、ポート競合を避けるために 4000以上 4000 + autoBind未満の範囲で空いているポートへ自動的にバインドされます。つまり、既定構成では 4000 から 4099 のいずれかで待ち受けている可能性があります。 4000 番だけを確認して問題なしと判断すると、実態を取りこぼすおそれがあります。

実際の待ち受け状況は、次のように確認します。

# 待ち受けポートの一覧から該当範囲を抽出
ss -lntp | grep -E ':40[0-9][0-9]'

あわせて確認したいのが、address属性の設定です。既定値は autoで、java.net.InetAddress.getLocalHost().getHostAddress()の結果に解決されます。意図せず業務ネットワーク側のインターフェースにバインドされていないか、出力されたアドレスを確認しておくことをおすすめします。

ポートが確認できたら、そのポートへ到達できる範囲を洗い出します。

• ファイアウォールやセキュリティグループで、クラスターノード間のみに通信が制限されているか
• クラスター通信用のセグメントが、業務セグメントやユーザーセグメントから分離されているか
• クラウド環境の場合、サブネットとルーティングの設定が意図どおりか

クラスター通信のポートを不特定多数から到達可能な位置に置く構成は、本来の設計としても想定されにくいものです。 ここが適切に分離されていれば、対象バージョンであっても実際のリスクは限定的と判断できます。

恒久対処と暫定的な緩和策

対処は修正版へのアップグレードが基本です。クラスター構成であることを逆に活かせば、業務影響を抑えたまま適用できます。

修正版へのアップグレード

Apache は CVE レコードにおいて、次のように更新を推奨しています。

参考: CVE-2026-34486（CVE Program）
“Users are recommended to upgrade to version 11.0.21, 10.1.54 or 9.0.117, which fix the issue.”
（利用者には、本問題を修正する 11.0.21、10.1.54、9.0.117 のいずれかへの更新が推奨される）
https://www.cve.org/CVERecord?id=CVE-2026-34486

修正版と、2026 年 8 月時点で公開されている各系列の最新版は次のとおりです。

修正版以降であれば本脆弱性は解消されますが、その後も別の脆弱性の修正が重ねられているため、系列内の最新版への更新を検討することをおすすめします。

クラスター構成であることから、待機系から順に適用するローリング方式を取れます。適用後の確認では、次の点を見ておくと切り分けが容易になります。

• ノード間でセッションレプリケーションが正常に動作しているか
• クラスターメンバーの検出に関するログにエラーが出ていないか
• インターセプターの順序が維持されているか

3 点目は本脆弱性に固有の注意点です。公式リファレンスでは、TcpFailureDetector を併用する場合、EncryptInterceptor をチェーン内でその前に配置する必要があるとされています。送信側と受信側でチェーンの通過順が逆になるという非対称性があるためで、順序を誤るとメッセージが破損します。設定ファイルを編集する際は、既存の順序を変えないよう注意が必要です。

あわせて、EncryptInterceptor はメッセージのタイムスタンプをリプレイ攻撃対策に利用しており、ノード間の時刻のずれが大きいと正常なメッセージまで拒否される旨が公式に記載されています。アップグレードの前後で時刻同期の状態を確認しておくと、切り分けの手戻りを減らせます。

すぐに更新できない場合のネットワーク面の緩和

期限内に更新できない場合、有効な緩和は到達可能性を断つことに集約されます。

クラスタリングを実際には使用していない場合、server.xmlの <Cluster>要素を無効化することが最も確実です。過去の構成が残ったまま運用されているケースもあるため、セッションレプリケーションの必要性をあらためて確認する価値があります。

クラスタリングを使用している場合、次の順で到達範囲を絞ります。

• ファイアウォールやセキュリティグループで、Tribes のポートへの接続をクラスターノードの IP アドレスのみに限定する
• Receiver の address属性を明示的に指定し、クラスター通信専用のインターフェースへバインド先を固定する
• autoBind属性を 1に設定し、待ち受けポートを port属性の値だけに固定する（既定値の 100 では 4000 から 4099 の範囲で変動し得るため、フィルタリング設計が複雑になります）
• クラスターノード間の通信を専用のセグメントへ分離する

1 点、緩和策として選ばれやすいものの効果が期待できない対応があります。EncryptInterceptor の設定を削除しても緩和にはなりません。 レシーバーがメッセージを受け付ける動作自体は変わらないためで、暗号化の保護が失われる分だけ状況が悪化する可能性があります。設定を残したままネットワーク面で到達範囲を絞る対応が適切です。

BOD 26-04 の 4 変数で評価する

本脆弱性は KEV へ追加されているため、CISA の BOD 26-04 における対応期限の判定材料が揃っています。CVE レコードの CISA-ADP コンテナに記録されている値は次のとおりです。

3 つが確定しているため、残る外部公開の有無だけで対応期限が決まります。

• 外部公開されている場合: 3 日
• 外部公開されていない場合: 14 日

いずれの場合もフォレンジック調査は求められません。 調査が要件となるのは技術的影響が Total control の組み合わせに限られるためで、Partial control と判定されている本脆弱性はこれに該当しません。

実務上の着地は 14 日と考えられます。Tribes のレシーバーポートを不特定多数から到達可能な位置に置く構成は、設計として想定されにくいためです。ただし、外部公開されていなくても、KEV への掲載によって 14 日という枠が課される点は押さえておく必要があります。閉じたネットワークにあるという理由で無期限に先送りできる階層には入りません。

4 変数の定義や 16 通りの組み合わせの全体像については、関連記事『BOD 26-04 とは｜KEV と外部公開で決まる対応期限の読み方』で整理しています。日本の組織に義務は生じませんが、対応期限を自組織で決める際の枠組みとして参考になります。

まとめ

CVE-2026-34486 は、Apache Tomcat の EncryptInterceptor が迂回され得る脆弱性で、前段の CVE-2026-29146 に対する修正の誤りとして混入しました。影響を受けるのは 11.0.20、10.1.53、9.0.116 の 3 バージョンのみで、さらにクラスタリングと EncryptInterceptor を設定している環境に限られます。対処は修正版へのアップグレードで、すぐに更新できない場合は Tribes ポートへの到達範囲を絞ることが緩和につながります。

• 対象は 11.0.20、10.1.53、9.0.116 の 3 バージョン
• CVE-2026-29146 の修正版がそのまま対象になる構造
• クラスタリング未使用または単一構成なら影響を受けない
• 暗号化を設定していた環境のみが対象となる点に注意
• 恒久対処は 11.0.21、10.1.54、9.0.117 以降への更新
• 既定構成では待ち受けポートが 4000 から 4099 で変動し得る
• KEV 掲載により BOD 26-04 では最長 14 日の階層に入る

以上、最後までお読みいただきありがとうございました。