Oracle PeopleSoft悪用中のRCEは3つの脆弱性の連鎖と判明

概要

• ShinyHunters が悪用している Oracle PeopleSoft の CVE-2026-35273 は、1つの欠陥ではなく、3つの脆弱性の連鎖だった。報告者の TrendAI の Zero Day Initiative（ZDI）がブログで中身を公開し、The Hacker News が10月28日に報じた（ZDI、The Hacker News）。
• 外部連携用の PSIGW の SSRF で、内部管理用の PSEMHUB に「サーバー自身から」リクエストを送る。PSEMHUB の接続元チェックは出荷時から localhost を信頼しているため素通りになる（ZDI）。
• そこから、ログ書き込み機能で Webシェルを置くか、再起動時に読み込まれる XML で Java の逆シリアル化を起こすかの2通りでコードを実行できる。後者は Webシェルを残さない（ZDI）。

この記事では、ベンダー・公的機関・研究者・報道で確認できた内容を「事実」、筆者の推測や意見を「考察」として分けて書いています。

何が起きたか（時系列）

技術的な問題点（根本原因）

事実（ZDI）

関係するのは、別々の Web アプリケーションとして動く2つの部品である。PSIGW（Integration Gateway）は外部システムとメッセージをやり取りする。PSEMHUB（Environment Management Hub）は内部の管理用インターフェースで、validateClient メソッドで信頼できる接続元だけを受け付けることになっている。

• validateClient は、接続元のホスト名と IP を /envmetadata/config/allowedhosts.properties の一覧と照合する。この一覧には出荷時から localhost が入っている。SSRF で 127.0.0.1 から PSEMHUB にリクエストを送ると、サーバー自身からの通信に見えるので照合を通る。ZDI は「強力な SSRF と、ループバックからの PSEMHUB へのアクセスを既定で許す判断の組み合わせが、validateClient の保護を無効にしている」と書いている。

考察

• 1つ1つは「内部向けだから大丈夫」という前提で書かれた機能である。ログ書き込みが任意パスを受け付けるのも、XMLDecoder で設定を読むのも、PSEMHUB に外から届かなければ問題にならない。その前提を、別アプリの SSRF と「localhost は信頼する」既定値が同時に崩した。
• 修正が1つの CVE にまとめられているため、どの部分が直ったのかを利用者が把握しにくい。ZDI が個別の CVE 化を求めているのは、この見えにくさを解消するためと読める。

攻撃・侵入経路

flowchart TD
    A[攻撃者] -->|POST /PSIGW/HttpListeningConnector<br/>HttpTargetConnector指定| B[PSIGW SSRF]
    B -->|http://127.0.0.1 からPSEMHUBへ| C[PSEMHUB validateClient<br/>既定でlocalhostを許可し通過]
    C --> D[ExecuteProcessActivityCommand<br/>m_line と m_targetFile を指定]
    D -->|経路1| E[WARのパスにJSPを書き込み<br/>Webシェルで即時にコード実行]
    D -->|経路2| F[envmetadata/data/environment/ に<br/>悪意のあるXMLを書き込み]
    F --> G[再起動などでHubServlet初期化<br/>XMLDecoderで逆シリアル化]
    G --> H[Webシェルなしでコード実行]
    E --> I[データ窃取と恐喝]
    H --> I

事実（Mandiant、The Hacker News 経由）

• 9月の攻撃では、/PSEMHUB/ のパスをブロックする WAF のルールを、1文字を URL エンコードした /%50SEMHUB/ で回避していた。多くの WAF ルールはパスを文字列のまま照合するが、PeopleSoft のサーバーはデコードしてページを返す。

なぜ防げなかったか・構造的要因の考察

考察

• 公表前に悪用が始まっていた。 最初の悪用（5月27日〜6月9日）は Oracle のアラートより前で、修正を当てる機会がなかった。大学の PeopleSoft は学生・教職員の個人情報や成績をまとめて持っており、データを盗んで恐喝する ShinyHunters にとって価値が高い。
• 「ループバックは安全」という既定値。 同じサーバーからの通信を信頼する設計は多いが、そのサーバー上に外部の入力で任意の宛先に通信できる機能（SSRF）が1つでもあれば、信頼は外部に開いてしまう。今回は別の Web アプリ同士だったため、設計の段階で組み合わせが見落とされたと考えられる。
• WAF だけの暫定対策は破られる。 9月の波で使われた %50 の回避は単純だが、パスの正規化をしない WAF ルールには十分だった。修正までのつなぎを WAF に任せていた組織は、守れていると思い込んだまま侵入された可能性がある。
• 2つ目の経路は痕跡が少ない。 XMLDecoder の経路は Webシェルを残さず、コードが動くのも次の再起動時なので、Webシェルの探索だけでは見逃す。

運用者向けの具体的な対策と検知ポイント

事実（Oracle、Mandiant、ZDI）

• 修正を適用する。すぐにできなければ PSEMHUB を無効化・削除する（Oracle）。
• Webシェルが見つかったホストは侵害済みとして扱い、証拠を保全し、PeopleSoft 層から届く認証情報をすべて変更する（Mandiant）。

考察（検知の工夫）

• Web サーバーのアクセスログで、/PSIGW/HttpListeningConnector への外部からの POST と、/PSEMHUB/ や URL エンコードされた /%50SEMHUB/ などへのアクセスを探す。WAF・ログの照合はデコード後のパスで行う。
• PSEMHUB の WAR のディレクトリに、見覚えのない JSP ファイルがないかを確認する。
• [docroot]/envmetadata/data/environment/ に、正規の環境情報以外の XML がないかを確認する。再起動の前に確認しておくと、2つ目の経路の実行を防げる。
• allowedhosts.properties の内容を見直し、PSEMHUB を使っていなければ止める。修正を当てても、すでに置かれた Webシェルや XML は残る可能性があるので、修正前に侵入されていなかったかを別に確かめる。

参考リンク

• CVE-2026-35273: SSRF to RCE in Oracle PeopleSoft（Zero Day Initiative）
• Oracle Security Alert Advisory - CVE-2026-35273（Oracle）
• ShinyHunters-Exploited Oracle PeopleSoft Zero-Day Turns Out to Be Three Chained Flaws（The Hacker News、2026年10月28日）