Apache Tomcatに複数の脆弱性、認可バイパスに注意

Apache Tomcatに複数の脆弱性、認可バイパスに注意 脆弱性・脅威情報

【更新 2026-07-02】本記事を見直しました。主な変更点:同じ2026年6月29日に公表された7件目のCVE(CVE-2026-55957/JNDIRealmの認証バイパス、Important)を「何が公開されたのか」に追記しました。また、報告日(6月15日)が公式情報で確認できないため、一部に要確認の注記を追加しています(本文の事実関係・論旨・6件の脆弱性に関する記述は変更していません)。

Apache Software Foundationは2026年6月29日、Webアプリケーションサーバー「Apache Tomcat」に関する6件の脆弱性情報を公開しました。開発元はいずれも重要度を「Moderate(中)」以下と評価していますが、外部の評価では「クリティカル(Critical)」とする声もあり、対応判断に迷う担当者もいるかもしれません。自社でTomcatを使っているなら、まず「どのバージョンか」を確認し、修正版(11.0.23 / 10.1.56 / 9.0.119)への更新を計画してください。

この記事でわかること

  • 今回公開された6件の脆弱性の概要と、特に注意すべき1件
  • 影響を受けるバージョンと、更新すべき修正版
  • 「開発元はModerate、外部評価はCritical」という食い違いの読み解き方
  • 情シスとして今すぐ確認すべきこと

何が公開されたのか

今回公開されたのは、Apache Tomcat 9系・10系・11系に影響する6件の脆弱性です。2026年6月15日にTomcatセキュリティチームへ報告され、 【要確認 2026-07-02:報告日(6月15日)は公式のセキュリティ情報で確認できていません。各修正版のリリースは6月22日、一般公開は6月29日は確認済みです】 6月29日に公開されました。いずれも同時期にリリースされた修正版で解消されています。

【更新 2026-07-02 追記】なお、上記6件とは別に、同じ2026年6月29日にはCVE-2026-55957も公表されています。これはJNDIRealmをGSSAPI(Kerberos)によるバインド認証に使う構成における認証バイパスで、開発元評価は上記6件より高い「Important(重要)」です。ただし修正はより古いリリース(Tomcat 11.0.5 / 10.1.37 / 9.0.101)で既に提供済みのため、本記事が扱う修正版(11.0.23 / 10.1.56 / 9.0.119)の修正内容には含まれません。本記事の主題である「認可(アクセス制御)バイパス(CVE-2026-55956)」とは別物の「認証バイパス」である点に注意し、JNDIRealm+GSSAPI/Kerberos認証を利用している場合は、そちらの修正版適用状況もあわせて確認してください。

CVE番号 開発元の評価 内容(要約)
CVE-2026-55956 Moderate(中) デフォルトサーブレットに設定したセキュリティ制約で、HTTPメソッドの指定が無視され、認可制御をすり抜けうる
CVE-2026-55955 Low(低) クラスタ通信のEncryptInterceptorがリプレイ攻撃から保護されていなかった
CVE-2026-55276 Low(低) 有効なweb.xmlのログ出力が不完全(特殊ロール・空の認可制約が記録されない)
CVE-2026-53434 Low(低) FFMコネクタで無効なCRL(証明書失効リスト)設定が検出されず、無効な証明書を受理しうる
CVE-2026-53404 Low(低) RewriteValveのOR条件(ornext)処理の不備で、後続条件がスキップされうる
CVE-2026-50229 Low(低) サンプルアプリ(数当てゲーム)にXSSの余地

とくに注意すべきはどれか

実務でまず押さえたいのはCVE-2026-55956(デフォルトサーブレットの認可バイパス)です。Tomcatでは、静的ファイルなどを配信する「デフォルトサーブレット」に対してセキュリティ制約(特定のURLやHTTPメソッドへのアクセス制限)を設定できます。今回の不具合では、制約の一部として指定したHTTPメソッド、またはメソッドの省略(すべてのメソッドを対象にする指定)が無視される場合がありました。

結果として、本来は保護されるはずのリソースへ、意図しないメソッドでアクセスできてしまう恐れがあります。認可(アクセス制御)に関わる問題であり、Tomcat上でアクセス制限を前提に設計しているアプリケーションほど影響が読みにくい、という点に注意が必要です。

影響を受けるバージョンと修正版

主要ブランチの影響範囲と修正版は次のとおりです(CVE-2026-55956を基準に整理)。

ブランチ 影響バージョン 修正版
Tomcat 11 11.0.0-M1 〜 11.0.22 11.0.23
Tomcat 10.1 10.1.0-M1 〜 10.1.55 10.1.56
Tomcat 9.0 9.0.0.M1 〜 9.0.118 9.0.119

いずれのブランチも修正版がリリース済みです。すでにサポートが終了した8.5系・7.0系などを使い続けている場合は、これを機に保守されているブランチへの移行を検討してください。なお、正確な影響範囲は各CVEで微妙に異なるため、自社の構成に合わせて公式のセキュリティ情報で確認することをおすすめします。

「中」と「クリティカル」、どちらを信じるべきか

結論から言えば、どちらか一方を鵜呑みにせず、自社での影響条件を確認するのが実務者の取るべき姿勢です。開発元のApacheは今回の6件をいずれも「Moderate(中)」以下と評価していますが、報道では「クリティカル」とする外部評価も紹介されています。

こうした食い違いは珍しくありません。脆弱性データベースやスキャナが機械的に算出するCVSSスコアは、悪用条件(特定の設定が有効な場合のみ影響する、など)を十分に反映しきれず、開発元の実態評価より高く出ることがあるためです。逆に、自社の使い方によっては開発元評価より深刻になる場合もあります。ラベルの数字だけで一喜一憂せず、「その脆弱性が成立する前提条件が、自社環境で満たされているか」を見るのが近道です。

情シスはどうすべきか

やることはシンプルで、棚卸し→影響判定→計画的な更新の3ステップです。

  • 棚卸し:自社で稼働中のTomcat(同梱製品やアプライアンス内蔵分を含む)のバージョンを洗い出す。開発者が個別に立てているものは見落としがちなので注意。
  • 影響判定:デフォルトサーブレットへのセキュリティ制約、クラスタ構成、CRL利用、RewriteValveなど、各CVEの前提となる機能を使っているかを確認する。
  • 更新:修正版へアップグレードする。マイナーバージョン更新でも動作確認は必須なので、検証環境でテストしてから本番へ。

脆弱性管理の基本的な進め方や、社内での優先度付け・体制づくりについては、IPAの資料が参考になります。中小規模の組織であれば「中小企業の情報セキュリティ対策ガイドライン」が、日々の脆弱性情報の追い方はJPCERT/CCやJVNの公開情報が起点になります。特定の製品にとどまらず、「新しい脆弱性が出たときに、誰がどう拾い、どう判断するか」という運用フローを一度整理しておくと、こうした発表のたびに慌てずに済みます。

現場から見た率直なところ

正直なところ、Tomcatのように「アプリの土台としていつの間にか組み込まれている」ミドルウェアは、情シスから最も見えにくい領域の一つです。開発チームが構築したシステムの奥深くで動いていたり、購入した業務パッケージに同梱されていたりして、バージョンの把握そのものが難しい。「Critical」の見出しに驚いても、そもそも自社のどこで何が動いているか分からなければ、判定も更新も進みません。

今回のような発表は、ある意味「自社の資産管理が追いついているか」を試す定期テストのようなものです。派手な脆弱性でなくても、棚卸しの精度を上げ、開発部門や委託先と情報を回す経路を確認する機会として使いたいところです。

まとめ

  • Apache Tomcatに6件の脆弱性が公開(2026年6月29日)。開発元評価はいずれも「中」以下だが、外部では「クリティカル」とする声もある。
  • 実務上の注目はCVE-2026-55956(デフォルトサーブレットの認可バイパス)。修正版は11.0.23 / 10.1.56 / 9.0.119。
  • スコアの数字に振り回されず、自社での稼働バージョンと影響条件を確認し、計画的に更新する。資産の棚卸しが最初の関門。

出典

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