CISAがOracle Identity Managerのゼロデイ脆弱性を警告
アメリカ合衆国のサイバーセキュリティおよびインフラセキュリティ庁(CISA)は、Oracle Identity Managerに影響を与える重大な脆弱性CVE-2025-61757を、既知の悪用脆弱性リストに追加しました。この脆弱性は、認証が欠如しているため、未認証のリモート攻撃者がシステムを乗っ取る可能性があります。具体的には、特定のAPIエンドポイントにアクセスすることで、認証フローを操作し、権限を昇格させ、組織のコアシステム内を横移動することが可能です。CISAは、連邦政府機関に対し、2025年12月12日までに必要なパッチを適用するよう求めています。
メトリクス
このニュースのスケール度合い
インパクト
予想外またはユニーク度
脅威に備える準備が必要な期間が時間的にどれだけ近いか
このニュースで行動が起きる/起こすべき度合い
主なポイント
- ✓ CISAは、Oracle Identity Managerの脆弱性CVE-2025-61757が悪用されていると警告しています。
- ✓ この脆弱性は、未認証のリモートコード実行を可能にし、早急な対策が求められています。
社会的影響
- ! この脆弱性の悪用は、企業のセキュリティに深刻な影響を及ぼす可能性があります。
- ! 特に、重要なシステムが攻撃を受けることで、顧客データや機密情報が危険にさらされる恐れがあります。
編集長の意見
解説
CISAがOracle Identity Managerの未認証RCE(CVE-2025-61757)をKEVに追加、12/12期限で是正要求—ID基盤直撃の攻撃連鎖をどう断つかです
今日の深掘りポイント
- ID基盤(Oracle Identity Manager, OIM)の未認証リモートコード実行が確認悪用となり、CISAのKEVに登録され、米連邦機関に12月12日までの是正期限が課された事実が重いです
- OIMは特権アカウントの発行・権限付与の“統制平面”であり、1台の侵害がADやERP、SaaS全体の権限拡大に波及しやすいです
- 日本企業にとっては自社OIMだけでなく、委託先・SIer・BPOが運用するOIMの是正状況がサプライチェーンリスクの支点になります
- 技術詳細が限定的な現時点でも、暫定的な封じ込め(公開面の遮断、境界の強化、監視の重点化)と、OIM経由の「権限変更・アカウント作成」の後追い監査は即時に着手すべきです
- 短期の是正はパッチ適用と到達経路の遮断、中期はコネクタ資格情報・キーストアの総入れ替え、長期はID統制の冗長化(Break-glass運用、ゼロトラスト化)で再発の事業影響を最小化すべきです
はじめに
米国CISAは、Oracle Identity Manager(OIM)に影響する重大な欠陥CVE-2025-61757を既知の悪用脆弱性(KEV)カタログに追加し、連邦政府機関に対して2025年12月12日までの是正を指示しています。既に実運用環境での悪用が確認され、未認証のリモート攻撃者が特定APIにアクセスして認証フローを操作しうる性質と報じられています。OIMは企業のIDライフサイクルや権限付与の中枢を担うため、侵害時の横移動と権限昇格の“飛び地”が格段に広がるのが最大の特徴です。緊急パッチの適用に加え、IDガバナンスの監査・復旧計画まで一気通貫で見直す局面に来ていると捉えるべきです。
出典として、CISAのKEVカタログ追加と是正期限については、業界報道がCISAの公表に基づき伝えています。また、KEVカタログの一次情報はCISAの公開ページから参照可能です。The Hacker Newsの報道およびCISA Known Exploited Vulnerabilities Catalogを確認してください。
深掘り詳細
事実関係(一次情報に基づく整理)
- CISAはOracle Identity Managerに関するCVE-2025-61757をKEVに追加し、連邦機関に対し2025年12月12日までの是正を求めています。KEVは「実際に悪用されている」脆弱性のみが掲載され、期限付きでの是正要求が付される点が特徴です
- 報道は、未認証のリモート攻撃によって認証フローの操作や権限昇格、横移動に至りうる点を伝えています。悪用の観測期間についても具体的な記載があり、複数ソースからの攻撃が把握されているとされています
- Oracle側の是正は、通常はCritical Patch Update(CPU)やセキュリティアラートで提供されます。対象バージョンや適用手順はOracle公式アドバイザリで確認するのが確実です
現時点で公開情報は限定的であり、技術的詳細(影響する正確なエンドポイント、バージョン範囲、CVSS等)はOracle公式アドバイザリやCISAのKEVエントリ更新を継続的に確認するのが適切です。
インサイト(リスクの質と運用面の痛点)
- ID統制平面の一撃は事業影響の“乗数”です
OIMはADやERP、SaaSへのアカウント発行・権限付与・ロール管理を司るため、ここを踏み台にされると「権限の不正付与」「特権の横流し」「自動プロビジョニングの悪用」が連鎖しやすいです。EDRやMFAが末端で効いていても、上位のID統制が乗っ取られると無力化される局面が生じます。 - 外部非公開でも“実質外部面”になりやすいです
OIMのセルフサービスや管理コンソールは、社外委託、B2B接続、ゼロトラスト境界越しの到達点になりがちです。完全に閉域としても、VPNやリバースプロキシ、SSOゲートウェイを介した“事実上の公開面”として機能しているケースが少なくありません。露出の認識ギャップが初動遅延につながるため、到達経路の棚卸しから始めるべきです。 - サプライチェーンの“権限継承”を見落とさないことが肝要です
SIerやBPOが顧客複数社のID管理をOIMで一元運用している場合、1つのOIM侵害が複数顧客の権限へ連鎖する構造的リスクがあります。今回のように是正期限が明示されると、調達・委託契約の遵守事項として波及し、監査可能な形での対策状況の提出が求められる可能性が高いです。 - メトリクス観点の総合判断
悪用確認済みで是正期限が短いことから、即時性と行動可能性は非常に高いと評価できます。一方で、技術詳細が限定的で検知ルールを即座に高精度化しづらい側面があります。したがって、当面は露出面の遮断と権限変更イベントの監査を“幅広く・早く”走らせ、詳細が出次第で特定エンドポイントやシグネチャに寄せる二段構えが合理的です。
脅威シナリオと影響
以下は現時点の公開情報に基づく仮説シナリオであり、具体の侵入手口や環境差により変動します。MITRE ATT&CKの戦術・技術は代表例として整理します。
-
シナリオ1:公開OIMセルフサービス面からの初期侵入です
- 公開・準公開のOIMエンドポイントに対し未認証RCEを悪用(Initial Access: T1190 Exploit Public-Facing Application)
- OIM/アプリ基盤上での権限昇格(Privilege Escalation: T1068 Exploitation for Privilege Escalation)
- 構成・接続情報から資格情報取得(Credential Access: T1552.001 Credentials in Files, T1555 Credentials from Password Stores)
- OIMコネクタを通じて下流のAD/ERP/SaaSへアカウント作成・権限付与(Persistence/Privilege Escalation: T1098 Account Manipulation, T1136 Create Account)
- 組織横断の横移動(Lateral Movement: T1021 Remote Services)
- IDストアや権限台帳の持ち出し(Collection/Exfiltration: T1213 Data from Information Repositories, T1041 Exfiltration Over C2 Channel)です
-
シナリオ2:内部侵入後の特権拡大ハブとしての悪用です
- 別経路で社内侵入済みの攻撃者がOIMに到達し脆弱性を悪用(Privilege Escalation: T1068)
- WebLogic/DB接続のキーストア・設定から機密抽出(Credential Access: T1552, Discovery: T1082 System Information Discovery)
- 権限ワークフローのバイパスや承認者アカウントのなりすまし(Defense Evasion/Privilege Escalation: T1556 Modify Authentication Process, T1078 Valid Accounts)です
-
シナリオ3:委託先のOIMから複数顧客へ波及するサプライチェーン事案です
- MSSP/BPOのOIMが侵害され、管理下複数テナントの権限操作に悪用(Impact/Lateral Movement: T1199 Trusted Relationship)
- 顧客環境側でのアカウント自動プロビジョニングを踏み台に展開(Privilege Escalation/Persistence: T1098, T1136)です
影響は、単一システムの停止に留まらず、事業横断の権限不正・データアクセス・認証基盤の信頼性毀損へ拡大しやすいです。復旧には「技術的封じ込め+権限の完全性回復+監査証跡の整合」を同時並行で進める負荷が生じ、ダウンタイムよりも“権限再信頼構築”のコストが支配的になり得ます。
セキュリティ担当者のアクション
優先度高(0–72時間)
- 到達経路の遮断です
- OIM関連の公開・準公開エンドポイントの一時閉塞、IP制限、mTLSやVPN強制での段階的封鎖を実施します
- WAF/リバプロでOIM特定パス群への未認証アクセスをブロックし、例外は業務影響を評価したうえで最小化します
- パッチとベンダー通達です
- Oracle公式アドバイザリを確認し、該当環境へ速やかにパッチまたはベンダー推奨の緩和策を適用します
- 委託先・運用受託ベンダーにKEV是正期限を含む即応通達を発出し、適用計画と完了エビデンスの提出を求めます
- 侵害有無の一次確認です
- 直近数週間のOIMアクセスログ、リバプロ/WAFログ、サーバ監査ログを横断し、未認証要求の急増、異常な応答コード、管理系APIへのアクセスを重点確認します
- OIM経由の「新規アカウント作成」「ロール大量付与」「権限昇格」「承認フロー無視」などのイベントを抽出し、人事データやITSM記録と突合します
中期(3–10日)
- 資格情報と秘密情報の総入れ替えです
- OIMサーバ、WebLogicドメイン、OIM DBスキーマ、コネクタ用サービスアカウント、各種キーストア/トラストストアのローテーションを計画的に実施します
- 回復後の再侵入防止として、特権アカウントに強固なMFAとネットワーク境界制御を適用します
- 監視と検知の精緻化です
- 攻撃前兆のKPI(失敗要求の急増、未認証200応答、既知URIパスへのスキャン)と、攻撃後兆候のKPI(権限付与スパイク、承認ワークフローの逸脱、コネクタ実行異常)を分けてダッシュボード化します
- MITRE ATT&CKに沿った検知コンテンツをSOCで整備し、T1190/T1098/T1136/T1552/T1021/T1556の検知カバレッジを棚卸します
長期(2–6週間)
- アーキテクチャの是正です
- OIMの管理面・セルフサービス面をゼロトラスト化(明示的許可、デバイス信頼、連続認証)し、公開前提の設計をやめます
- ID統制の冗長化として、Break-glass手順と監査耐性(付与系イベントのWORM保管、外部SIEMへの不可逆転送)を標準化します
- サプライチェーン管理です
- 委託先のID基盤(OIM含む)の構成・パッチSLO・侵害時連絡SLAを契約条件に織り込み、年次監査で検証します
- 連邦期限やKEV準拠を契約条項にマッピングし、是正遅延時の代替措置を明文化します
補足:メトリクス評価の示唆
- 悪用確認済みかつ是正期限が設定された事案は、対応の即時性と行動可能性が特に高いとみなすべきです。一方で、技術詳細が未確定の部分があるため、検知を“広めに貼る”初動と、後で“狭める”調整を前提に運用計画を立てると実務上のムダが減ります。さらに、今回はID統制層の脆弱性であるため、通常のサーバ脆弱性よりも権限の完全性回復に時間がかかる点を経営へ先に説明し、復旧KPIを「パッチ適用率」だけでなく「不正権限の是正率」「資格情報ローテーション完了率」「承認ワークフロー健全性」で併走させるのが有効です。
参考情報
- CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
- The Hacker News: CISA Warns of Actively Exploited Oracle Identity Manager Zero-Day: https://thehackernews.com/2025/11/cisa-warns-of-actively-exploited.html
- Oracle Security Alerts / Critical Patch Update ポータル: https://www.oracle.com/security-alerts/
本稿は公開一次情報およびそれに基づく報道に依拠し、未確定事項は仮説として記述しています。最新の技術詳細や影響バージョンは、CISAのKEVエントリとOracle公式アドバイザリの更新を必ず確認してください。
背景情報
- i CVE-2025-61757は、Oracle Fusion Middlewareにおける重要な機能の認証欠如に起因し、攻撃者がAPIエンドポイントにアクセスすることで、システムを乗っ取ることが可能です。この脆弱性は、特定のURIに対して不正なリクエストを行うことで発生します。
- i この脆弱性は、特にGroovyコードの構文チェック用エンドポイントに対して悪用され、特別に作成されたHTTP POSTリクエストを送信することでリモートコード実行が可能になります。