Tomcatサンプルアプリに脆弱性、修正版は未公開

脆弱性・脅威情報

【更新 2026-08-02】本記事を見直し、修正しました。主な修正点：JVNの掲載内容についての説明を実際の記載（対策方法の欄は「Apache Tomcatのアドバイザリを参照してください」で、修正版は詳細情報・ベンダ情報の欄に列挙）に訂正。あわせて2026年8月2日時点でも修正版11.0.25／10.1.58／9.0.121が未リリースであることを一次情報で確認し、追記しました。

2026年7月28日、Apache Tomcatに同梱されるサンプルアプリケーション（examples webapp）のWebSocketチャット例にサービス運用妨害（DoS）の脆弱性 CVE-2026-66299 が公表されました。認証も利用者の操作も不要で、遠隔からTomcatプロセスをメモリ枯渇に追い込める内容です。

ただし本件には、いつもの脆弱性対応と違う点が2つあります。ひとつは、修正版（11.0.25／10.1.58／9.0.121）が執筆時点（2026年8月1日）でまだリリースされていないこと。もうひとつは、対象がTomcat本体ではなく「本番環境からは消しておくべき」とされてきたサンプルアプリであることです。結果として、今日打てる手は「examplesを削除する」の一択になります。

この記事でわかること

  • CVE-2026-66299の対象範囲と、修正版がまだ出ていないという事実
  • 自社のTomcatが該当するかを5分で判定する具体的な手順
  • なぜメモリが枯渇するのか（修正コミットから読み解く仕組み）
  • 開発元が「低」、NVDが「7.5（重要）」と評価が割れている理由と、どちらで判断すべきか

何が起きたのか

Apache Software Foundation（ASF）が公表したアドバイザリによると、WebSocketチャットのサンプルが未送信メッセージ用に上限のないバッファを持っており、悪意ある低速クライアントがバッファを際限なく成長させることで、メモリを使い果たしTomcatプロセスを停止させられます。

項目 内容
CVE番号 CVE-2026-66299
種別 CWE-400（リソースの無制限消費）
対象 Tomcat同梱のサンプルアプリ（examples）内のWebSocketチャット例
影響を受ける版 11.0.0-M20〜11.0.24／10.1.24〜10.1.57／9.0.89〜9.0.120
修正版 11.0.25／10.1.58／9.0.121（いずれも執筆時点で未リリース）
ASFの深刻度評価 Low（低）
NVD掲載のCVSS 7.5 HIGH（CISA-ADP評価、CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H）
報告日／公表日 2026年7月13日／2026年7月28日
回避策 examples webappの削除（ASFが明記）

影響範囲の下限にあたる9.0.89・11.0.0-M20・10.1.24は、いずれも2024年5月に公開された版です（順に5月7日・5月8日・5月13日）。つまりこの状態は2年以上続いていたことになります。

修正版はいつ出るのか

Tomcat公式サイトの新着情報で確認できる最新リリースは、11.0.24（2026年7月8日）、10.1.57および9.0.120（いずれも2026年7月7日）です。各系列のセキュリティページも、修正版の項目に「not yet released（未リリース）」と表示されています。JVN（JVNVU#99139115）も、詳細情報とベンダ情報の欄に「Fixed in Apache Tomcat 11.0.25」「同 10.1.58」「同 9.0.121」を並べています（対策方法の欄は「Apache Tomcatのアドバイザリを参照してください」）。しかしそのバージョンはまだ入手できません。この点を読み違えると、対応チケットが「修正版待ち」のまま塩漬けになります。

【2026年8月2日 追記】本日時点でも状況は変わっていません。各系列のセキュリティページは「not yet released」のままで、配布アーカイブ（archive.apache.org）にも11.0.25／10.1.58／9.0.121は現れておらず、開発元のアナウンス用メーリングリストにも本件公表後の新規リリース告知はありません。

自社は対象か（5分で判定する）

該当判定はバージョン番号ではなく、examplesが配備されているかどうかで決まります。バージョンが対象範囲に入っていても、examplesを消してあれば影響を受けません。逆にバージョンだけ見て「対象」と判定しても、実態と合っているとは限りません。次の3つを確認してください。

  1. ファイルの有無を見る：ls $CATALINA_BASE/webapps/ を実行し、examples ディレクトリがあるか確認します。$CATALINA_BASE を分けていない構成なら $CATALINA_HOME/webapps/ を見ます。
  2. HTTPで叩いてみる：curl -I http://localhost:8080/examples/websocket/chat.xhtml が200を返せば該当します。チャットのWebSocketエンドポイントは /examples/websocket/chat です。
  3. パッケージ導入なら別パッケージを確認：Debian／Ubuntu系ではexamplesが本体と別パッケージになっています（例：Ubuntu 24.04 LTSの tomcat10-examples）。dpkg -l | grep tomcat で導入有無を確認します。本体だけを入れていればexamplesは配備されません。

あわせて、次の2つは原則として対象外です。

  • Spring Boot等の組み込みTomcat：examplesは同梱されないため該当しません。
  • Docker Hubの公式tomcatイメージ：イメージのビルド時に webapps を webapps.dist へ退避し、空の webapps を作る処理が入っているため、既定では何も配備されません。ただし、管理画面やサンプルを使いたくて webapps.dist の中身を webapps に戻す運用は現場でよく見かけます。戻していれば対象になります。

なぜメモリが枯渇するのか

修正コミットを見ると、原因は素朴な作りにあります。チャットのサーバ側クラスは、あるクライアントへの送信が完了していない間に次のメッセージが来ると、それを messageBacklog（キュー）に積んで戻る、という処理になっていました。このキューに上限がなかったため、受信が極端に遅いクライアントに対しては、積まれる一方で減らないという状態が成立します。

実務上厄介なのは、チャットが全接続へのブロードキャストである点です。攻撃者は受信をわざと遅らせたクライアントとして接続したうえで、別の接続から大量にメッセージを投稿すれば、自分のバックログを一方的に膨らませられます。攻撃の入力側と滞留側の両方を攻撃者が握れる構造で、特別な権限は要りません。

修正では、バックログの上限を10件に制限し、超過した場合はキューを破棄して「低速クライアントのためN件をスキップした」旨のメッセージに置き換えるようになりました。つまりチャット機能としての正常動作を捨てて、資源の上限を優先する設計変更です。

この「遅い受信者が資源を溜め込む」構造は、HTTP/2のフロー制御を悪用したDoSと同型です。プロトコルや実装が違っても、受信側の都合で送信が滞る仕組みには同じ落とし穴があります。

評価が割れている（Low と 7.5 High）

ASFは本件を「Low（低）」としていますが、NVDにはCISA-ADPが付与した7.5 HIGHが掲載されています。JVNにはCVSSの記載自体がありません。

ベクタを事実と突き合わせると、CISA-ADP側の AV:N/AC:L/PR:N/UI:N（ネットワーク経由・条件が容易・権限不要・利用者操作不要）と A:H（可用性への影響が高い）は、脆弱性の内容と矛盾しません。Tomcatプロセスが落ちるのは事実だからです。

では差はどこから来るのか。ASFの評価は「examplesは本番環境に置かれていないはずだ」という前提に立っています。アドバイザリにも、セキュリティガイダンスに従ってexamplesを削除している利用者は影響を受けない、と明記されています。一方でCVSSは構成の推奨/非推奨を勘案しません。

したがって読者にとっての実質は、スコアの中間を取ることではなく二値の判定です。

  • examplesを削除済み　→　影響なし（対応不要）
  • examplesが残っている　→　認証不要でプロセスを落とされる状態が2年以上続いていた

脆弱性管理台帳に「7.5だから対応」「Lowだから見送り」と入力する運用では、この二値がどちらも表現できません。判断すべきはスコアではなく配備状態です。6月に公開されたTomcatの複数脆弱性でも、サンプルアプリの数当てゲームのXSS（CVE-2026-50229）が含まれていました。1か月あまりの間に、同じexamples webappから2件目が出たことになります。

現場目線：なぜサンプルアプリは消えないのか

「サンプルアプリは消しましょう」は、Tomcatの公式ドキュメント（Security Considerations）が以前から明記している基本中の基本です。examplesについては、既知の脆弱性がなかった時期であっても、受信したCookieを全部表示したり新しいCookieを設定できたりする機能が、他のアプリの脆弱性と組み合わされて情報を取られる余地になる、としてセキュリティを気にする環境からは常に削除すべきとされています。

それでも残り続けるのには、現場なりの理由があります。動作確認のために立てた検証機がそのまま本番に昇格する。導入時に外部ベンダーが構築し、削除手順が引き継がれていない。コンテナ化のときに「管理画面が使えないと困る」と言われて webapps.dist を戻す。どれも悪意はなく、その場では合理的な判断です。

そして厄介なのは、資産管理台帳に記録されるのは「Tomcat 10.1.55」というバージョンだけで、examplesを消したかどうかは記録されないことです。消してあることを台帳で証明できない以上、「対応不要」と判定する根拠を毎回実機で取り直すしかありません。ここは、外部からの指摘で初めて公開状態に気づいた事例と同じで、自分の側の記録だけを見ていると穴が見えない領域です。

限られた人員で数十台のアプリケーションサーバを見ていると、こうした「昔の誰かが入れたまま残っているもの」まで手が回らないのが実情だと思います。今回のように全台に同じ1コマンドで確認できるネタが出たときにまとめて棚卸ししてしまうのが、現実的な進め方だと感じます。

情シスはどうすべきか

本件に限れば、やることは明快です。

  1. 全Tomcatで webapps/examples の有無を確認し、あれば削除する（停止して削除、または配備解除）。修正版を待つ必要はありません。削除すればCVE-2026-66299の影響は消えます。
  2. ついでに docs、不要なら ROOT、使っていなければ manager／host-manager も外す。公式ドキュメントは、不要なアプリを残さないこと自体を推奨しています。
  3. 修正版11.0.25／10.1.58／9.0.121が出たら通常の更新サイクルで適用する（本件以外の修正も入るため）。
  4. 削除した事実を構成情報として記録に残す。次に同じ種類の脆弱性が出たときの判定コストが下がります。

より一般的な考え方の整理には、公的機関の指針を起点にするのが確実です。運用中のウェブサイト・ウェブアプリケーションで「不要な機能・不要なファイルを置かない」という原則を含め、体系的にまとまっているのがIPAの安全なウェブサイトの作り方です。社内標準や委託先への要件に落とし込む際の下敷きに使えます。組織全体の枠組みから見直すなら中小企業の情報セキュリティ対策ガイドラインも参照してください。

あわせて、外部ベンダーに構築を委託する場合は「初期状態の不要コンポーネントを削除すること」を検収項目に入れる、という地道な作り込みが効きます。技術的な対処より、こうした要件化と引き継ぎのほうが再発防止には効くというのが実感です。

まとめ

  • CVE-2026-66299はTomcat同梱のサンプルアプリ（examples）のWebSocketチャット例の問題で、認証不要でプロセスをメモリ枯渇させられる。影響範囲は11.0.0-M20〜11.0.24／10.1.24〜10.1.57／9.0.89〜9.0.120。
  • 修正版11.0.25／10.1.58／9.0.121は執筆時点（2026年8月1日）で未リリース。待つのではなく、examplesを削除すれば影響は消える。判定は webapps/examples の有無で行う。
  • ASFはLow、NVD掲載のCISA-ADP評価は7.5 HIGHと割れているが、実質は「消してあれば影響なし／残っていれば認証不要でDoS可能」の二値。スコアではなく配備状態で判断する。

関連記事

出典

タイトルとURLをコピーしました