修正から7か月後に是正期限3日 — Oracle の CVE-2026-21962 が示す「パッチ済み」の落とし穴
脆弱性対応の話をするとき、わたしたちはつい「修正が出たかどうか」を軸に考える。出ていれば対処可能、出ていなければ回避策を探す、という具合に。
ところが修正が7か月前から出ているのに、いま緊急で叩かれているという脆弱性がある。Oracle の CVE-2026-21962 だ。CISA が 2026年8月24日に KEV(Known Exploited Vulnerabilities)カタログへ追加し、是正期限を 2026年8月27日 に設定した。追加から期限まで3日である。
修正はどこにあるか。2026年1月の Oracle Critical Patch Update(cpujan2026)に、とっくに入っている。
この記事では、この時間差が何を意味するのか、そして自分の環境が該当するかをどう確かめるのかを整理する。掲載は 脆弱性対応ウォッチ にもある。
何の脆弱性か
対象は Oracle Fusion Middleware の Oracle HTTP Server と Oracle WebLogic Server Proxy Plug-in である。コンポーネントとしては、Apache HTTP Server 用と IIS 用の WebLogic Server Proxy Plug-in が該当する。
該当バージョンは次のとおり。
| 製品 | 該当バージョン |
|---|---|
| Oracle HTTP Server / Proxy Plug-in(Apache 用) | 12.2.1.4.0 / 14.1.1.0.0 / 14.1.2.0.0 |
| WebLogic Server Proxy Plug-in(IIS 用) | 12.2.1.4.0 のみ |
CVSS 3.1 は 10.0、ベクタは AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N(NVD)。CWE は CWE-284(不適切なアクセス制御)。
このベクタは3か所を読めば足りる。
PR:N/UI:N — 認証も利用者操作も要らない。攻撃者は HTTP を投げるだけでよい。
S:C(スコープ変更) — ここが本題である。Oracle の記述は「脆弱性は Oracle HTTP Server / Proxy Plug-in にあるが、攻撃は他の製品にも重大な影響を及ぼしうる」としている。プロキシの背後にいる WebLogic のアプリケーションまでが射程に入るということだ。プロキシは前段だから被害も前段で止まる、という直感が通じない。
A:N — 可用性への影響は無い。つまりこれは「止められる」脆弱性ではなく、「読まれる・書き換えられる」脆弱性である。落ちないので、気づきにくい。
時間差が本題
時系列を並べる。
| 日付 | 出来事 |
|---|---|
| 2026-01-20 | CVE 公開。修正は同月の CPU(cpujan2026)に含まれる |
| 2026-01 以降 | PoC 公開後に最初の攻撃が観測されたと報告される |
| 2026-07 | 国家背景の攻撃者が政府インフラへの攻撃で悪用していたと報告される |
| 2026-08-24 | CISA が KEV カタログへ追加。是正期限 2026-08-27 |
KEV への追加は「実際に悪用されている」ことの確認を意味する。修正の不在ではなく、適用の不在が理由で緊急扱いになったわけだ。
ここから引き出せる教訓はひとつしかない。「CPU を当てている」は「最新の CPU を当てている」ではない。 Oracle の CPU は四半期ごとに出て累積する。1月の CPU 以降どれか1回でも当てていれば本件は塞がっている。逆に言えば、2025年10月の CPU で止まっている環境は、7か月間ずっと開いたままだった。
そして厄介なのは、この手のリバースプロキシが「一度組んだら触らない」構成要素だという点である。アプリケーションサーバは更新計画に乗るが、その前段の Oracle HTTP Server は「動いているので触らない」になりやすい。
該当するかを確かめる
順番が大事だ。バージョンを調べる前に、そもそも使っているかを調べるほうが速い。多くの環境はここで対象外になる。
1. プラグインを使っているか
Apache HTTP Server 側なら、設定ファイルに WebLogic プラグインのモジュールが読み込まれているかを見る。
1 | |
LoadModule weblogic_module .../mod_wl_ohs.so のような行、あるいは <IfModule weblogic_module> ブロックが出てくれば使っている。1行も出なければ、その Apache は対象外だ。
IIS 側は iisproxy.dll を ISAPI フィルタとして登録している構成が該当する。こちらは 12.2.1.4.0 のみが対象なので、14.x で運用しているなら IIS 側は外れる。
1 | |
2. どの CPU まで当たっているか
Oracle ホームに当たっているパッチは OPatch で一覧できる。
1 | |
出力の Interim patches に並ぶパッチ番号と適用日を見る。2026年1月以降の CPU が1つも無ければ該当と考えてよい。判断に迷うときは、Oracle のセキュリティアラート一覧(Critical Patch Updates)で cpujan2026 以降の該当パッチ番号を照合する。
バージョン自体は次で確認できる。
1 | |
3. 外向きから先に直す
AV:N/PR:N なので、インターネットに面したプロキシがそのまま攻撃面である。台数が多いなら、外向きを先に、内部専用を後に回す。優先順位づけの実務としてはこれで十分だ。
回避策は無い
公表された回避策は存在しない。到達元をファイアウォールで絞ることは攻撃面の縮小にはなるが、Oracle が示した回避策ではないので「対処した」とは言えない。CPU を当てる以外の道は無い。
CPU の適用はプラグインのバイナリ差し替えを伴うため、Apache または IIS の再起動が要る。無停止では終わらないので、停止時間の調整から始めることになる。
パッチを当てて終わりにしない
最後にひとつ。KEV の要求アクションは、パッチ適用だけでなく CISA の「Forensics Triage Requirements」への準拠にも触れている。
理由は単純で、パッチは今後の侵入を止めるだけだからである。2026年1月から8月までのあいだ、未パッチのまま外部に露出していた期間があるなら、その期間にすでに入られていた可能性は消えない。悪用は1月から観測されているのだ。
したがって、該当した環境では次の2つを分けて考える必要がある。
- 塞ぐ — cpujan2026 以降の CPU を適用する
- 見る — 未パッチかつ露出していた期間のアクセスログを遡る
とくに S:C(スコープ変更)である以上、見る対象はプロキシのログだけでは足りない。背後の WebLogic アプリケーション側のログも同じ期間で確認する。プロキシを踏み台にして後段へ届いた痕跡は、前段のログだけでは形にならないことがある。
まとめ
- CVE-2026-21962 は 2026年1月の CPU で修正済み。それでも8月24日に KEV 入りし、期限は3日後だった
- 緊急扱いの理由は修正の不在ではなく適用の不在である
S:Cなので、プロキシの前段で被害が止まる前提は成り立たないA:Nなので落ちない。落ちないから気づかない- 回避策は無く、CPU 適用のみ。加えて露出していた期間のログを遡る必要がある
「四半期パッチを運用に組み込んでいる」と言えるかどうかは、直近1回を当てたかではなく、当て続けているかで決まる。この CVE はそれを7か月ぶんの時間差で示した事例である。