Oracleが10月の大規模修正を公開！Web基盤の更新漏れをどう減らすか

Oracleは2026年10月20日、10月のCritical Patch Update（CPU）を公開しました。公式勧告は製品群全体で1,295件の新しいセキュリティパッチを含むと説明し、サポート中のバージョンを使い、修正を遅滞なく適用するよう求めています。これは単一製品に1,295件の問題があるという意味ではありません。自社の製品、部品、構成に対応する行を読む必要があります。

本稿は10月21日に確認した未掲載の更新情報です。新たな被害が判明したという速報ではありません。既に公表された脆弱性への修正が残るWeb基盤を整理し、保守担当が具体的な更新計画を作るための考え方を解説します。以下の作業順序と構成例は本サイトの提案であり、Oracleがすべての環境へ同じ停止手順を指示しているわけではありません。

一次資料：Oracle Critical Patch Update Advisory October 2026。以下の運用手順と仮想例は本サイトの提案です。

パッチ件数と自社への影響を分けて読む

CPUのAffected Products and Versionsは対象の製品と系列を確認する入口です。Risk MatrixはCVE、部品、プロトコル、認証なしの遠隔悪用可否、CVSS、対象版を対応付けています。製品名だけで一覧を閉じず、実際に稼働するコンポーネントまで照合します。未使用の部品かどうかを判断する際も、管理者の記憶だけでなく配備物や設定を確認してください。

たとえばFusion Middlewareの表には206件の新規パッチがあり、そのうち134件について認証不要で遠隔から悪用される可能性が示されています。この数は同製品群の集計であり、すべてがWebLogicの同じ入口へ適用される評価ではありません。HTTP、T3、IIOPなどの違いを無視すると、Webの入口を制限しただけで全対応が済んだと誤解するおそれがあります。

OracleはCPUが通常は累積的である一方、今回の表は前回以降に追加された修正を説明するものだとしています。長期間更新していない環境では、今回の一覧だけを読んでも過去の未適用事項を説明できません。直前の適用履歴、必要な前提パッチ、提供元のインストール手順を合わせて確認します。

製品の下にある部品へ担当者を割り当てる

Webアプリの運用では、アプリ担当、Java担当、ミドルウェア担当、DB担当、クラウド担当が異なることがあります。一人が本体を更新しても、同梱のライブラリーや別のOracle Homeにある部品が残る可能性があります。台帳はホスト名だけでなく、インストール先、稼働プロセス、利用アプリ、保守責任者を一組で持つことを勧めます。

公式勧告はE-Business SuiteやEnterprise Managerについて、利用しているDatabaseやFusion Middlewareの脆弱性も影響し得ると説明しています。それらの更新は各製品のRisk Matrixだけには載らないため、基盤側の項目を別途確認する必要があります。アプリ名で検索して該当件数が少ないから安全だと判断すると、この依存関係を落とします。

説明用の仮想例として、会員サイトがWebLogic上で動き、別のジョブがJavaでファイルを取り込み、管理システムが同じDBへ接続している構成を考えます。会員サイトの表示試験だけでは、ジョブのJavaと管理システムの接続ドライバーの状態を確認できません。更新対象をアプリの画面単位だけで管理しない理由です。

優先順位は到達性と権限から決める

本サイトでは、対象版が一致する項目のうち、外部や委託先ネットワークから到達でき、認証なしで悪用される可能性のある経路を先に確認することを提案します。次に、認証情報が侵害された場合の権限、保存データ、他システムへの接続を調べます。CVSSの大きさだけで全台を一列に並べるより、実際の露出を説明しやすくなります。

管理コンソールの公開制限は有効な防御層ですが、製品更新の代わりではありません。アプリ経由で到達する機能やサーバー間のプロトコルもあります。制限を追加する場合は、必要な監視、クラスターメンバー、デプロイ経路を止めないかを確認し、許可された接続元を明確にします。

個別CVEの悪用状況が勧告に書かれていない場合、本稿では不明として扱います。Oracleが過去に修正済みの問題を狙う攻撃について一般的に警告していることを、今回の全CVEが悪用中だという意味へ拡張してはいけません。対応の緊急度と被害の断定は別の判断です。

更新前に用意する検証と切り戻し

最初に利用中の系列と導入パッチを記録し、対象のPatch Availability Documentを確認します。具体的な配布物や適用手順にはサポート認証が必要な場合があります。本稿ではその中の未閲覧手順を推測して案内しません。権限を持つ担当が公式手順を読み、前提条件、停止対象、ディスク容量、再起動の要否を確定してください。

バックアップにはデータだけでなく設定、証明書の参照、起動パラメーター、ドライバー、デプロイ成果物を含めます。戻す単位がDBとアプリで異なると、片方だけ旧状態へ戻して不整合を作る場合があります。更新中の書き込みをどう止めるか、再送されたジョブをどう扱うかも切り戻し計画に入れます。

ステージングではログイン、検索、更新、ファイル入出力、外部API、バッチ、証明書を使う通信を確認します。大量データや長時間ジョブが重要な環境では、小さな動作確認に加えて代表的な負荷の試験を用意します。単に管理画面が開いたという結果を業務全体の成功として扱わないことが大切です。

適用後は稼働実体と依存先を確認する

適用ログの成功だけでなく、サービスが修正済みの場所から起動しているかを確認します。古いOracle HomeやJDKを起動スクリプトが参照していないか、待機系のノードに旧版が残っていないかを調べます。更新後のプロセス、パッチ一覧、代表業務の試験結果を同じ作業票に対応付けて残します。

自動再作成されるサーバーやコンテナでは、現行環境だけを直しても古いテンプレートから戻る可能性があります。ゴールデンイメージ、構成管理、災害復旧環境の更新を別タスクとして管理します。休止中の環境には、次に公開する前に同じ確認を通す条件を付けます。

更新に伴って通知が止まる、接続プールが再作成される、ジョブが再実行されるなどの挙動は、業務上の誤処理にもつながります。検証担当はアプリのログだけでなく、メールの到達、キューの滞留、外部決済や連携先への送信結果も確かめます。試験には本物の決済や個人情報を無計画に使わず、承認済みの検証用データを使います。

更新できない項目を完了にしない

保守契約、互換性、停止時間の制約で即時更新できない場合は、理由、対象の入口、暫定制限、責任者、実施期限を残します。ネットワーク制限がどのCVEの条件を減らすかまで対応付ければ、単に「WAFあり」と記録するより判断を引き継げます。例外を永久承認にしないよう、見直しの条件も決めます。

複数の担当へ渡す更新計画の具体例

仮想の企業サイトで、WebLogicの上に会員機能、別サーバーにREST連携、DB側に夜間集計があるとします。このとき、サイト運営者は公開停止の時間、ミドルウェア担当は導入手順、DB担当は整合性、アプリ担当は業務試験を受け持ちます。作業を一つの「Oracle更新」にまとめるより、停止と再開の依存関係を決めやすくなります。

変更票には、先行作業、停止の合図、実行する担当、成功を確かめる担当を記載します。更新処理の担当者が成功ログを確認した後、別の担当が代表業務を試験する流れにすれば、インストールと業務復旧を同じ判断で閉じずに済みます。夜間作業で担当が交代するなら、口頭だけで引き継がないことが重要です。

外部接続が多い環境では、接続先の検証窓口も事前に確保します。送信元のJavaやTLS設定が変わったとき、接続できない原因が相手の制限なのか自社の設定なのかを調べられるようにします。失敗した要求を無制限に再送すると、二重処理や相手側の負荷につながるため、業務の再実行条件も確認します。

適用できなかった製品は、対象外と別の状態で残します。サポート認証がなく資材を取得できない、互換性試験が未完了、停止時間を確保できないなど、理由によって次の行動が違います。担当と期限を付け、暫定制限がどこまでリスクを減らすかを説明できるようにしてください。

クラウド上のOracle製品でも、提供元が更新する範囲と顧客が管理する範囲はサービスごとに違います。仮想マシン上へ自社導入したソフトと、管理されたサービスを同じ責任分担で扱わず、契約と公式の更新方針を確認します。事業者から更新完了の連絡を受けた場合も、利用側の接続試験と未更新の関連部品の確認を残します。

最後に、次回のCPUで再利用できる情報を整理します。製品と部品の対応、更新に必要だった時間、業務試験の項目、失敗しやすかった接続を残せば、次の判断を早められます。今回の個別番号を永久に使うのではなく、台帳と確認手順を維持することが、継続的な更新の基盤になります。

一方、ログに不審な操作や未知の成果物がある場合、更新計画とは別に侵害対応が必要です。パッチは既存の侵入痕跡や漏えい済み資格情報を取り除きません。作業前の証拠を保全し、対象を隔離する判断を組織の対応手順へ接続します。問題がないと結論する際も、調査対象とログの保存範囲を明記します。

今回のCPUを処理する実務上の成果は、パッチの件数を消化することだけではありません。どの製品の、どの部品を、誰が更新し、どの業務で正常性を確かめたかを説明できる状態です。製品別一覧と依存関係の両方を使い、公開経路から復旧用イメージまで更新漏れを減らしてください。