【2026年最新】Apache Tomcatの脆弱性を解説!Spring Bootへの影響と対策

はじめに

2026年10月20日、Apache Tomcatで複数の脆弱性が公表されました。

今回公表された脆弱性は8件。なかには、認証を回避できる可能性があるものや、異なるユーザーのリクエスト・レスポンスが混在する可能性があるものも含まれています。

「Tomcatを直接インストールしたことがないから関係ない」と思う方もいるかもしれません。

しかし、Spring BootでWebアプリケーションを開発している場合、Tomcatを組み込みWebサーバーとして利用しているケースが多くあります。

この記事では、2026年10月に公表された脆弱性を中心に、以下の内容を解説します。

  • Apache Tomcatの役割
  • 2026年に公表された主な脆弱性
  • 具体的にどのような問題が発生するのか
  • Spring Bootアプリケーションへの影響
  • 使用中のTomcatバージョンを確認する方法
  • 脆弱性への対策方法

できるだけ実際のWeb API開発に置き換えて説明していきます。

※本記事は2026年10月24日時点の公式情報をもとに作成しています。

Apache Tomcatとは?

Apache Tomcatは、JavaのWebアプリケーションを動作させるためのServletコンテナです。

例えば、Spring Bootで以下のようなAPIを作成したとします。

@RestController
public class HelloController {

    @GetMapping("/hello")
    public String hello() {
        return "Hello World";
    }
}

ブラウザから/helloへアクセスすると、以下のような流れで処理されます。

ブラウザ・React
    ↓ HTTPリクエスト
Apache Tomcat
    ↓
Spring MVC(DispatcherServlet)
    ↓
HelloController
    ↓
"Hello World"
    ↓
Apache Tomcat
    ↓ HTTPレスポンス
ブラウザ・React

TomcatはHTTPリクエストを受け付け、Spring MVCへ処理を渡し、結果をクライアントへ返す役割を担います。

つまり、ControllerやServiceの実装に問題がなくても、Tomcat自体に脆弱性があれば、Webアプリケーションに影響する可能性があります。

なお、Spring Boot 3系は主にTomcat 10.1系、Spring Boot 4系はTomcat 11系に対応しています。

2026年10月に公表されたApache Tomcatの脆弱性8件

2026年10月20日に公表された脆弱性は、次の8件です。

CVE番号脆弱性の概要Tomcat公式の重要度
CVE-2026-101296特定条件で認証を回避できるImportant
CVE-2026-101356HTTP/2でリクエスト・レスポンスが混在Important
CVE-2026-103119AJPでレスポンスデータが混在Important
CVE-2026-93446TLS 1.3の接続が断続的に失敗Low
CVE-2026-88041HTTP/2のトレーラーヘッダーが別リクエストに混入Low
CVE-2026-74049JSPのリダイレクト後に処理が継続Low
CVE-2026-74048FIPSモードの有効化失敗後もサーバーが起動Low
CVE-2026-80353Unix Domain Socketへの不正アクセスLow

重要なのは、すべての脆弱性がすべてのTomcatで発生するわけではないという点です。

例えば、CVE-2026-103119はTomcat 11系、CVE-2026-80353はTomcat 9系で修正された問題です。

それぞれの影響条件を確認する必要があります。

今回は特に実務で気になる3件を詳しく解説します。

① CVE-2026-101356:HTTP/2で別ユーザーの情報が混在する可能性

今回、個人的に注目している脆弱性です。

どんな脆弱性?

HTTP/2で非同期Servletを処理している際、エラーが発生すると、Tomcat内部のオブジェクト再利用処理に問題が生じ、異なるユーザーのリクエストやレスポンスが混在する可能性があります。

Tomcatは大量のHTTP通信を効率よく処理するため、内部でオブジェクトを再利用しています。

しかし、特定のエラー発生時に、その管理が正しく行われない場合がありました。

具体例:ユーザー情報取得API

例えば、ログインユーザーの情報を取得するAPIがあるとします。

GET /api/profile

通常であれば、以下のようにレスポンスが返ります。

ユーザーA

{
  "userId": "A001",
  "userName": "田中"
}

ユーザーB

{
  "userId": "B001",
  "userName": "佐藤"
}

当然ですが、ユーザーAにはユーザーAの情報が返り、ユーザーBにはユーザーBの情報が返る必要があります。

ところが、今回の脆弱性では、HTTP/2の非同期処理中に特定のエラーが発生した場合、リクエストやレスポンスが混同される可能性があります。

ユーザーA ── リクエストA ──┐
                            │
                            ▼
                      Apache Tomcat
                       HTTP/2処理
                            ▲
                            │
ユーザーB ── リクエストB ──┘

        非同期処理中にエラー発生
                  ↓
       内部オブジェクトの再利用に不備
                  ↓
      リクエスト・レスポンスが混在する可能性

結果として、本来ユーザーAに返すべき情報が、別ユーザーの通信に混入するおそれがあります。

これは情報漏洩や意図しない処理につながる可能性がある問題です。

※上記は影響を理解するための概念例であり、このAPIを実装するだけで脆弱性を再現できるという意味ではありません。

Spring Bootではどんな実装が関係する?

Spring MVCでは、CallableやDeferredResultなどを利用してServletの非同期処理を実装できます。

例えば、以下のようなControllerです。

import java.security.Principal;
import java.util.Map;
import java.util.concurrent.Callable;

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class ProfileController {

    @GetMapping("/api/profile")
    public Callable<Map<String, String>> profile(
            Principal principal) {

        String userId = principal.getName();

        return () -> Map.of("userId", userId);
    }
}

このControllerはCallableを返しており、Spring MVCの非同期リクエスト処理を利用します。

ただし、今回の脆弱性はHTTP/2、非同期Servlet処理、処理中のエラーなど、複数の条件が関係するものです。

すべての非同期APIが直ちに攻撃可能になるわけではありません。

影響するTomcatバージョン

系列影響バージョン修正版
Tomcat 99.0.118~9.0.1229.0.123
Tomcat 10.110.1.55~10.1.6010.1.61
Tomcat 1111.0.22~11.0.2611.0.27

Spring BootでHTTP/2を有効にしている場合は、使用中のTomcatバージョンを確認しておきたいところです。

② CVE-2026-101296:パスワードが正しくなくても認証できる可能性

次は認証に関する脆弱性です。

どんな脆弱性?

TomcatにはJNDIRealmという認証機能があります。

JNDIRealmはLDAPなどのディレクトリサービスと連携してユーザー認証を行うために利用されます。

今回の脆弱性は、JNDIRealmでGSSAPI以外の特定のSASL認証方式を使用している場合、認証に必要な検証が適切に行われない問題です。

その結果、正しいパスワードを提供しなくても認証が成功する可能性があります。

具体例:社内システムのログイン

例えば、社員情報をLDAPで管理している社内Webシステムがあるとします。

通常の認証処理は以下のようになります。

ユーザー
   ↓
ログイン画面
   ↓
Tomcat(JNDIRealm)
   ↓
LDAPサーバー
   ↓
パスワード検証
   ↓
認証成功 / 認証失敗

正しいパスワードを入力した場合のみログインできるのが本来の動作です。

しかし、脆弱な構成では、認証に必要な検証処理が不足しているため、攻撃者が正しいパスワードを知らなくても認証される可能性があります。

これはシステムのアクセス制御に関わる重大な問題です。

Spring Securityを使っていても影響する?

ここは重要なポイントです。

Spring Bootで次のような認証を実装している場合、

  • Spring Securityのフォームログイン
  • JWT認証
  • OAuth 2.0 / OpenID Connect
  • 独自のUserDetailsService

これらが直ちに今回のJNDIRealmの脆弱性に該当するわけではありません。

問題になるのは、TomcatのJNDIRealmを対象のSASL認証方式で構成している環境です。

Spring SecurityとTomcatの認証機能は区別して考える必要があります。

影響するTomcatバージョン

系列影響バージョン修正版
Tomcat 99.0.122以前の対象版9.0.123
Tomcat 10.110.1.60以前の対象版10.1.61
Tomcat 1111.0.26以前の対象版11.0.27

サポート終了済みの古いTomcat系列にも影響が確認されています。

③ CVE-2026-103119:AJP通信で別リクエストのデータが漏れる可能性

どんな脆弱性?

AJP(Apache JServ Protocol)は、Apache HTTP ServerなどのWebサーバーとTomcatを連携させるために使用されるプロトコルです。

例えば、以下のようなシステム構成で利用されます。

ブラウザ
    ↓ HTTPS
Apache HTTP Server
    ↓ AJP
Apache Tomcat
    ↓
Java Webアプリケーション

今回の脆弱性では、TomcatがAJP経由で大きなレスポンスをノンブロッキング方式で書き込む際、バッファの読み取り処理に不備がありました。

その結果、レスポンス本文が現在のリクエストと次のリクエストに分割されてしまう可能性があります。

具体例:注文履歴API

例えば、次のAPIがあるとします。

GET /api/orders

ユーザーAが注文履歴を取得した後、同じAJP接続でユーザーBのリクエストが処理されるケースを考えます。

通常は、それぞれのユーザーに正しいレスポンスが返されます。

しかし、この脆弱性の影響で、ユーザーAへのレスポンスの一部が次のリクエスト側に混入する可能性があります。

公式情報によれば、次のリクエストが失敗するケースが主に想定されますが、前のレスポンスの情報漏洩につながる可能性もあります。

Spring Bootでの影響

Spring Bootの組み込みTomcatは、通常、AJPを標準で使用する構成ではありません。

そのため、通常のHTTP通信だけを利用しているアプリケーションでは、この脆弱性の影響条件には該当しません。

一方、Tomcat 11系でAJP Connectorを明示的に設定している環境は確認が必要です。

今回のCVE-2026-103119は、Tomcat 11.0.0-M25~11.0.26が影響対象で、11.0.27で修正されています。

その他、2026年10月に公表された5件

残りの脆弱性についても簡単に紹介します。

CVE-2026-93446:TLS 1.3の接続障害

Tomcat内部のクリーンアップ処理が不完全なため、TLS 1.3の接続が断続的に失敗する可能性があります。

例えば、HTTPS通信を行うクライアントが、まれに接続エラーに遭遇するようなケースが考えられます。

CVE-2026-88041:HTTP/2のトレーラーヘッダー混入

以前のリクエストのトレーラーヘッダー情報が、後続のリクエストに残ってしまう可能性があります。

トレーラーヘッダーは、HTTPメッセージ本文の後ろに付加されるメタデータです。

これをアプリケーションで扱っている場合、リクエスト間の情報混在に注意が必要です。

CVE-2026-74049:JSPリダイレクト後の処理継続

TomcatのJasperによるJSTLの<c:redirect>処理で、リダイレクト後にページ処理が直ちに終了しない問題です。

本来終了すべき処理が続くことで、意図しない出力などにつながる可能性があります。

JSPを利用するアプリケーションで特に関係する脆弱性です。

CVE-2026-74048:FIPSモードの有効化失敗

TomcatでOpenSSL-FFMを使ったFIPSモードを設定している場合、FIPSの有効化に失敗しても、非FIPSのJSSEによってサーバーが起動してしまう問題です。

セキュリティ要件としてFIPSモードを必須にしているシステムでは注意が必要です。

CVE-2026-80353:Unix Domain Socketへの不正アクセス

Unix Domain Socket作成時の権限設定に競合状態があり、ローカルの権限のないユーザーがソケットへアクセスできる可能性があります。

Tomcat 9系のAPR/Native Connectorに関係する問題です。

一般的なSpring BootのHTTP APIとは異なる環境条件が必要になります。

2026年には他にもTomcatの脆弱性が公表されている

2026年に公表されたTomcatの脆弱性は、10月の8件だけではありません。

過去数か月にも、注目すべき脆弱性が複数公表されています。

公表日CVE番号概要
2026/9/23CVE-2026-86350HTTP/2のリクエストヘッダー混在
2026/9/23CVE-2026-76183WebSocketエンドポイントのアクセス制御回避
2026/9/23CVE-2026-78383AJPの処理スレッドを占有するDoS
2026/8/25CVE-2026-68763HTTP/2ストリーム管理におけるリソースリークによるDoS
2026/8/25CVE-2026-68569特定のRealmでユーザー存在確認が正しく行われない
2026/8/25CVE-2026-65182セキュリティ制約の適用順序によるアクセス制御回避
2026/4/9CVE-2026-24880不正なHTTP/1.1チャンク拡張によるリクエストスマグリング

※2026年に公表された脆弱性の一部を抜粋しています。

特に気になるのはCVE-2026-86350

この脆弱性は、以前の脆弱性(CVE-2026-41293)に対する修正が原因で、新しい問題が発生したものです。

いわゆる**リグレッション(修正による不具合の再発・新規発生)**です。

ソフトウェア開発では、不具合を修正したことで別の不具合が発生することがあります。

今回のケースは、その問題がセキュリティ上の脆弱性として現れた例です。

2026年10月の脆弱性も含めると、HTTP通信の解釈や内部オブジェクトの管理は、Webサーバーの安全性に直結することが分かります。

Spring Bootのプロジェクトで脆弱性の影響を確認する方法

ここからは、実際にSpring Bootアプリケーションを開発している方向けの確認方法です。

① MavenでTomcatのバージョンを確認する

Mavenを利用している場合、次のコマンドを実行します。

mvn dependency:tree -Dincludes=org.apache.tomcat.embed

Windowsのコマンドプロンプトでも1行で実行できます。

例えば、以下のように出力されたとします。

org.apache.tomcat.embed:tomcat-embed-core:jar:10.1.60
org.apache.tomcat.embed:tomcat-embed-el:jar:10.1.60
org.apache.tomcat.embed:tomcat-embed-websocket:jar:10.1.60

この例では、Tomcat 10.1.60を利用しています。

10月公表のCVE-2026-101356やCVE-2026-101296について、影響条件の確認が必要なバージョンです。

② Gradleで確認する

Gradleを利用している場合は、次のコマンドで確認できます。

./gradlew dependencyInsight \
  --dependency tomcat-embed-core \
  --configuration runtimeClasspath

Windowsの場合はgradlew.batを使用してください。

確認したいのは、実際に解決されたtomcat-embed-coreのバージョンです。

③ HTTP/2を利用しているか確認する

Spring Bootでは、次の設定によってHTTP/2を有効にできます。

server:
  http2:
    enabled: true

ただし、この設定がないからといって、今回のTomcat脆弱性がすべて無関係になるわけではありません。

HTTP/2を使用する脆弱性もあれば、認証設定やAJPなど別の機能に関係する脆弱性もあります。

また、AWSのALBやリバースプロキシを利用している場合、ブラウザ側がHTTP/2でも、Tomcat側までHTTP/2で通信しているとは限りません。

実際の通信経路も確認する必要があります。

④ Tomcatを修正版へ更新する

2026年10月20日公表分に対する修正版は、次のとおりです。

Tomcat系列修正版
Tomcat 99.0.123
Tomcat 10.110.1.61
Tomcat 1111.0.27

これらは2026年10月12日にリリースされ、その後10月20日に脆弱性情報が公開されています。

Spring Bootでは、原則として修正版Tomcatを含むSpring Bootのメンテナンスリリースへ更新する方法を優先して検討します。

すぐにSpring Bootを更新できない場合は、依存関係のバージョンを個別に変更する方法もありますが、互換性や動作テストが必要です。

Tomcatの修正版番号だけを見て、Spring Bootのバージョンを無条件に変更しないようにしましょう。

実務では何を優先して確認すべき?

今回の脆弱性を踏まえると、次のような観点が重要だと考えています。

1. 依存ライブラリのバージョン管理

Spring Bootのようなフレームワークは、多くのライブラリに依存しています。

自分で直接追加していないライブラリにも脆弱性が存在する可能性があります。

2. 認証処理の実装・構成

認証はSpring Securityだけでなく、Tomcatやリバースプロキシなど、複数のレイヤーで実現されることがあります。

どのレイヤーで認証・認可を行っているか把握することが重要です。

3. 非同期処理の利用状況

非同期処理そのものが危険というわけではありません。

ただし、HTTP/2やWebSocket、Servlet非同期処理などを利用している場合、通常の同期APIとは異なる確認項目が増えます。

4. 本番環境の構成確認

開発環境では組み込みTomcatを使っていても、本番環境では外部TomcatへWARをデプロイしているケースがあります。

また、DockerやAWS ECS・EC2などを利用する場合は、実際に稼働している環境のバージョンを確認する必要があります。

5. 修正後のテスト

Tomcatのバージョンを変更したら、少なくとも以下の動作を確認しておきたいところです。

  • ログイン・ログアウト
  • HTTP APIの正常系・異常系
  • 非同期API
  • WebSocket(利用している場合)
  • HTTPSやHTTP/2の通信

特に外部システムと連携しているAPIでは、タイムアウトやエラー処理も確認するとよいでしょう。

まとめ

2026年は、Apache Tomcatに関する脆弱性が継続的に公表されています。

10月20日に公表された8件のうち、特に注目したいのは以下の3件です。

  • CVE-2026-101296: 特定条件で認証を回避できる可能性
  • CVE-2026-101356: HTTP/2の非同期処理で異なるユーザーの情報が混在する可能性
  • CVE-2026-103119: AJP通信でレスポンスデータが混在する可能性

Spring Bootを利用している場合は、Tomcatの存在をあまり意識せずに開発していることもあると思います。

しかし、Webアプリケーションのセキュリティは、ControllerやServiceのコードだけで決まるものではありません。

使用しているフレームワーク、Webサーバー、ミドルウェアまで含めて確認することが重要です。

まずは、自分が担当しているSpring Bootプロジェクトで、どのバージョンのTomcatが使用されているか確認することから始めてみてはいかがでしょうか。

参考情報

関連記事

認証機能の仕組みについて学びたい方は、以下の記事も参考にしてください。

Spring Security 7でPasskey認証を実装する:WebAuthn入門

Spring SecurityとWebAuthnによる認証の仕組みを、Spring Bootの実装例とともに解説しています。

是非フォローしてください

最新の情報をお伝えします

類似投稿