Apache Tomcatに、アクセス制御をすり抜けられる不具合を中心とした11件の脆弱性が公表されました。深刻度「Important」は4件で、いずれも「認証・認可の判定が意図せず通ってしまう」系統です。修正版は11.0.25 / 10.1.59 / 9.0.121で、JVNからも2026年8月25日付で注意喚起が出ています。
今すぐやることは1つです。「自社のどこでTomcatが動いているか」の棚卸し。自分でインストールした覚えがなくても、グループウェアや業務パッケージに同梱されて動いていることが珍しくありません。
この記事でわかること
- Tomcatが「知らないうちに動いている」典型パターンと、その確認方法
- 11件のうち、どれを先に潰すべきか（優先度の判断材料）
- 同梱型（バンドル）製品でTomcatだけを上げられないときの考え方
- 「10.1.58」を探しても見つからない理由
Apache Tomcatとは何者か（「うちは使っていない」と思っている人ほど要確認）
Apache Tomcatとは、Javaで書かれたWebアプリケーション（サーブレット／JSP）を動かすためのアプリケーションサーバーです。Apache Software Foundationが開発するオープンソースで、Javaの業務システムを社内公開・外部公開する際の「土台」として広く使われています。
重要なのは、情シスが自分でTomcatを導入した記憶がなくても、製品に同梱されて動いているケースが非常に多いという点です。一次情報で確認できる例を挙げます。
- Atlassian Confluence：Atlassianの公式ドキュメントは「同梱されているTomcatのバージョンのみをサポートする。独自のアプリケーションサーバーでConfluenceを動かすことはできない」と明記しています。つまり利用者側の判断でTomcatだけを差し替えることができません。
- Liferay DXP／Portal：公式ドキュメントに「Tomcat Bundle」（Tomcatに製品をあらかじめ配置した配布形態）の導入手順が用意されています。
- このほか、Javaベースの業務パッケージやアプライアンス製品では、インストーラがTomcatを同時展開する構成が一般的です。
資産管理台帳に「Tomcat」という行が無くても、実体は動いています。逆に言えば、製品名ではなくファイル単位で探すのが確実です（探し方は後述します）。
何が起きたのか
Apache Software Foundationが、Tomcatの各サポートブランチに対して修正版を公開しました。公式のセキュリティページに並ぶのは計11件で、内訳は Important 4件・Moderate 1件・Low 6件です（JVNの注意喚起は、既報の1件を除いた10件を案内しています）。
| CVE番号 | 深刻度 | 概要 |
|---|---|---|
| CVE-2026-65182 | Important | セキュリティ制約のバイパス（制約の記述順による判定漏れ） |
| CVE-2026-65927 | Important | RewriteValveの[N]フラグが2番目のルールから再開し、アクセス制御を回避 |
| CVE-2026-68569 | Important | Realmでの利用者検索が失敗した際に「フェイルオープン」（通してしまう） |
| CVE-2026-68763 | Important | HTTP/2のストリームリセット時にメモリが解放されずDoS |
| CVE-2026-65637 | Moderate | HTTP/2でオーソリティ無しのリクエストによりSNIの厳格検証を回避 |
| CVE-2026-68525 | Low | FORM認証後のリダイレクトでメソッド単位の制約を回避 |
| CVE-2026-66422 | Low | サーブレットのロール参照定義がRealm側でロール別名として扱われる |
| CVE-2026-65905 | Low | DIGEST認証で限定的なリプレイ攻撃が可能 |
| CVE-2026-73180 | Low | HTTPセッション終了後も認証済みWebSocketセッションが残存 |
| CVE-2026-65183 | Low | Unixドメインソケットの権限設定時のTOCTOU（競合状態） |
| CVE-2026-66299 | Low | WebSocketチャットのサンプルアプリでメモリ枯渇（既報） |
修正版と公開日は次のとおりです。
| ブランチ | 修正版 | 公開日 | 影響を受けるバージョン（主要な件） |
|---|---|---|---|
| 11.0.x | 11.0.25 | 2026-08-18 | 11.0.0-M1 ～ 11.0.24 |
| 10.1.x | 10.1.59 | 2026-08-20 | 10.1.0-M1 ～ 10.1.57 |
| 9.0.x | 9.0.121 | 2026-08-18 | 9.0.0-M1 ～ 9.0.120 |
どれから手を付けるべきか
CVE-2026-65182：セキュリティ制約のバイパス
web.xml のセキュリティ制約で、長いパスの制約を先に書き、その配下のより短いパスに厳しい制約を後から書いている場合に、意図した制限が効かなくなります。設定の書き順という「レビューで見落としやすい部分」が条件になるのが厄介な点です。自社アプリの <security-constraint> の記述順を確認する良い機会と言えます。
CVE-2026-68569：認証がフェイルオープンする
DataSourceRealmを使い、かつCLIENT-CERT（クライアント証明書）やSPNEGO（Windows統合認証）で認証している環境で、Realmに存在しない利用者が認証を通ってしまうという不具合です。「安全側に倒れない」タイプの欠陥なので、該当構成なら優先度は高くなります。認証方式が組織のIDインフラと直結しているぶん、影響範囲を上司に説明しやすい案件でもあります。
CVE-2026-65927：RewriteValveのオフバイワン
URL書き換え（RewriteValve）で [N] フラグを使っていると、処理の再開位置が1つずれ、後続のアクセス制御ルールを飛ばしてしまう可能性があります。Rewriteをアクセス制御の一部として使っている構成は、実は珍しくありません。rewrite.config に [N] があるかどうかで一次切り分けができます。
CVE-2026-68763：HTTP/2のリセットでメモリが漏れる
HTTP/2のストリームをリセットさせ続けることで確保済みメモリが解放されず、サービス停止に至るおそれがあります。過去にも同系統のHTTP/2枯渇型DoSが繰り返し報告されており（当サイトのHTTP/2にDoS脆弱性 フロー制御停止でメモリ枯渇も参照）、インターネットに面したTomcatでHTTP/2を有効にしているなら現実的な脅威です。
なお、認可バイパス系はTomcatで繰り返し出ています。過去記事（Apache Tomcatに複数の脆弱性、認可バイパスに注意、Apache ActiveMQに2件の脆弱性、認可バイパスとDoS）と合わせて読むと、傾向がつかみやすいはずです。
自社は影響を受けるか（該当判定の手順）
「Tomcatを入れた覚えがない」場合の探し方です。製品名ではなくファイルとポートで探すのが確実です。
- ファイルを探す：サーバー内で
catalina.jarまたはbin/catalina.sh（Windowsはcatalina.bat）を検索します。見つかったディレクトリがTomcatの実体です。 - バージョンを確認する：そのディレクトリで
bin/version.sh（Windowsはbin\version.bat）を実行すると、「Server number」としてバージョンが表示されます。ここが 11.0.25 / 10.1.59 / 9.0.121 より前なら該当します。 - 構成を確認する：
conf/server.xmlでHTTP/2コネクタの有無、conf/web.xmlと各アプリのWEB-INF/web.xmlでセキュリティ制約、conf/rewrite.configで[N]の使用有無を見ます。 - 同梱型かを見極める：Tomcatのディレクトリが製品のインストール先配下（例：グループウェアや業務パッケージのフォルダ内）にある場合は同梱型です。この場合は製品ベンダーの更新を待つのが原則で、独断でjarを差し替えるとサポート対象外になり得ます。
現場目線の課題
正直なところ、この手の「11件まとめて公開」は現場にとってありがたくありません。深刻度がImportantでも、緊急パッチとして即日サービスを止めるほどではない。かといって放置すれば、次に何かあったときに「なぜ8月の分を当てていないのか」と問われる。この「急ぎではないが確実に効いてくる」帯の作業が、いちばん溜まります。
さらに厄介なのが同梱型です。前述のとおりConfluenceは同梱Tomcat以外をサポートしません。執筆時点で公開されているAtlassianの対応表では、Confluence 10.2系に同梱されるTomcatは10.1.57（＝今回の影響範囲）です。利用者側でできるのは「ベンダーが取り込むのを待つ」ことだけで、その間の空白は、外部公開の有無やアクセス制限といった周辺で埋めるしかありません。バンドル製品を採用した時点で、パッチ適用の主導権を一部手放しているという事実は、リスク評価に明示的に書いておくべきだと感じます。
そしてもう一つ、地味に時間を溶かす罠があります。10.1系を使っている場合、「10.1.58」を探しても見つかりません。Apacheの公式セキュリティページによれば、修正自体は10.1.58で行われたものの、そのリリース投票が通らなかったため配布されていません。取得すべきは10.1.59です。手順書に「10.1.58以降」と書いてしまうと、現場で確実に止まります。
なお、公開情報の範囲では、今回の件について悪用の報告は確認できていません。ただし認可バイパス系は攻撃手法が出回ると一気に広がるため、「悪用報告が無いこと」を先送りの根拠にはしないほうが無難です。先日取り上げたTomcatサンプルアプリの脆弱性（CVE-2026-66299）は当時まだ修正版が出ていませんでしたが、今回のリリースで解消されています。この件を保留にしていた組織は、今回まとめて片付けられます。
情シスはどうすべきか
個別の設定チェックリストを自前で作り込むより、「Tomcatがどこで動いているかを把握し、更新を回す仕組み」に手をかけるほうが費用対効果は高くなります。仕組み側の整備は、公的機関の指針をたたき台にするのが早道です。
- IPA「中小企業の情報セキュリティ対策ガイドライン」：資産管理と更新運用（脆弱性対応のプロセス化）の基本形が整理されています。台帳に載らないミドルウェアをどう扱うかを決める出発点になります。
- IPA「セキュリティインシデント対応 机上演習教材」：「同梱コンポーネントに脆弱性が出たが、ベンダー更新待ち」という今回のようなシナリオは、机上演習の題材として現実的です。
- IPA「対策のしおり」：Tomcat自体は利用部門の目に見えませんが、更新のための計画停止に協力してもらう場面は必ず来ます。日頃の啓発が効いてくる部分です。
加えて、外部公開しているTomcatについては、更新までの間の暫定策（HTTP/2の要否の見直し、管理系パスへのアクセス元制限）を検討する価値があります。恒久策ではありませんが、待ち時間の説明材料にはなります。
まとめ
- Apache Tomcatに11件の脆弱性が公表され、Important 4件はいずれもアクセス制御をすり抜ける系統。修正版は11.0.25 / 10.1.59 / 9.0.121。
- 自社導入していなくても、Confluenceのようなバンドル製品に同梱されて動いている。
catalina.jarの検索とbin/version.shでまず該当判定を。 - 同梱型はベンダー更新待ちになる点、10.1系の修正版は「10.1.58」ではなく10.1.59である点を、手順書と報告資料に明記する。
出典
- JVN: Apache Tomcatにおける複数の脆弱性(2026年8月25日)
- Apache Tomcat: Security – Apache Tomcat 11
- Apache Tomcat: Security – Apache Tomcat 10
- Apache Tomcat: Security – Apache Tomcat 9
- Atlassian: Supported platforms（同梱Tomcatのみサポートである旨） / Bundled Tomcat and Java versions
- Liferay: Installing a Liferay-Tomcat Bundle
