2026.11.03 Java

Tomcatのバージョン確認方法｜version.sh・起動ログ・管理画面・Spring Boot組み込み版の調べ方と脆弱性の影響判定

Q: Tomcatのバージョンをコマンドで確認するには？

Tomcatのインストール先で bin/version.sh を実行します（Windowsは bin\version.bat ）。出力の「Server version」の行に「Apache Tomcat/11.0.27」のような形で系列とパッチ番号が出ます。 catalina.sh version で得られる結果も同じです。どちらも起動中かどうかに関係なく使え、起動に使うJavaの版も同時に表示されるので、Java要件を満たしているかもあわせて確かめられます。

Q: Linuxでversion.shが見つからない場合はどうすればよいですか？

まず ps -ef | grep '[c]atalina.home' で起動中のプロセスの -Dcatalina.home= を読み、本体の場所を特定します。停止中なら find で catalina.jar を探し、jar内の ServerInfo.properties を unzip -p で読めば版が分かります。OSのパッケージで入れた場合は、 dpkg -l や rpm -q で版を確認してください。Spring Bootのアプリなら bin ディレクトリ自体がありません。

Q: Spring Bootに組み込まれたTomcatのバージョンはどう確認しますか？

ビルド側ではMavenなら dependency:tree -Dincludes=org.apache.tomcat.embed 、Gradleなら dependencyInsight --dependency tomcat-embed-core で版が分かります。本番側では、実行可能jarの BOOT-INF/lib にある tomcat-embed-core のファイル名か、起動ログの「Starting Servlet engine」の行を見ます。Spring Boot 4.1.2の管理版は11.0.27です。版はSpring Bootの版上げで更新されます。

Q: Tomcatのバージョン表示を隠すにはどうしますか？

エラーページの版は、 server.xml のHost内に ErrorReportValve を showServerInfo="false" で設定すると消えます。あわせて、公開環境ではROOTアプリとドキュメントアプリを削除します。Serverヘッダーは8.5系以降なら既定で付きません。隠すのは攻撃者への手がかりを減らすためであって、脆弱性が消えるわけではありません。修正版の適用は別に進めてください。

Tomcatのバージョン確認方法｜version.sh・起動ログ・管理画面・Spring Boot組み込み版の調べ方と脆弱性の影響判定

Tomcatのバージョンは、インストール先のbin/version.sh（Windowsはversion.bat）を実行すれば1行目の「Server version」で分かります。ただ、現場で困るのはその先です。どこにインストールされているか分からない、Javaが入っていないサーバーに古い本体だけ残っている、Spring Bootのjarに組み込まれていてbinディレクトリ自体が無い、といった場面では別の手段が要ります。この記事では、2026年11月3日時点の11.0.27・10.1.61・9.0.123を前提に、サーバー上のコマンド、起動ログ、Managerアプリ、Spring BootとDocker公式イメージでの確かめ方を整理し、確認した版が脆弱性の影響範囲に入るかを判定する手順までまとめました。

まとめ｜Tomcatの版はversion.shで確定し画面やヘッダーの表示は信用しない

確実なのはversion.shです。中身はcatalina.sh versionの呼び出しで、Tomcat本体のjarに書き込まれた版番号と、起動に使うJavaの版を表示します。起動していないTomcatでも動き、管理画面やエラーページの表示を書き換えていても正しい版が出ると公式ドキュメントが明記しています。

確認経路は置かれた環境で選びます。

サーバーにログインできる：version.sh、Javaが無ければcatalina.jar内のServerInfo.propertiesを読む
ログしか見られない：起動時に出る「Server version name」の行をgrepする
Spring Bootアプリ：ビルドの依存ツリーでtomcat-embed-coreの版を見る
Docker公式イメージ：コンテナ内でversion.shを実行する

版が分かったら、系列ごとのセキュリティ情報のAffects欄と突き合わせ、修正版へ上げるかを決めます。エラーページやHTTPヘッダーに出る版で判定を済ませないのが、この記事の一番の主張です。

稼働中Tomcatの版をコマンドで確かめる手順とLinux・Windowsの差

version.shの出力で系列・パッチ番号・JVMを確認する手順

まずCATALINA_HOME（Tomcat本体の置き場所）を特定します。起動中のプロセスがあれば、Javaの起動引数に-Dcatalina.home=が付いているので、そこから読み取れます。これからTomcatを入れる場合の配置と自動起動の設定はTomcatのインストール手順で解説しています。

# 起動中のTomcatから本体の場所を探す（-Dcatalina.home= の値を読む）
ps -ef | grep '[c]atalina.home'

# 本体の場所が分かったら版を表示する
cd /opt/tomcat          # 環境に合わせて読み替える
./bin/version.sh
# 同じ処理を直接呼ぶ場合
./bin/catalina.sh version

catalina.shのソースを読むと、versionはlib配下をクラスパスにしてorg.apache.catalina.util.ServerInfoを実行するだけの処理です。その前にsetenv.shを読み込むため、本番の起動と同じJavaが使われます。

出力項目はServerInfo.javaで決まっています。出力のうち、系列とパッチ番号、比較用の版番号、起動に使うJavaの版を確認するために見る行は、次の3つです。

Server version：「Apache Tomcat/11.0.27」の形で系列とパッチ番号が出る
Server number：4つの数字の版番号。スクリプトで比較するときはこちらが扱いやすい
JVM Version：起動に使うJavaの版。11.0系はJava 17以降が必要なので、ここも同時に確かめる

このほかOS NameやAPR loadedの行も出ます。版番号に-Mが付いていればマイルストーン版で、本番向けの安定版ではありません。

Windowsサービス運用でversion.batが環境変数未設定で止まるときの対処

Windowsではbin\version.batを使ってください。インストーラーで入れてWindowsサービスとして動かしている環境では、サービスがJavaの場所を独自に持っているため、コマンドプロンプトにJAVA_HOMEが無いことがよくあります。その場合はsetclasspath.batが「Neither the JAVA_HOME nor the JRE_HOME environment variable is defined」と出して終了します。

rem その場限りでJAVA_HOMEを指定してから実行する（パスは環境に合わせる）
set "JAVA_HOME=C:\Program Files\Java\jdk-21"
cd "C:\Program Files\Apache Software Foundation\Tomcat 11.0\bin"
version.bat

setはそのウィンドウだけに効くので、システムの環境変数を書き換えずに済みます。サービスの設定を変えて確認しようとしないでください。版を見るだけなら、本番のサービスに触る必要はありません。

起動していないTomcatやJavaの無い環境でcatalina.jarから版を読む方法

停止中のサーバーや、バックアップから戻したディレクトリ、Javaを外した古い環境ではversion.shが動きません。版番号そのものはlib/catalina.jarの中のServerInfo.propertiesに入っているので、展開して読めます。

# サーバー内に残っているTomcat本体を洗い出す
find / -name catalina.jar -path '*/lib/*' 2>/dev/null

# Javaを使わずに版番号を読む（server.info と server.number の行を見る）
unzip -p /opt/tomcat/lib/catalina.jar org/apache/catalina/util/ServerInfo.properties

ServerInfo.javaが読んでいるのは、まさにこのファイルのserver.info・server.built・server.numberです。findで複数見つかったら、使われていない旧版が残っている合図です。脆弱性診断で古い本体が検出される原因になるため、棚卸しの段階で撤去の要否を決めます。

起動ログ・管理画面・HTTP応答から稼働中Tomcatの版を確かめる方法と限界

catalina.outから起動時の版情報をgrepで拾い起動日時と照合する手順

サーバーへのシェル権限が無く、ログだけ渡される運用もあります。既定のserver.xmlは最初のリスナーにVersionLoggerListenerを置いており、リスナーの設定リファレンスのとおり、起動のたびにTomcat・Java・OSの情報をログへ書きます。

# 起動時の版情報だけを抜き出す（ログの場所は環境に合わせる）
grep -E 'Server version (name|number)|JVM Version' /opt/tomcat/logs/catalina.out

# systemd で動かしている場合はジャーナルを見る
journalctl -u tomcat --no-pager | grep 'Server version name'

行の見出しは「Server version name」「Server version number」です。ログは起動した時点の版を示すので、版上げ後に再起動していなければ古い値のままです。版情報の行を読むときは、ログに記録された最後の起動日時も合わせて確認してください。server.xmlからこのリスナーを外している環境では、行そのものが出ません。

Managerのserverinfoで版情報を取得するためのロール設定

Managerアプリが入っていれば、HTTPで版情報の取得が可能です。Managerのドキュメントでは/manager/text/serverinfoがTomcatの版・OS・JVMの情報を返すとされ、利用にはmanager-scriptロールが要ります。初期状態ではこのロールを持つ利用者がいないため、conf/tomcat-users.xmlに追加します。

<!-- conf/tomcat-users.xml：版の取得専用の利用者を作る -->
<role rolename="manager-script"/>
<user username="ops-check" password="長く推測されにくい値" roles="manager-script"/>

# Tomcatと同じホストから取得する
curl -u ops-check http://localhost:8080/manager/text/serverinfo

監視ツールから定期取得するならこの経路が楽です。ただし、Managerはリモート配備ができるため攻撃の標的になりやすいと公式も注意しています。版を見るためだけにManagerをインターネット側へ開けるのは見送ります。

エラーページやServerヘッダーで版が見える条件と外部から確かめる危うさ

外からcurl -Iを打っても、多くの場合版は分かりません。セキュリティ設定のガイドによると、8.5系以降はServerヘッダーを既定で付けません。一方、既定のErrorReportValveは404などのエラーページに版番号を載せます。ROOTアプリやドキュメントアプリも版を表示します。

この表示は設定によって書き換えが可能な情報です。同じガイドには、CATALINA_BASE/libにServerInfo.propertiesを置いてserver.infoを変える方法が載っており、その場合は管理ツールの表示も変わる一方、version.shは正しい版を出し続けると書かれています。表示を消したいときは、Valveの設定リファレンスにあるshowServerInfo（既定はtrue）をfalseにします。

<!-- conf/server.xml の Host 内：エラーページから版とスタックトレースを外す -->
<Valve className="org.apache.catalina.valves.ErrorReportValve"
       showServerInfo="false" showReport="false" />

外部から見えた版は「表示されている文字列」に過ぎません。偽装されていることも、前段のプロキシが別のエラーページを返していることもあります。判定の根拠には使わず、隠せているかの点検に使う程度にとどめます。

Spring Boot・Docker公式イメージ内のTomcatの版を確かめる手順

Maven・Gradleの依存情報から組み込みTomcatの版を特定する手順

Spring Bootのアプリにはbin/version.shがありません。組み込みTomcatの実体はorg.apache.tomcat.embed:tomcat-embed-coreというライブラリで、版はSpring Bootが管理します。Spring Boot 4.1.2の管理依存の一覧ではtomcat-embed-coreは11.0.27です。

# Maven：組み込みTomcatの版を依存ツリーから絞り込む
./mvnw dependency:tree -Dincludes=org.apache.tomcat.embed

# Gradle：実行時クラスパスで解決された版と、その理由を表示する
./gradlew dependencyInsight --dependency tomcat-embed-core --configuration runtimeClasspath

ここで出る版がSpring Bootの管理版と違えば、誰かによる版の上書きがある状態です。脆弱性の修正版が先に出たときは、Mavenプラグインのドキュメントにあるとおり<tomcat.version>プロパティで版を上書きできます。Gradleでは依存管理のドキュメントの方法でext['tomcat.version']を設定します。

<!-- pom.xml（spring-boot-starter-parent を継承している場合） -->
<properties>
  <tomcat.version>11.0.27</tomcat.version>
</properties>

公式は、上書きは互換性の問題を招きうるので慎重に、と警告しています。上書きは次のSpring Bootの修正版が出るまでのつなぎにとどめ、修正版が出た時点で外してください。組み込みTomcatの版を決めるSpring Boot側の期限はSpring Bootのバージョン一覧とサポート期限で確認できます。BOM importやGradleのplatformでプロパティが効かない構成での書き方はSpring Bootの組み込みTomcatの版上げとserver.*設定の手順にまとめています。

実行可能jarの中身と起動ログで本番のTomcatの版を照合する手順

ビルド定義が正しくても、本番に載っているjarが古いことはあります。本番側では、実際に配置された成果物に含まれる版と、起動ログに記録された版の2点を突き合わせて照合します。

# 実行可能jarに同梱された組み込みTomcatのファイル名を見る
unzip -l app.jar | grep tomcat-embed-core
# BOOT-INF/lib/tomcat-embed-core-（版番号）.jar の形で出る

# 起動ログから実際に動いた版を拾う
grep 'Starting Servlet engine' application.log

起動ログの文言はTomcatのメッセージ定義で「Starting Servlet engine: [{0}]」と決まっており、角括弧の中に「Apache Tomcat/11.0.27」のような版が入ります。jarのファイル名とログの値が食い違っていたら、クラスパスに別の版が紛れ込んでいる疑いがあります。

Docker公式イメージの環境変数とコンテナ内コマンドで版を確認する手順

Docker公式イメージはDockerfileでCATALINA_HOMEを/usr/local/tomcatに置き、binをPATHに通しています。2026年11月3日時点の11.0/jdk21/temurin-nobleはTOMCAT_VERSIONが11.0.27です。

# イメージに記録された版（ビルド時の値）
docker exec my-tomcat printenv TOMCAT_VERSION

# コンテナ内で実際に入っている本体の版
docker exec my-tomcat version.sh

環境変数はイメージを作った時点の値です。派生イメージでlibのjarを差し替えている場合は実体とずれるので、判定にはversion.shの結果を使ってください。tomcat:11.0のような浮動タグは取得した日によって中身が変わるため、本番はパッチ番号まで固定したタグかダイジェストで指定します。Spring Bootアプリをコンテナに載せる構成なら、Spring BootのDockerfileの書き方のように組み込み版をjar側で管理する形になります。

確認した版を脆弱性情報と突き合わせて修正版へ上げるかを決める判断基準

Affects欄と版番号を照合する手順と11.0.27の修正範囲の実例

版が分かったら、系列ごとのセキュリティ情報を開きます。11.0系はsecurity-11.html、10.1系はsecurity-10.html、9.0系はsecurity-9.htmlです。各CVEの「Affects」欄にある範囲に自分の版が入るかを見ます。2026年10月20日に公表された11.0.27の修正分を例にすると、範囲の幅は脆弱性ごとにかなり違います。

CVE	重大度	内容	Affects
CVE-2026-101296	Important	JNDIRealmの認証	11.0.0-M1〜11.0.26
CVE-2026-103119	Important	AJPの応答の取り違え	11.0.0-M25〜11.0.26
CVE-2026-101356	Important	HTTP/2非同期処理の取り違え	11.0.22〜11.0.26

判定は「版が範囲に入るか」と「その機能を使っているか」の2段です。AJPコネクタもHTTP/2も有効にしていない構成なら、上の2件目と3件目は該当しません。ただし1件目のように系列のほぼ全版が範囲に入るものもあるので、11.0.26以前なら11.0.27へ上げる前提で計画するのが現実的です。CVEごとの影響条件と当て方はApache Tomcatの脆弱性一覧と影響確認・対応手順に、系列そのもののサポート期限はTomcatのバージョン一覧とサポート期限にまとめています。

OSパッケージ版の版番号とApache公式の版を同じ物差しで比べない理由

Linuxのパッケージで入れたTomcatは、確認の仕方も読み方も変わります。版はdpkg -l 'tomcat*'（Debian・Ubuntu）やrpm -q tomcat（RHEL系）で見ます。

注意したいのは、ディストリビューションが古い版番号のまま修正だけを取り込む運用をとる場合がある点です。表示がApacheの最新版より古くても、修正済みのことがあります。逆に、パッケージ版でApacheのAffects欄を機械的に当てはめると、誤って「影響あり」と判定します。パッケージ版の判定は、各ディストリビューションのセキュリティ告知に従ってください。Apacheから直接取得した本体とパッケージ版が同じサーバーに混在しているなら、前の章のfindで洗い出し、どちらが動いているかを先に確定させます。

版確認を手作業で済ませてよい規模と棚卸しを仕組み化すべき条件

Tomcatが1〜2台で、構成も1人が把握しているなら、脆弱性の公表のたびにversion.shを打つ手作業で足ります。仕組み化は過剰です。

一方、次のどれかに当てはまるなら、手作業はやめて定期的な棚卸しに切り替えます。外部公開のTomcatが3台以上ある場合、Spring Bootの組み込み版と単体のTomcatが混在している場合、担当者の交代で「どこに何が入っているか」を誰も答えられない場合です。最低限、Server numberとホスト名を週次で集めて一覧化し、security-11.htmlなどの更新と照合する流れを作ります。

9.0系や8.5系が棚卸しで見つかったときは、修正版の適用ではなく版上げの計画に切り替えます。8.5系は2024年3月31日に終了しており、9.0系も2027年3月31日で終わるためです。古いTomcatで動く業務システムの棚卸しから版上げ後の回帰テストまでを外部に任せたい場合は、保守運用・内製化支援で既存システムの現状調査から相談を受けています。

よくある質問

Tomcatのバージョン確認について、検索の多い質問に答えます。

Tomcatのバージョンをコマンドで確認するには？

Tomcatのインストール先でbin/version.shを実行します（Windowsはbin\version.bat）。出力の「Server version」の行に「Apache Tomcat/11.0.27」のような形で系列とパッチ番号が出ます。catalina.sh versionで得られる結果も同じです。どちらも起動中かどうかに関係なく使え、起動に使うJavaの版も同時に表示されるので、Java要件を満たしているかもあわせて確かめられます。

Linuxでversion.shが見つからない場合はどうすればよいですか？

まずps -ef | grep '[c]atalina.home'で起動中のプロセスの-Dcatalina.home=を読み、本体の場所を特定します。停止中ならfindでcatalina.jarを探し、jar内のServerInfo.propertiesをunzip -pで読めば版が分かります。OSのパッケージで入れた場合は、dpkg -lやrpm -qで版を確認してください。Spring Bootのアプリならbinディレクトリ自体がありません。

Tomcatのバージョンをブラウザから確認できますか？

既定の設定なら、存在しないURLを開いたときのエラーページ下部や、ROOTアプリのトップページに版が表示されます。Managerアプリの/manager/statusも版を確認できる画面です。ただし、エラーページの表示はshowServerInfo="false"で消せるうえ、ServerInfo.propertiesで書き換えることもできます。ブラウザで見えた版は参考にとどめ、判定にはサーバー上のversion.shの結果を使ってください。

Spring Bootに組み込まれたTomcatのバージョンはどう確認しますか？

ビルド側ではMavenならdependency:tree -Dincludes=org.apache.tomcat.embed、GradleならdependencyInsight --dependency tomcat-embed-coreで版が分かります。本番側では、実行可能jarのBOOT-INF/libにあるtomcat-embed-coreのファイル名か、起動ログの「Starting Servlet engine」の行を見ます。Spring Boot 4.1.2の管理版は11.0.27です。版はSpring Bootの版上げで更新されます。

Tomcatのバージョン表示を隠すにはどうしますか？

エラーページの版は、server.xmlのHost内にErrorReportValveをshowServerInfo="false"で設定すると消えます。あわせて、公開環境ではROOTアプリとドキュメントアプリを削除します。Serverヘッダーは8.5系以降なら既定で付きません。隠すのは攻撃者への手がかりを減らすためであって、脆弱性が消えるわけではありません。修正版の適用は別に進めてください。