CVSS 10.0のOracleプロキシ、パッチは1月に出ていた｜KEV是正期限8月27日

結論：問うべきは「パッチを当てたか」ではなく「その層を誰が見ているか」

米国CISAは2026年8月24日、CVE-2026-21962を悪用が確認された脆弱性のカタログ（Known Exploited Vulnerabilities Catalog、以下KEV）へ追加し、米国連邦政府機関に対する是正期限を2026年8月27日と設定しました。対象はOracle Fusion MiddlewareのOracle HTTP ServerおよびOracle WebLogic Server Proxy Plug-inです。

CVSS 3.1のBase Scoreは10.0で、これは評価体系上の最大値です。Oracle自身のCritical Patch Update Advisoryが「Remote Exploit without Auth.: Yes」と示しているとおり、認証なしにネットワーク経由で悪用されうる脆弱性です。

そして重要なのは日付です。このパッチは2026年1月20日のCritical Patch Updateで公開されています。KEVに追加されたのは8月24日で、その間およそ7か月あります。公表情報から言えるのはここまでです。どの組織が適用済みで、どこが未適用だったのか、なぜ悪用に至ったのかは、CISAもOracleも公表していません。ここで確認したいのは一点だけです。対処する手段は半年以上前から存在していた。では、自社はそれを使ったのか。この記事は、Oracle製品を含む基幹システムを外部ベンダーの保守に委ねている中堅企業の経営者・情シス責任者に向けて、「この層のパッチ適用を、誰が、どうやって把握しているのか」という構造の話を扱います。

何が公表されたか

Oracle Critical Patch Update Advisory - January 2026のFusion Middlewareリスクマトリクスに記載されている内容は次のとおりです。

CISAのKEVカタログ側の記載は次のとおりです。追加日2026年8月24日、是正期限2026年8月27日、脆弱性の種別はCWE-284（不適切なアクセス制御）、ランサムウェアキャンペーンでの使用は「Unknown」。

なお、KEVへの追加は「悪用が確認された」という事実を示すものであり、特定の企業が侵害されたことを示すものではありません。具体的な攻撃手口や被害の範囲は、CISAの記載からは読み取れません。

可用性への影響がNoneであることの意味

CVSSの内訳で目を引くのは、機密性と完全性への影響がHighである一方、可用性への影響がNoneである点です。それでもBase Scoreが10.0になっているのは、Scopeが Changed だからです。

Scope: Changed とは、脆弱性のある部品の権限境界を越えて、別の部品の資源にまで影響が及びうることを指すCVSS上の評価です。ここでの脆弱性はプロキシ側にあります。CVEの説明文（採番元はOracle）は、脆弱性はOracle HTTP ServerおよびOracle WebLogic Server Proxy Plug-inにあるが、攻撃は追加の製品に重大な影響を及ぼしうる（原文は "attacks may significantly impact additional products (scope change)"）と記載しています。どの製品へ、どの経路で、どこまで及ぶのかは特定されていません。分かるのは、影響がこのプロキシ1つの中で完結しないと評価されている、ということです。

経営判断の観点から、この組み合わせは厄介です。ここで注意したいのは、A:Noneの意味です。CVSS v3.1の仕様では、Availability の None は「There is no impact to availability within the impacted component.（影響を受けるコンポーネントの可用性に影響がない。訳は筆者）」と定義されており、これはこの脆弱性の直接的な影響として可用性の低下が評価されていないという意味です。攻撃を受けた後も必ず正常に動き続けるとか、監視に一切現れないという保証ではありません。

そのうえで、経営が注意すべき点はこうなります。この脆弱性は、それ自体が停止を引き起こすものとしては評価されていない。停止を合図にして動く運用では、拾える保証がないということです。実際に何が起きるかは構成と攻撃内容しだいであり、公表情報からは分かりません。

中堅企業の情シス運用は、多くの場合「止まったら動く」体制です。停止として現れない事象は、この体制の外側に落ちます。だからこそ、障害が起きるのを待つのではなく、公開されたパッチ情報を起点に自社の適用状況を確認する運用が要ります。

なぜプロキシ層は台帳から漏れるのか

Oracle HTTP ServerやWebLogic Server Proxy Plug-inは、業務担当者が名前を見る種類の製品ではありません。利用者が使うのは「基幹システム」であり、その手前でリクエストを振り分けている層は、業務側からは存在しないのと同じです。

この見えなさが、次の3つの形で管理から抜け落ちます。

1. 資産台帳の粒度がアプリケーション単位で止まっている

「販売管理システム」「生産管理システム」という単位で台帳を作ると、その1行の裏側にあるWebサーバー、プロキシ、アプリケーションサーバー、データベース、OS、ミドルウェアの各バージョンが記録されません。脆弱性情報が出ても、自社が該当するかを判定できません。

2. 導入したベンダーしか構成を知らない

構築時にベンダーが設計し、以後は誰も触っていないという層です。社内に構成図が残っていない、あるいは残っていても更新されていないことが珍しくありません。この状態では、自社で判定しようとしても情報が足りず、結局ベンダーに問い合わせることになり、そこで時間が失われます。

3. 保守契約の適用責任が曖昧

これは実務でよく詰まる箇所です。保守契約に「障害時の対応」は書いてあっても、「ベンダーが公開したセキュリティパッチを、誰が、いつまでに適用するか」は書かれていないことがあります。書かれていない結果、ベンダーは「依頼があれば作業する」と考え、発注側は「保守料を払っているのだから当然やってくれている」と考えます。そして、どちらも自分の理解が正しいと思っているので、話し合いの機会すら生まれません。

「Oracleを使っている」と「この脆弱性の対象である」は別の話

社内で確認を進めると、話が混線しやすい箇所があります。今回の対象は3つの名前が並んでいるため、どれを指しているのかを最初に切り分けておく必要があります。

「うちはOracleのデータベースを使っているが、これは関係あるのか」という問いには、それ単体では関係がない、と答えられます。逆に、自社が「Apache HTTP Serverを使っている」と認識しているだけの場合でも、その上にWebLogic向けのProxy Plug-inが載っていれば対象になります。製品名ではなくモジュール構成まで見ないと判定できないというのが、この層の確認が面倒な理由です。

Scopeが Changed と評価されているのは、影響がこのプラグイン単体の中で完結しないと見なされているためです。どの製品へ、どの経路で及ぶのかは公表情報からは特定できません。ただ、プロキシは「守るための層」として置かれていることが多いだけに、そこが評価上の境界を越えると判断されている意味は小さくありません。

今日から3日でできる確認

期限が明日（8月27日）というのは米国連邦政府機関に対する基準であり、日本の民間企業に直接適用されるものではありません。ただし、悪用が確認されている以上、判断を先送りする理由にはなりません。次の順で進めてください。

ステップ1：該当するかを判定する（当日）

自社の基幹システムに、Oracle HTTP Server、またはApache HTTP Server／IIS上のWebLogic Server Proxy Plug-inが含まれているかを確認します。判定に必要なのは製品名とバージョンです。対象は12.2.1.4.0、14.1.1.0.0、14.1.2.0.0で、IIS版については12.2.1.4.0のみが対象です。

社内で答えが出ないなら、その事実自体が結論です。「自社の基幹システムの構成を自社で把握していない」という状態が確認できたことになります。

ステップ2：適用状況を確認する（翌日まで）

該当する場合、2026年1月のCritical Patch Updateが適用済みかを確認します。ここで聞くのは「適用しましたか」ではなく、「いつ、どのパッチセットを、どの環境に適用しましたか」です。前者はYes/Noで流されますが、後者は記録がなければ答えられません。

ステップ3：契約と体制を確認する（3日以内）

適用済みであっても未適用であっても、次の確認は必要です。保守契約書のどの条項に、セキュリティパッチの適用責任が書かれているか。書かれていない場合、次の四半期パッチはどうするのか。この2点を、契約書の現物にあたって確認します。

ベンダーへ出す質問状

次の6項目を、そのままメールに貼って送れる形にしています。回答を文書で受け取ってください。口頭の回答は記録に残らず、後日の判断材料になりません。

1. 当社の基幹システムに、Oracle HTTP Server または WebLogic Server Proxy Plug-in は含まれますか。含まれる場合、製品名・バージョン・稼働台数をご教示ください。
2. CVE-2026-21962（2026年1月Critical Patch Update）について、当社環境は影響を受けますか。判定の根拠もあわせてご教示ください。
3. 影響を受ける場合、パッチはすでに適用済みですか。適用日と適用範囲をご教示ください。未適用の場合、適用可能な最短日程をご提示ください。
4. 現在の保守契約において、Oracleが四半期ごとに公開するCritical Patch Updateの適用は、貴社の作業範囲に含まれますか。含まれる場合、根拠となる条項をご指定ください。
5. 含まれない場合、適用を依頼するときの手続き・費用・リードタイムをご教示ください。
6. 当社システムの構成図（Webサーバー、プロキシ、アプリケーションサーバー、DB、OS、各バージョン）の最新版をご提供ください。

4番と5番が本題です。この2つに即答が返ってこないなら、パッチ適用の責任が契約上どちらにあるのか、当事者間で共有されていないということです。まずそこを文書で確定させるところから始めてください。

次のCritical Patch Updateは2026年10月20日

今回の対応を単発で終わらせないために、日程を先に押さえておきます。Oracleの公式Advisoryは「Critical Patch Updateは1月・4月・7月・10月の第3火曜日に公開される」と明記しており、2026年1月版のAdvisoryは今後の予定として2026年4月21日、2026年7月21日、2026年10月20日、2027年1月19日を挙げています。

つまり、次の公開は2026年10月20日です。今日から約2か月あります。この2か月でやることは、パッチ適用そのものではなく、次のCPUが出たときに自動的に動き出す仕組みを作ることです。

最後の行を軽視しないでください。すべてのパッチをただちに適用できる企業ばかりではありません。業務影響の検証に時間がかかる、24時間稼働で停止枠が取れない、旧バージョンのアプリケーションが動かなくなる、といった事情は現実に存在します。

その場合に必要なのは、「適用していない」という空白ではなく、「検証中である／この時期に適用する／それまでの代替策はこれである」という記録です。空白と記録の違いは、事故が起きたときに決定的な差になります。前者は説明できず、後者は説明できます。

「レガシーだから危ない」ではなく「見えていないから危ない」

Oracle WebLogicのような製品を使っていること自体が問題なのではありません。Critical Patch Updateは四半期ごとに公開され、その回に該当する修正があれば対象製品向けのパッチが案内されます。対処する手段は用意されています。今回のケースでも、パッチは1月に出ていました。

注意すべきなのは、パッチが公開されたことを発注側が知る仕組みがあるかどうかです。仕組みがなければ、公開されていても適用に至らないという状態が生まれます。この構造は、製品が新しいか古いかとは関係がありません。クラウドのマネージドサービスに移行しても、責任分界の理解がなければ同じことが起こります。

したがって、この一件を「システムを刷新すべき理由」として使うのは、半分だけ正しい表現です。刷新すべきかどうかは、可用性要件、業務要件、費用、移行リスク、残存耐用年数を総合して判断します。しかし、刷新するにせよ現行を維持するにせよ、構成情報を自社が持ち、パッチ適用責任を契約で明示するという作業は、どちらの選択でも必要です。

現行維持を選ぶなら、四半期ごとのCritical Patch Updateを受け止める運用を契約に組み込む。刷新を選ぶなら、その運用コストを削減効果として見積もりに反映する。どちらの方向でも、まず必要なのは現状の可視化です。

GXOに相談できること

• 基幹システムの構成棚卸し（アプリケーション単位ではなく、ミドルウェア・OS単位まで）
• 保守契約におけるパッチ適用責任の条項確認と、第三者としての評価
• 四半期パッチを受け止める運用体制の設計と代行
• 現行維持と刷新の比較検討（費用・リスク・移行難易度）

基幹システムの現状を診断する

FAQ

KEVの期限8月27日は、日本の民間企業にも適用されますか

適用されません。KEVの是正期限は、CISAの拘束的運用指令にもとづく米国連邦政府機関向けの基準です。日本の民間企業に法的な義務はありません。ただし、期限そのものよりも「悪用が確認された」という事実のほうが重要です。自社の対応基準に翻訳するなら、「KEVに載った脆弱性で、自社に該当製品があるものは、原則として2週間以内に対応方針を決定する」といった社内ルールを作るのが実務的です。

可用性への影響がNoneなら、業務は止まらないので急がなくてよいのでは

A:Noneが示しているのは、CVSSの評価上、この脆弱性の直接的な影響として可用性の低下が計上されていないということだけです。実際に停止するかどうか、いつ気づけるかまでを保証するものではありません。そのうえで、機密性と完全性への影響がHighと評価されている以上、想定される結果はデータの窃取や改ざんです。停止という分かりやすい合図が出るとは限らない分、こちらから確認しにいく必要があります。

当社のシステムはインターネットに公開していません

公開していないのであれば、外部から直接到達される経路は限定されます。ただし、その判断の前提として「本当に公開されていないか」を確認する必要があります。テスト環境、保守用の接続経路、拠点間VPN経由の到達、クラウド上の検証環境などが、意図せず外部から見える状態になっている例は珍しくありません。構成図と実際のネットワーク到達性を突き合わせて確認してください。

Oracle製品を使っているかどうか、社内で分かりません

その状態が今回いちばん確認したかったことです。判定できないということは、脆弱性情報が出るたびに毎回ベンダーへ問い合わせるしかないということで、対応速度が構造的に遅くなります。まずは構成情報を自社の資産として受け取るところから始めてください。構成図の提供が保守作業の範囲に含まれるかは契約によって異なるため、契約書の作業範囲を確認したうえで依頼するのが確実です。

関連記事・サービス

• レガシーシステム刷新
• EOL緊急対応
• レガシー刷新の準備度診断
• 脆弱性診断
• セキュリティ運用伴走

参考情報

• CISA Known Exploited Vulnerabilities Catalog（CISA、catalogVersion 2026.08.25、2026年8月26日確認、一次情報）
• Oracle Critical Patch Update Advisory - January 2026（Oracle、2026年1月20日、2026年8月26日確認、一次情報）
• CVSS v3.1 Specification Document（FIRST、2026年8月26日確認、一次情報）
• NVD CVE-2026-21962（NIST、2026年1月20日公開・2026年8月25日更新、2026年8月26日確認。公的な脆弱性データベースであり、この件の情報源はOracle）

この記事が扱ったのは、公表されたCVSSの内訳とKEVの日付から、契約と体制について何を確認すべきかという点です。読者の環境が実際に該当するか、パッチを当てて既存アプリケーションが動き続けるかは、構成を見なければ判断できません。Oracleの製品は同じ名称でも構成の組み合わせが多岐にわたるため、判定はOracleの公式文書と保守ベンダーの回答を根拠にしてください。