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

【2026年8月23日 追記】更新先は10.1.59です ― 10.1.58は配布されていません

本記事はこれまで、10.1系の更新先を10.1.58と案内していました。これは誤りです。10.1.58は一般配布されていません。ダウンロードページにもアーカイブにも存在せず、探しても見つかりません。10.1系の更新先は10.1.59です。

経緯はこうです。Apacheの公式セキュリティ情報は、いまも「10.1.58で修正」と書いています。ところが10.1.58は開発途中で番号だけが進み、実際に配布されたのは次の10.1.59でした。Tomcatでは、リリース前の確認で問題が見つかった版が飛ばされることが時々あります。公式の表記が「10.1.58で修正、ただし未リリース」のまま止まっているため、そこだけを見ると存在しないバージョンを探すことになります。

この更新には、設定を変える必要のある変更が入っています

8月の3本には、本記事で扱っているEncryptInterceptorそのものの仕様変更が含まれています。Apacheはこれを「破壊的変更（breaking change）」と明記しました。クラスタ構成でEncryptInterceptorを使っている環境、つまりCVE-2026-34486の対象そのものに直接効きます。

変わったのは、通信を暗号化するときの既定の方式です。これまでの AES/CBC/PKCS5Padding から AES/GCM/NoPadding になりました。CBCという方式は、暗号文を少しずつ書き換えながら反応を見ることで中身を推測できる弱点が知られています。今回の一連の問題の出発点だったCVE-2026-29146も、まさにその型でした。個別の穴をふさぐのではなく、弱点のある方式を既定から外したということです。

実務上の注意はひとつだけですが、重要です。暗号化の方式が変わるため、新旧のバージョンが混在したクラスタは通信できなくなります。1台ずつ順番に更新していく手順を取っている場合、途中でノード間の通信が止まります。全ノードを同時に更新するか、更新中は encryptionAlgorithm に従来の値を明示しておいて、全台が上がりきってから外してください。設定ファイルで方式を明示的に指定している環境は、そのまま従来の動作を続けます。

あわせて、Apacheは公式ドキュメントに「一部の対応方式には安全上の弱点がある」ことと、「なりすまし対策（replay protection）が有効なのは、暗号文を改ざんしにくい方式に限られる」ことを明記しました。EncryptInterceptorを使い続けるなら、設定で方式を固定していないか一度確認しておく価値があります。

なお、この記事のこれまでの結論は変わりません。CVE-2026-34486の対象は11.0.20・10.1.53・9.0.116のちょうど3つの版だけで、緊急停止は要りません。1台構成の環境と、クラスタでもEncryptInterceptorを使っていない環境には関係がない、という点も同じです。

【2026年8月21日 追記】CVE-2026-34486で実際に乗っ取られた台数がわかりました ― 2台

8月5日の追記の時点では、CISAが「実際に攻撃されている」と判断した根拠が公表されていませんでした。その後、根拠にあたる調査報告が2本出ています。読んだ結論を先に書きます。攻撃は実在しますが、規模は小さく、成立の条件も限られています。本記事の見立ては変わりません。

1本目は、脅威情報企業SOCRadarが2026年7月31日に公開したSNOWLIGHTと呼ばれる攻撃活動の報告です。CISAはこの報告をCVE-2026-34486の登録情報に参照先として添えており、KEV入りの直接の根拠はこちらと見られます。数字はこうです。

時期は2026年4月24日から29日、標的は台湾の官公庁・医療・教育です。攻撃者は公開されている実証コードとysoserialという道具を組み合わせ、ポート4000へ一斉に投げていました。日本の組織が狙われたという記載はありません。

2本目は、パロアルトネットワークスのUnit 42が7月30日に公開したAIに攻撃を自動実行させた事例の報告です。中国語話者の攻撃者が生成AIを組み込んだ道具で460以上の標的を攻撃したというもので、そのうちTomcatは9台。ただしUnit 42の記述は「試みた（attempts）」であり、Tomcatについて成功したとは書いていません。同社が成功を確認したのは別製品です。「AIが460台を攻撃、Tomcatも被害」という形で伝わることがありますが、Tomcatに関しては成功例として数えられていません。

「認証なしの遠隔コード実行」という説明は、いまも裏付けがありません

8月5日の追記で、実証コードを名乗るリポジトリの「認証なしの遠隔コード実行」という説明はNVDの評価と一致しない、と書きました。その後も、開発元Apacheも米NVDも評価を変えていません。

• —NVDの危険度は7.5のまま。内訳も機密性だけが「高」で、書き換え・サービス停止はいずれも「なし」（I:N/A:N）
• —Apache自身の深刻度は「Important」のまま。同社の説明文に「遠隔コード実行」の語は一度も出てきません
• —CISAのKEV登録文も「暗号化の欠落」であり、遠隔コード実行とは書いていません

実際に乗っ取りまで至るには、4つの条件が同時にそろう必要があります。複数台構成（Tribesクラスタ）が有効であること、EncryptInterceptorが実際に組み込まれていること、クラスタ間の受信口が攻撃者から届く位置にあること、そして悪用可能な部品がJavaの読み込み対象に入っていること。台湾の事例で乗っ取りが37台中2台にとどまったのは、この条件の厳しさを示しています。

悪用の起きやすさの指標は上がり、そのあと止まりました

8月5日の追記では、EPSS（悪用の起きやすさを見積もる指標）を0.426と書きました。その後8月5日に0.812へ跳ね上がり、8月11日以降は0.829（全CVEの上位0.4%）で止まったまま、8月20日時点まで10日間まったく動いていません。本記事が扱う他の3件は、いずれも0.005前後で変わりません。

日本語の公的な注意喚起は、いまも1件も出ていません

ここは知っておいていただきたい点です。本記事が扱う3件は、いずれもJVN（日本の脆弱性情報ポータル）で案内が出ています。ところがCVE-2026-34486については、JVN・JVN iPedia・JPCERT/CC・IPAのいずれにも案内がありません。KEVに載り、実際に乗っ取りが確認されている側だけが抜けている状態です。

つまり日本語の公的情報だけを見て運用していると、この件は目に入りません。社内の脆弱性管理でJVNを一次情報にしている場合は、この抜けを前提に見てください。

やることは変わりません

対象は11.0.20・10.1.53・9.0.116 のちょうど3つの版だけです。本記事が案内している9.0.121／10.1.59／11.0.25へ上げれば、この件もあわせて片付きます。1台構成の環境、クラスタでもEncryptInterceptorを使っていない環境には関係がありません。

なお、Linuxのディストリビューションを使っている場合は、そもそも対象外のことが多いです。Debianは「該当なし」と明記しています。問題の原因になった修正を、Debianはそもそも取り込んでいなかったためです。Ubuntu・Amazon Linuxも同様に「該当なし」と回答しています。攻撃されている脆弱性の最新状況はCISA KEV一覧（日本語版）でも追えます。

【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.59／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.59／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.59／11.0.25）へ上げれば、7月中旬の2件も含めて一度に対応できます。

では何をすればいいのか

対応はシンプルです。次回の定例メンテナンスのタイミングで、サポート系統の修正版（9.0.121／10.1.59／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.59／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.59／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（公式・深刻度評価）