Tomcat CVE-2026-34486が実際の攻撃に 対象は3つの版だけ、期限8月7日

【2026年8月5日 追記】Tomcatの別の脆弱性CVE-2026-34486が実際の攻撃に ― 期限は8月7日

米CISAは2026年8月4日、Apache TomcatのCVE-2026-34486を「実際に攻撃されている脆弱性リスト（KEV）」へ追加しました。米連邦機関に課された是正期限は8月7日です。これは本記事が扱う3件とは別の脆弱性で、2026年4月9日に公表されていたものです。数字だけで慌てなくてよい、という本記事の見立ては変わりませんが、「実際に攻撃されているかどうかを見る」という判断のはっきりした実例が出たので、経緯を補っておきます。

影響するのは11.0.20・10.1.53・9.0.116 のちょうど3つの版だけです。修正は 11.0.21・10.1.54・9.0.117 に入っており、本記事が案内している定例更新先（9.0.121／10.1.58／11.0.25）まで上げれば、この件もあわせて片付きます。1台構成で動かしている環境には、そもそも関係がありません。

中身は、複数台構成（クラスタ）でログイン状態などをやり取りするときに、その通信を暗号化する部品「EncryptInterceptor」を素通りさせられてしまう、というものです。もとをたどると別の脆弱性CVE-2026-29146の修正が引き金で、直した結果として暗号化の効かない経路が残りました。奪われるのは流れている通信の中身、つまり機密性で、CVSSの内訳も機密性だけが「高」、書き換えやサービス停止は含まれません。危険度の数字は7.5——本記事で「慌てなくてよい」と説明したCVE-2026-66299と同じ値です。同じ7.5でも、実際に攻撃されているかどうかで扱いはまったく変わります。

その差は、悪用の起きやすさを見積もるEPSSという指標にも出ています。2026年8月4日時点で、CVE-2026-34486は0.426（全CVEの上位1.5%に入る水準）、これに対しCVE-2026-66299は0.003、CVE-2026-59083は0.004にとどまります。数字の高さではなく、こうした実態の指標を見るべきだ、というのが本記事で伝えたかったことでした。なお、実証コードを名乗る公開リポジトリも現れていますが、そこで掲げられている「認証なしの遠隔コード実行」という説明は、NVDの評価（失われるのは通信の中身だけ）とは一致しません。出所の不確かな実証コードをそのまま信じないでください。

確認すべきは、Tomcatをクラスタ構成で動かし、設定ファイル（server.xml）でEncryptInterceptorを使っているかどうかです。当てはまるなら、定例を待たずに修正版へ上げてください。当てはまらない大多数の環境では、これまでどおり定例更新で問題ありません。攻撃されている脆弱性の最新状況はCISA KEV一覧（日本語版）でも追えます。

社内のセキュリティ検査ツールやニュースで「Apache Tomcatにまた脆弱性」と表示され、身構えた方もいるかもしれません。結論から言うと、今回もあわてて緊急対応に走る必要はありません。2026年7月末に新しく公表されたCVE-2026-66299（日本ではJVNVU99139115として公表）は、検査ツールでは「危険度7.5」と出ることがありますが、開発元であるApache自身の評価は「低（Low）」です。しかも影響するのは、本番環境ではふつう置かない「サンプル（お試し用）アプリ」だけ。大多数の利用者には、実質的な関係がありません。

Apache Tomcatは、Javaで作られたWebシステムを動かすためのソフトで、日本の企業システムの裏側で広く使われています。それだけに「Critical（緊急）」「危険度7.5」といった表示が出ると、現場は一斉に警戒モードに入りがちです。ところが、その数字と、開発元の「低」という評価は、たびたび大きく食い違います。この記事では、まず最新のCVE-2026-66299を取り上げ、続けて7月中旬に公表されたCVE-2026-59083・CVE-2026-59084もあわせて、なぜ数字が食い違うのか、自分の環境は本当に影響を受けるのか、そして落ち着いて何をすればいいのかを、順を追って整理します。

【最新】CVE-2026-66299：WebSocketチャットの「サンプル」アプリで起きる停止攻撃

2026年7月28日、Apache TomcatにDoS（サービス運用妨害。サーバーを止めてしまう攻撃）の脆弱性が公表され、日本の脆弱性情報ポータルJVN（JVNVU99139115）でも「Apache TomcatにおけるDoSの脆弱性」として案内されました。ここで最も大事な事実を先に書きます。問題があるのは、Tomcatに同梱されている「WebSocketチャットのサンプルアプリ」だけです。これは開発者が動作を試すための"お試し用"のプログラムで、Apacheの公式ガイドは以前から「本番ではサンプル（examples）を削除するように」と案内しています。その通りにサンプルを外している環境は、そもそも今回の対象外です。

CVE-2026-66299：WebSocketチャットのサンプルアプリでのリソース枯渇によるDoS

Tomcatには、ブラウザとサーバーが双方向でやり取りする「WebSocket」の使い方を示すために、簡単なチャットのサンプルアプリが同梱されています。今回の問題は、このサンプルの作りにありました。チャットで送るメッセージのうち、まだ相手に届けきれていない分を一時的にためておく置き場（バッファ）に、上限が設けられていなかったのです。修正コミットでも、この置き場に上限を設ける形で直されています。

わざと受信を遅らせる「遅いクライアント」が接続すると、届けきれないメッセージが延々とたまり続け、サーバーのメモリを食いつぶして、最後にはTomcatのプロセスそのものが落ちてしまう――これがCVE-2026-66299の中身です。分類は「リソースの使い過ぎ（CWE-400）」で、Apacheには2026年7月13日に報告され、7月28日に公表されました。データを盗み出したり、サーバーを乗っ取ったりする類の脆弱性ではなく、あくまで「止められる」タイプです。そして繰り返しになりますが、成立するのはお試し用のサンプルアプリを本番に残したまま外部に見せている場合に限られます。開発元Apacheの深刻度評価は「低」です。

攻撃者像と狙い ― 誰が、何のために悪用するのか

狙われるのは、動作確認用のサンプルアプリを消し忘れたまま、インターネットに公開されているTomcatサーバーです。攻撃者からすれば、特別なIDやパスワードは不要で、外からそのサンプルにつなげさえすればよいため、公開サーバーを機械的に探し回る相手にとっては手軽な標的になります。

攻撃者がやることは単純です。チャットのサンプルに接続したうえで、わざとメッセージの受け取りを遅らせ、届けきれない分をサーバー側にためこませ続けて、メモリをじわじわ食い尽くす。金銭や情報を直接奪うのではなく、サービスを止めること自体が目的の嫌がらせ・妨害に向いた手口です。

その結果として起きるのは、Tomcatが動かなくなり、その上で動いていたWebサイトや業務システム、APIが応答しなくなることです。ただし、サンプルを削除している運用（＝Apacheが以前から推奨している運用）であれば、この被害は最初から発生しません。裏を返せば、CVE-2026-66299は「サンプルを消す」という基本を守れているかを点検するきっかけと捉えるのが実用的です。

影響を受けるバージョンと修正版は次の通りです。この脆弱性は途中のバージョンで追加された機能に起因するため、9.0.89より前や8.5系以前は、そもそも対象外という点が、後述の7月中旬の2件とは異なります。

やることは2つのどちらかです。ひとつは、本番に残っているサンプル（examples）アプリを削除すること。これだけで今回の穴はふさがり、しかもApacheが以前から推奨している運用そのものです。もうひとつは、次の定例メンテナンスで修正版（9.0.121／10.1.58／11.0.25）へ更新すること。どちらもサービスを止めての緊急対応までは求められていません。

なぜ「7.5」「9.1」と開発元の「低」が食い違うのか

ここが、Tomcatの脆弱性ニュースに共通する、いちばん大事なところです。同じ脆弱性なのに、片や「7.5」「9.1」と高い数字、片や「低」。この差は、スコアを付けている主体と方法が違うことから生まれています。

脆弱性の深刻度は、CVSS（共通脆弱性評価システム）という国際的なものさしで0.0〜10.0の数値に表されます。今回のCVE-2026-66299に付いた「7.5」は、米政府側の組織CISA-ADPが付けた値で、サーバーが「止まる」という影響（可用性）だけを最大に見積もった暫定的なスコアです。7月中旬の2件で出回った「9.1」も同様に、脆弱性データベース（NVD）に機械的に付けられた自動補完のスコアでした。いずれも、詳しい前提条件を一つひとつ確かめる前に「最悪の場合」を想定して付けられるため、実際の悪用しやすさより高めに出やすい性質があります。

一方、「低」という評価は、この脆弱性を最もよく知る開発元Apache（採番元）が、成立条件や実際の影響を踏まえて付けたものです。CVE-2026-66299でいえば、「そもそも本番には置かないはずのサンプルアプリの話」という前提が、Apacheの「低」にはきちんと織り込まれています。多くの商用スキャナは自動補完値やCISA-ADPの値をそのまま取り込んで表示するため、社内の検査で「7.5」「Critical」と警報が鳴っても、中身は緊急とは限らない、ということが起こります。数字だけを見て慌てるのではなく、採番元（開発元）の評価と、実際に攻撃されているかどうかを合わせて見るのが、正しい向き合い方です。米政府CISAが公開する実際に攻撃されている脆弱性のリスト（KEV）にも、今回の3件はいずれも登録されていません（ただし、同じTomcatでも別の脆弱性CVE-2026-34486が2026年8月4日にKEVへ登録されました。冒頭の追記を参照してください）。

先に公表された2件（CVE-2026-59083・CVE-2026-59084）

今回の最新CVEの前、2026年7月14日にも、Apache Tomcatに2件の脆弱性が公表されています。日本のJVN（JVNVU95286373）でも「Apache Tomcatにおける複数の脆弱性」として案内されました。こちらも開発元Apacheの評価はいずれも「低」で、実際に攻撃された報告はありません。1件はURLの解釈のずれによるアクセス制御の回避、もう1件はそもそもプログラムの欠陥ではなく、設定手順の説明（ドキュメント）が不十分だったという問題です。実証コード（PoC）の公開も、KEVへの登録も確認されていません。

CVE-2026-59083：URLの解釈のずれでアクセス制御を回避しうる

Tomcatには、アクセスされたURLを内部で書き換える「RewriteValve」という機能があります。今回の問題は、書き換えたあとのURLに含まれる「+（プラス）」記号を、Tomcatが誤って半角スペースに解釈してしまう場合があった点です。この解釈のずれを利用すると、本来はアクセス制御（セキュリティ制約）で守られているはずのパスに、条件次第で到達できてしまう可能性があります。ただし、これはサーバーを乗っ取るRCE（遠隔コード実行）ではなく、成立するのも「RewriteValveを使い、かつ特定の設定になっている」環境に限られます。分類はURLエンコードの取り扱い不備（CWE-177）で、Tomcatのセキュリティチームが自ら発見しました。開発元Apacheの深刻度評価は「低」で、修正版は11.0.24／10.1.57／9.0.120です。

CVE-2026-59084：暗号化設定の説明（ドキュメント）不足

2件目は、複数のTomcatを束ねて動かす「クラスタ」構成で、サーバー間の通信を暗号化する「EncryptInterceptor」という仕組みに関するものです。ここで重要なのは、これはプログラムの欠陥ではなく、安全に設定するための要件がドキュメントに十分書かれていなかった、という「説明不足」の問題だという点です。分類も、技術文書の不備（CWE-1059）です。実際に影響が出るとすれば、この暗号化を誤った設定のまま使っていた組織で、期待した保護が効いていなかったかもしれない、という限られたケースです。こちらも開発元評価は「低」で、修正版は同じく11.0.24／10.1.57／9.0.120です。ドキュメントを直しただけの案件にも自動補完では9.1という高い数字が付いており、数字と実態のずれが極端に表れた例と言えます。

自分の環境は影響を受けるのか

落ち着いて確認しましょう。ここまでの3件が実際に関係するのは、次のような環境に限られます。当てはまらなければ、実質的な影響はほとんどありません。

修正版は、サポートが続いている系統ごとに用意されています。3件すべてを直したい場合の目安は、下の表の通りです。CVE-2026-66299だけは、機能が追加される前の古いバージョン（9.0.89より前・8.5系以前）が対象外である一方、7月中旬の2件はサポート系統の広い範囲が対象になります。なお、Tomcat 8.5系（および7.0系）はすでにサポートが終了しているため、これらを使っている場合は、今回の件に関わらずサポートの続く9.0系以降へ移行するのが本筋です。

3件をまとめて解消するなら、各系統の新しい方の修正版（9.0.121／10.1.58／11.0.25）へ上げれば、7月中旬の2件も含めて一度に対応できます。

では何をすればいいのか

対応はシンプルです。次回の定例メンテナンスのタイミングで、サポート系統の修正版（9.0.121／10.1.58／11.0.25）へ更新する。これで3件まとめて片付きます。今すぐサービスを止めて緊急パッチを当てる、といった対応は求められていません。あわせて、本番環境に残っているサンプル（examples）アプリがあれば削除しておくと、CVE-2026-66299は更新を待たずにその場で解消でき、Apacheが以前から推奨している運用にもなります。前の章の表で「確認対象」に当てはまった環境（RewriteValveの利用、クラスタでの暗号化通信）は、更新にあわせて設定を見直しておくと安心です。

今回いちばん持ち帰ってほしいのは、スキャナが出す「7.5」「Critical」の一言だけで判断しないという姿勢です。数字が高くても、実際に悪用されているか（KEVへの登録の有無）、悪用の起きやすさ（EPSSという指標）、そして採番元の評価まで合わせて見れば、本当に急ぐべきか、定例で足りるのかが見えてきます。Apache関連では、同じく評価が過熱しやすい話題として、AIが発見したHTTP/2の停止攻撃や、ログイン不要で悪用されるApache MINAの脆弱性のように、実際の深刻度は案件ごとに大きく異なります。一件ずつ、数字の裏側まで確かめる習慣が、無駄な火消しと本当の緊急の見落とし、どちらも防ぎます。

よくある質問

Q. CVE-2026-66299が「危険度7.5」と出ました。すぐ止めて対応すべきですか。

A. 緊急停止までは不要です。7.5はCISA-ADPが「止まる」影響だけを大きく見積もった値で、採番元Apacheの評価は「低」、実際の悪用も確認されていません。しかも影響するのは、本番ではふつう置かないサンプルアプリだけです。本番からサンプル（examples）を削除するか、次のメンテナンスで9.0.121／10.1.58／11.0.25へ更新すれば十分です。

Q. サンプルアプリを消していれば、CVE-2026-66299は関係ないのですか。

A. その通りです。今回の穴はTomcat同梱のWebSocketチャットのサンプル（examples）に固有のもので、Apacheも以前から本番での削除を推奨しています。サンプルを外している環境は、そもそも今回の対象外です。まだ残っている場合は、この機会に削除しておくとよいでしょう。

Q. なぜ開発元とスキャナで深刻度が違うのですか。

A. スキャナが表示するのは、脆弱性データベースやCISA-ADPが機械的に付けた「最悪の場合」寄りの値であることが多いためです。採番元（開発元）は成立条件や実際の影響を踏まえて評価するため、より実態に近くなります。数字が食い違うときは、採番元の評価と実際の悪用状況を優先して判断してください。

Q. うちのTomcatは8.5系です。どうすれば。

A. Tomcat 8.5系はすでにサポートが終了しており、今後は新しい修正が提供されません。なお、CVE-2026-66299については8.5系はそもそも対象外ですが、7月中旬の2件を含め、サポート切れのまま本番で使い続けること自体がより大きなリスクです。サポートの続く9.0系以降への移行を計画してください。

まとめ

Apache Tomcatに新しく公表されたCVE-2026-66299は、スキャナで「危険度7.5」と表示されることがありますが、開発元Apacheの評価は「低」で、実際に攻撃された報告もありません。影響するのは、本番ではふつう置かないWebSocketチャットの「サンプルアプリ」だけで、そこに上限のない置き場があり、遅い接続でメモリを食いつぶして止められる、という内容です。サンプルを削除していれば、そもそも関係ありません。7月中旬のCVE-2026-59083・CVE-2026-59084も同様に評価は「低」で、緊急でサービスを止めて対応する類のものではありません。

やるべきことは、定例のタイミングで9.0.121／10.1.58／11.0.25へ更新すること、本番に残っているサンプルアプリを削除すること、そしてRewriteValveやクラスタ暗号化を使っている環境は設定を確認すること。それで十分です。今回の一連の件は、「7.5」「Critical」という表示に振り回されず、採番元の評価・実際の悪用状況・悪用のしやすさまで見て判断するという、脆弱性対応の基本を改めて思い出させてくれる事例でもあります。

参照元

• ▸JVN - JVNVU99139115 Apache TomcatにおけるDoSの脆弱性（CVE-2026-66299）
• ▸NVD - CVE-2026-66299
• ▸JVN - JVNVU95286373 Apache Tomcatにおける複数の脆弱性
• ▸NVD - CVE-2026-59083
• ▸NVD - CVE-2026-59084
• ▸Apache Tomcat - Security（公式・深刻度評価）