【CVE-2026-93446】
※V12.1の場合
V12.11.01.00 標準修正を適用した場合に影響あります。
V12.10.00.00/V12.11.00.00は影響ありません。
[脆弱性の概要]
TLS通信の内部状態(ハンドシェイクの進行状況を記録するフラグ)が、接続の再利用時に初期化されません。そのため、前の接続の状態が残ったまま次の接続が処理される場合があります。
[脆弱性に該当する条件]
以下の全ての条件を満たした場合に該当します（条件の確認方法は、各項目末尾の
(※1)～(※5)に対応する「条件の確認方法」をご参照ください）。
(1) Javaベースの内蔵Webサーバが、クライアントからのHTTPS(TLS)接続を直接処理
している。(※1)
(2) 該当するHTTPS用のネットワークリスナーが有効になっている。(※2)
(3) そのリスナーのプロトコル種別が nio（既定値。type属性を省略した場合も
同じ）である。(※3)
(4) SSL/TLSが有効（security-enabled="true" と ssl要素の定義がある）である。(※4)
(5) TLS 1.3が有効（ssl要素の tls13-enabled の既定値は有効）で、クライアント
がTLS 1.3で接続する。(※5)
■条件の確認方法
以下、上記「脆弱性に該当する条件」の(1)～(5)に対応する確認方法です。
確認方法詳細の「https-protocol」「http-listener-2」は標準のプロトコル名・
リスナー名です。お客様環境で名称を変更している場合は、実際の名前を確認の上、
読み替えてください。
(※1) Javaベースの内蔵Webサーバを利用しているかどうかの確認方法
以下のFAQをご参照ください。
【WebOTX Application Server】利用しているWebサーバの確認方法 (OTX-FAQ-000832)
(※2) ネットワークリスナーの有効/無効の確認方法
otxadmin> get server.network-config.network-listeners.network-listener.http-listener-2.enabled
→ "true" であれば対象。"false" なら対象外。
(※3) プロトコル種別の確認方法
otxadmin> get server.network-config.protocols.protocol.https-protocol.type
→ "nio" であれば対象。"ajp"/"tpm" なら対象外。
(※4) SSL/TLS有効化の確認方法
otxadmin> get server.network-config.protocols.protocol.https-protocol.security-enabled
otxadmin> get server.network-config.protocols.protocol.https-protocol.ssl.*
→ security-enabled="true" かつ ssl配下の属性が表示されれば対象。
security-enabled="false" もしくは sslの結果が "not found" であれば対象外。
(※5) TLS 1.3有効化の確認方法
otxadmin> get server.network-config.protocols.protocol.https-protocol.ssl.tls13-enabled
→ "true" であれば対象。"false" なら対象外。
[脆弱性の影響]
TLS 1.3で接続したクライアントの接続が、断続的に失敗する可能性があります。
影響は可用性(接続できなくなること)に限られ、情報の漏えいや改ざんは報告されていません。TLS 1.2以下の接続は対象外です。再接続(リトライ)で接続できる場合があります。
【CVE-2026-88041】
[脆弱性の概要]
HTTP/2の処理で、前のリクエストのtrailer(本文の後に送られる付加ヘッダ)に関する情報の後始末が不完全です。そのため、複数のリクエストを同時に処理しているときに、ごく狭いタイミングで競合した場合にのみ、前のリクエストのtrailerが消去されずに残り、後続のリクエストのtrailerとして読み取られてしまうことがあります。
[脆弱性に該当する条件]
以下の全ての条件を満たした場合に該当します（条件の確認方法は、各項目末尾の
(※1)～(※4)に対応する「条件の確認方法」をご参照ください）。
(1) Javaベースの内蔵Webサーバが、クライアントからのHTTP/2接続を直接処理
している。(※1)
(2) 該当するネットワークリスナーが有効になっている。(※2)
(3) そのリスナーが参照しているプロトコルが、HTTP/2用のプロトコル
（UpgradeProtocol#className に org.apache.coyote.http2.Http2Protocol
を設定したもの）になっている。(※3)
(4) 同一接続でtrailer付きのリクエストが処理され、前後のリクエストの
処理が競合する。(※4)
(5) 後続のリクエストを処理するアプリケーションが、trailerを参照する。(※4)
■条件の確認方法
以下、上記「脆弱性に該当する条件」の(1)～(5)に対応する確認方法です。
確認方法詳細の「https-protocol」「http-listener-2」は標準のプロトコル名・
リスナー名です。お客様環境で名称を変更している場合は、実際の名前を確認の上、
読み替えてください。
(※1) Javaベースの内蔵Webサーバを利用しているかどうかの確認方法
以下のFAQをご参照ください。
【WebOTX Application Server】利用しているWebサーバの確認方法 (OTX-FAQ-000832)
(※2) ネットワークリスナーの有効/無効の確認方法
otxadmin> get server.network-config.network-listeners.network-listener.http-listener-2.enabled
→ enabled属性が無ければ既定で有効、"false"なら対象外。
(※3) HTTP/2用プロトコルの設定確認方法
① そのリスナーが参照しているプロトコル名の確認
otxadmin> get server.network-config.network-listeners.network-listener.http-listener-2.protocol
② ①のプロトコルのhttp要素version属性の確認
otxadmin> get server.network-config.protocols.protocol.nio-http2-protocol.http.version
③ ①のプロトコルのssl要素配下のUpgradeProtocol#classNameの確認
otxadmin> get "server.network-config.protocols.protocol.nio-http2-protocol.ssl.property.UpgradeProtocol#className"
→ ②が"HTTP/2.0"、③が"org.apache.coyote.http2.Http2Protocol"であれば、
①のプロトコルはHTTP/2用です。標準の設定では、どのネットワーク
リスナーも"nio-http2-protocol"を参照しておらず、HTTP/2は無効です。
(※4) trailerとは本文の送信が終わった後に送信される、ヘッダと同じ形式（名前と値の組）
の付加情報です。本文の内容を全て送り終えた後でなければ値が決まらない情報
（本文のチェックサム、処理結果のステータスなど）を伝える用途で使われます。
実際にtrailerヘッダを含んだリクエストが発生するか、
HttpServletRequest#getTrailerFields() 等を使用しているかは、アプリケーションの
開発担当にご確認ください。
（例）リクエストのtrailerの例（本脆弱性が対象とする方向）
クライアントがサーバへ、送信するデータ（本文）の後に、送信済みの本文
から計算したダイジェスト値をtrailerとして送る場合：
POST /upload HTTP/2
content-type: application/octet-stream
trailer: digest
（↑本文の前に、どのtrailerを送るかを予告するヘッダ）
（本文データ…）
digest: sha-256=...
（↑本文をすべて送り終えた後に送られるtrailer。サーバ側の
アプリケーションは HttpServletRequest#getTrailerFields() で
この値を参照する）
[脆弱性の影響]
前のリクエストのtrailerに関する情報が、後続のリクエストの処理に混入し、後続のリクエストを処理するアプリケーションに渡される可能性があります。
【CVE-2026-80353】
[脆弱性の概要]
APRコネクタがUnixドメインソケットを作成するとき、先にソケットを作成して接続の受け付けを開始し、その後でアクセス権限（所有者以外は接続できないようにする制限）を設定する順序になっています。
そのため、作成から権限の設定が完了するまでのわずかな間、ソケットには制限がかからず、OSの既定の権限（umask）のままとなります。
[脆弱性に該当する条件]
以下の全ての条件を満たした場合に該当します。
- マニュアル「リファレンス＞設定＞4.Webコンテナ＞4.11. HTTP/2の利用方法」の手順で、
Webコンテナのコネクタ（プロトコルの種別）をネイティブライブラリ(APR)を使用する apr に
変更している。(WebOTXで apr を使用するのはこのHTTP/2利用の手順のみです)。
- そのコネクタの設定で、プロパティ unixDomainSocketPath を追加で指定し、Unixドメインソケットで
待ち受けている（HTTP/2利用の手順だけでは、このプロパティは設定されません）。
- WebOTXをLinux等のUNIX系OS上で動作させている。
- ソケットの作成先ディレクトリが、他の一般ユーザーから到達できる状態にある。
- 同じホスト上に、悪意を持ちうる一般ユーザーが存在する。
[プロパティの設定例]
<protocol name="apr-http2-protocol" type="apr">
<http default-virtual-server="server">
<property name="unixDomainSocketPath" value="/var/run/sample/webotx.sock"></property>
</http>
</protocol>
- otxadminコマンドで設定する場合の例）
otxadmin set "server.network-config.protocols.protocol.apr-http2-protocol.http.property.
unixDomainSocketPath=/var/run/sample/webotx.sock"
※WebOTXの標準の設定では、HTTP/2利用のためのAPRコネクタへの変更、Unixドメインソケットの
指定のいずれも行われていません。標準の設定のままご使用の場合は、本脆弱性の影響を受けません。
[脆弱性の影響]
ソケットの作成とアクセス権限の設定の間に、同じホスト上の権限のないローカルユーザーが、そのソケットへ接続できる可能性があります。ネットワーク経由の攻撃は対象外で、同じホスト上にローカルユーザーがいる場合に限ります。
【CVE-2026-74049】
[脆弱性の概要]
JSPの高速化の仕組み(タグプラグイン)で<c:redirect>を置き換えた場合、リダイレクトを指示した後に、ページの処理を終了する動作が組み込まれていません。
[脆弱性に該当する条件]
以下の全ての条件を満たした場合に該当します。
- JSPでJSTLのc:redirectタグを使用している。
- アプリケーションの WEB-INF/tagPlugins.xml かMETA-INF/org.apache.jasper/tagPlugins.xml
で、c:redirectタグ用のプラグインを明示的に登録している。
- c:redirectタグより後ろに、リダイレクト後に実行されると問題となる処理
（更新処理など）が記述されている。
[プラグインの定義例]
<tag-plugins>
<tag-plugin>
<tag-class>org.apache.taglibs.standard.tag.rt.core.RedirectTag</tag-class>
<plugin-class>org.apache.jasper.tagplugins.jstl.core.Redirect</plugin-class>
</tag-plugin>
</tag-plugins>
※WebOTX V8.xでは、META-INF/org.apache.jasper/tagPlugins.xmlを読む機能が存在しないため、WEB-INF/tagPlugins.xml のみが条件となります。
[脆弱性の影響]
プラグインを登録している場合、リダイレクトを指示した後も、同じJSPの残りの処理が最後まで実行されます。例えば、<c:redirect>の直後に、認可チェックの後のデータ更新などがあると、利用者がリダイレクトされるだけで、更新処理が実行されてしまいます。
プラグインを登録していない場合(WebOTXの標準構成)は、この影響を受けません。