Oracle Identity Manager（OIM）は、壊れるまで気づかないようなシステムである。OIMはアイデンティティをプロビジョニングし、エンタイトルメントを管理し、アクセスを発行または仲介し、多くの場合、あらゆる深刻なエンタープライズ・アプリケーションの上流に位置する。OIMに脆弱性が存在する場合、それが "単なるCVE "であることはほとんどない。CVE-2025-61757は重要な例だ。 認証されていない、ネットワーク到達可能なRCE OIMのRESTウェブサービス・コンポーネントに、ID層の完全な乗っ取りにつながる可能性がある。NVDはそれをわかりやすく要約している。 12.2.1.4.0および14.1.2.1.0搾取には 認証なしで発生する。 HTTPとなる。 ハイインパクト・コンポジット 機密性、完全性、可用性にまたがる CVSS 3.1スコア9.8（クリティカル）. (NVD)
このCVEをエンジニア級の深い読み物にする価値があるのは、その点数だけでない。 どこ それが生きている。アイデンティティ・プラットフォームは、現代企業の信頼基盤である。OIM上でコードを実行するリモートの攻撃者は、IDの偽造、役割割り当ての改ざん、または隣接するミドルウェアやアプリケーション層へのピボットから一歩先にいる。言い換えれば CVE-2025-61757はIDを乗っ取るプリミティブである。狭いアプリのバグではない。
最も引用された公的分析：このチェーンが機能する理由
一般に公開されている記事の中では、Searchlight Cyberの調査記事（「Breaking Oracle's Identity Manager: Pre-Auth RCE」）がCVE-2025-61757に関する詳細な分析として現在最も参照されており、SANSやその他のトラッカーもこれを支持している。(サーチライト・サイバー)彼らの主張の核心は、脆弱性は 二段チェーン:
- a 集中型Javaセキュリティフィルタにおける事前認証バイパス RESTの管理面を保護する
- 虐待 これらのREST APIによって公開される高プリビレッジの管理/スクリプト管理機能最終的にはリモートでコードが実行される。(サーチライト・サイバー)
正確なペイロードの仕組みは、防衛者にとって重要ではない（認可された研究室以外では繰り返すべきではない）。重要なのはパターンである。 "中央フィルター＋もろい許可リスト" 認証は、リクエストURIを許可されたホワイトリストと照合することで実施される。古いタイプのエンタープライズJavaアプリでは、これは一般的なことである。セキュリティの観点では、これは繰り返し使われるフットガンである。アクセス制御が複雑なURI解析ルールにまたがる文字列や正規表現によるマッチングに依存している場合、あなたは次のことに賭けている。 すべて 川上のコンポーネントも同じようにパスを正規化する。この賭けは負ける傾向がある。
根本原因の形状を捉える安全な方法は、ロジックの抽象化されたバージョンを見ることである：
// アンチパターンを示す擬似コード（製品コードではない）
if (request.uri.matches(ALLOWLIST_PATTERN) || request.query.equalsIgnoreCase("SPECIAL_CASE")) { // 認証をスキップする。
chain.doFilter(request, response); // 認証をスキップする。
} else {
enforceAuthentication()；
}
ひとたび攻撃者が認証ゲートを回避できるようになれば、どんな強力な管理者エンドポイントも潜在的な実行トランポリンになる。Searchlightの主な収穫は、「この特定のエンドポイントは危険だ」ということではなく、次のようなことだ。 「IAM製品のREST管理画面には、スクリプトのコンパイル、コネクターの管理、あるいは暗黙の信頼を伴うワークフローフックが含まれていることが多い。 それらが認証なしで公開されると、偶然ではなく、意図的にRCEを受けることになる。(サーチライト・サイバー)
より広範なエンジニアリングの教訓は、このCVEひとつをとっても有益である： 許可リストを使った集中型フィルターは、構造的な脆弱性のクラスである。.あなた自身のJavaサービスのコードレビュー（またはベンダーのミドルウェアの監査）を行っているのであれば、「中央許可リスト認証」を敵対的テストに値する臭いとして扱ってください。
影響を受けるバージョンとパッチのコンテキスト
Oracle 社は、以下の CVE-2025-61757 を修正した。 2025年10月クリティカルパッチアップデート（CPU）にリリースされた。 2025-10-21. (オラクル複数のトラッカーで言及されている対応バージョンは以下の通り：
| 製品 | コンポーネント | 対応バージョン | パッチライン |
|---|---|---|---|
| オラクル・アイデンティティ・マネージャー（Fusion Middleware） | REST ウェブサービス | 12.2.1.4.0, 14.1.2.1.0 | CPU 2025年10月パッチ |
これは、NVD、Wizの脆弱性DB、runZeroの暴露記事と一致している。(NVD)
微妙だが重要な運用ポイント：オラクルのCPUは四半期ごとである。オラクルのCPUは四半期ごとに更新される。CPUをきっちり確保し、ロールアウトする筋肉を持たない企業は、アイデンティティやミドルウェア・スタックに「パッチの負債」を蓄積する傾向がある。CVE-2025-61757はその前提を崩すものだ。REST管理プレーンが信頼できないネットワークからアクセス可能な場合、「次の四半期」に残しておけるバグではない。
攻撃サーフェスの現実：このCVEが高速スキャンされる理由
エクスプロイトの詳細を論じなくとも、CVSSベクターの形状が、自動化された脅威アクターが気にする理由を物語っている。NVDとWizは次のようにリストアップしている：
- AV:N (ネットワークに到達可能）、
- AC:L (複雑性は低い）、
- PR:N/UI:N (権限なし、ユーザーとの対話なし）、
- C:H/I:H/A:H (完全なインパクト）。(NVD)
この組み合わせは、コモディティ・スキャナーにとって "青信号 "である。PoCがパブリック・チャンネルに載った瞬間、それは ワン・リクエスト・フィンガープリント＋フォローオン・チェーン ボットネット内の設定ミスのロードバランサー、レガシーNATルール、またはベンダーのリモートサポートの穴を通して静かに公開されているIDサーバーは、これらのスキャンですぐに見つかる傾向がある。
また、より大きな文脈の問題もある：オラクルのミドルウェアは、2025年において高価値の標的となっており、隣接する製品（WebLogic、EBS、マーケティング・モジュール）の複数の重大な未認証バグがアクティブなキャンペーンに組み込まれている。Qualysの10月のCPUレビューでは、Fusion Middlewareの致命的なバグが高リスクのクラスタとして明示されています。(クオリスこのことは、攻撃者がOIMの侵害をより広範なオラクルの地所業務に連鎖させる可能性を高める。
検出を悪用に変えない防御的検証
ほとんどのチームにとって、最初の仕事は単純だ： 被ばくを特定する攻撃者をエミュレートしてはならない。安全で認可されたワークフローは次のようになる：
- インベントリOIMバージョン 環境間で比較し、影響を受けたラインと比較する。
- 管理アクセスを制限する ネットワークACL、VPNゲート、ZTNA）は、パッチ・ウィンドウの前であっても、即座に適用される。
- REST管理者の異常をハントする アクセスログに含まれるもの: エントロピーの高いリクエストURI、見慣れないIPからのバースト、変更のない時間帯に呼び出された管理者クラスのエンドポイントなど。
これを具体的にしておくために、資産目録のジョブに紛れ込ませることができるディフェンシブ・オンリーのバージョン・マッチャーを紹介しよう：
# ディフェンシブ・オンリー：発見された OIM バージョンを影響を受けるセットにマッチさせる
パッケージングからインポートバージョン
AFFECTED = [
("12.2.1.4.0", "12.2.1.4.0"),
("14.1.2.1.0", "14.1.2.1.0"),
]
def is_affected(v: str) -> bool：
v = version.parse(v)
return any(version.parse(lo) <= v <= version.parse(hi) for lo, hi in AFFECTED)
for v in ["12.2.1.4.0", "14.1.2.1.0", "14.1.2.2.0"]：
print(v, "affected?" , is_affected(v)is_affected(v))
バナーからバージョンを確実に抽出できない場合は、内部 CMDB データ、ホスト・パッケージ・マニフェスト、または Oracle ホーム・メタデータを優先する。重要なのは、運用リスクを増大させるような方法で ID ティアを「探る」ことを避けることである。
ポスト・パッチ・ハンティング：妥協とはどのようなものか
サーチライトのチェーンは、アップグレード後も注意すべき特定の行動を示唆している：
- REST管理エンドポイントが未知のソースから攻撃される特にパブリックIPレンジから。
- 変更窓口以外で使用される管理動詞特に、コンパイル、アップロード、ワークフローやコネクターを変更するもの。
- 新しいサービスアカウントまたは役割の変更 チケット制のオペレーションに合致しない。
RunZeroとWizは、単なる修復ではなく、ハードニングの一環として、異常なRESTアクティビティがないかログを確認し、管理者の到達可能性を狭めることをアドバイスしている。(ランゼロ)
パッチを当てた後、これを深刻に受け止める理由は、認証前のRCEバグがしばしば悪用されるからである。 以前 を開示する。REST層が公開されていた場合、それに触れた可能性を想定すること。
実際にリスクを軽減する緩和策
オラクルの公式ガイダンスによると、この修正を含む2025年10月のCPUアップデートを適用するようにとのことだ。(オラクル)工学的見地から、リスク低減のための行動は次のように積み重なる：
- すぐにパッチを当てる 影響を受けるサポートされているバージョンで。
- 公開リーチャビリティの削除 REST 管理プレーンの。ID 管理 API はインターネットに面するべきではない。
- 特権クレデンシャルのローテーション そして、運用上可能であればMFAを要求する。
- ベースラインとモニター OIM構成のドリフト（ロール、コネクタ、ワークフロー）。
- IAM層のセグメント化 OIMが損なわれても横方向への動きが鈍くなるように。
どれも目新しいものではないが、CVE-2025-61757は、なぜIAMのハードニングを "セット・アンド・フェザー "として扱うことができないかを示す事例である。アイデンティティ・ミドルウェアは現在、エッジVPNやウェブゲートウェイと同じ脅威の優先順位にある。
このCVEがAIセキュリティ・エンジニアにとって重要な理由
もしあなたがAIシステムとセキュリティの交差点で仕事をしているなら、OIMはますます関連性の高い上流の依存関係だ。モデル提供クラスタ、データプラットフォーム、CI/CD、そして社内のLLMツールでさえも、企業のIAMからアクセス決定を受け継いでいることが多い。IDインフラストラクチャの事前認証乗っ取りは、攻撃者がAIスタックの侵害を「正当化」する方法である。モデルサーバーの変更を許可するIDを鋳造できれば、モデルサーバーを破壊する必要はない。
防御 AI の観点から、CVE-2025-61757 は、ID テレメトリを検出パイプラインのファーストクラスのシグナルとして扱うことを思い出させてくれる。エージェント型のセキュリティ・ツールを構築しているのであれば、最も現実的な「インパクトの大きい自動化」は、投機的なエクスプロイト生成ではない。
自動化についての閑話休題（適切な場合）
大規模なオラクルエステートでは、バージョンの乱立が現実のものとなっており、開発、QA、DR、およびレガシーテナントが4分の1ずつ遅れていることがよくあります。Penligentのようなヒューマン・イン・ザ・ループの自動化プラットフォームは、以下の点で役立ちます。 フリート全体のOIMバージョンのインベントリ、暴露の検証、修復のトラッキングチームをリスクの高い悪用に追い込むことなく。脆弱性がIDレベルのクリティカルなものである場合、「発見→優先順位付け→修正」のループにおけるスピードと正確性が何よりも重要になる。
クロージング
CVE-2025-61757は単なるバグではなく、既知のエンタープライズJavaのアンチパターンから生まれた、高レバレッジのID層侵害ルートである。影響を受けるOIMバージョンにパッチを当て、REST管理アクセスをロックダウンすることだ。より長期的な対策はもっと大きなものだ： もしIAMコントロールプレーンに到達可能であれば、攻撃されるだろう。 この CVE を強制機能として扱い、ID システムの公開、認証、および監視方法を監査する。
