The critical Oracle PeopleSoft zero-day that the extortion group ShinyHunters has been exploiting since May is not a single vulnerability but three flaws chained together, the researchers who reported the issue said this week, according to The Hacker News.
Oracle delivered fixes for all three flaws under a single identifier — CVE-2026-35273 — back in June. The chain begins with a server-side request forgery (SSRF) that works because PeopleSoft places trust in requests originating from its own loopback address. That lets an attacker reach an internal management interface, where two additional flaws convert the initial foothold into real impact. The researchers have not yet publicly described those two components in detail.
The bookkeeping problem
For defenders, the story is as much about CVE bookkeeping as about the bug itself. Three distinct flaws have been collapsed into one identifier, so a dashboard showing "CVE-2026-35273: patched" gives no indication that remediation meant breaking a chain rather than closing one hole. Organisations that track coverage by CVE count — including zero-day tallies — will understate what was actually at stake.
There is a second subtlety: the root behaviour, PeopleSoft's trust of its own loopback address, may persist independently of the vendor fix in some configurations. Applying the June patch does not automatically prove that an internal management interface is unreachable from application hosts, or that loopback-originated requests are no longer treated as privileged. Patch presence and security posture are not interchangeable here.
Reconciling the timeline
Two timeframes have circulated around this story, and they describe different things. Oracle moved quickly on the vendor side: exploitation was under way in May, and fixes shipped in June — roughly a one-month turnaround from active exploitation to patch. But because the chain's structure only became public this month, an unpatched instance has been exposed to a known-in-the-wild attack for about five months without its administrators necessarily understanding what the June fix defended against. Administrators may have applied the patch on faith; others may still be running vulnerable instances five months after ShinyHunters began exploiting them.
The disclosure sequence also ran backwards from the defender's point of view: exploit first, patch second, understanding third.
What HK PeopleSoft teams should check this week
Hong Kong organisations running PeopleSoft, or comparable on-premises estates with similar internal management surfaces, would be well served by treating this as a checklist item rather than a CVE tick-box:
- Confirm the June CVE-2026-35273 fix is present on every PeopleSoft instance, including nodes that fall outside standard discovery and patch-scanning coverage.
- Audit whether internal management interfaces are reachable from application hosts, and whether any component grants elevated trust to loopback-originated requests.
- Treat SSRF findings as potential stepping stones to privileged internal surfaces, not as standalone information-disclosure issues worth deferring.
- Assume any instance left unpatched was in scope during the May-to-present window, given ShinyHunters' established extortion playbook.
- Watch HKCERT advisories as they appear, and reconcile local remediation records with any guidance the CERT issues on this issue.
A further question remains open: the technical detail behind the chain's second and third flaws has not been fully published. Should researchers describe them publicly, expect revised guidance — the current fix may not be the whole answer to what the chain can reach.
Source: The Hacker News.
據 The Hacker News 報導，報告相關問題的研究人員本週表示，勒索集團 ShinyHunters 自五月起持續利用的 Oracle PeopleSoft 關鍵 zero-day 漏洞，實際上並非單一漏洞，而是三個缺陷串連而成。
Oracle 已於六月以單一識別碼 —— CVE-2026-35273 —— 為全部三個缺陷提供修補。連環攻擊的起點是伺服器端請求偽造（SSRF），其成因在於 PeopleSoft 對源自自身 loopback 地址的請求予以信任。這使攻擊者得以接觸內部管理介面，並在該處透過另外兩個缺陷，將初步立足點轉化為實質影響。研究人員尚未公開詳細描述這兩個環節。
帳目管理的問題
對防禦者而言，此事不僅關乎漏洞本身，更關乎 CVE 的帳目管理。三個各自獨立的缺陷被合併至同一個識別碼之下，因此顯示「CVE-2026-35273：已修補」的儀表板，完全無法反映修復工作的實質內容 —— 該次修復是要斬斷一條攻擊鏈，而非僅封堵單一漏洞。以 CVE 數量追蹤涵蓋範圍的機構（包括 zero-day 統計在內），會低估實際風險的嚴重程度。
另有第二層微妙之處：根本行為 —— PeopleSoft 對自身 loopback 地址的信任 —— 在某些設定下可能獨立於廠商修補而繼續存在。套用六月份的修補程式，並不能自動證明內部管理介面無法從應用程式主機接達，亦不能證明源自 loopback 的請求已不再被視為具特權。在此情境下，有無安裝修補程式與實際安全態勢並不可以互相替代。
釐清時間線
圍繞此事流傳著兩組時間框架，而兩者所描述的內容並不相同。Oracle 在廠商方面行動迅速：利用行動於五月已經展開，修補程式六月出爐 —— 由 actively exploited 到發布修補，轉換期約為一個月。然而，由於攻擊鏈的結構直到本月才公開，未經修補的系統實例在約五個月內一直暴露於已知的在野攻擊之下，其管理員卻未必理解六月份的修補究竟防範了什麼。部分管理員可能是基於信任而套用修補；另一些人則可能在 ShinyHunters 開始利用漏洞五個月之後，仍在運行存在漏洞的實例。
從防禦者的角度而言，披露次序同樣是倒過來的：先是利用，其次是修補，最後才是理解。
香港 PeopleSoft 團隊本週應檢查的事項
運行 PeopleSoft 的香港機構，或擁有類似內部管理層面的同類本地部署環境，宜將此事視為一項待辦清單事項，而非僅僅在 CVE 方格上打勾：
- 確認六月份的 CVE-2026-35273 修補已安裝於每個 PeopleSoft 實例，包括不在標準發現及修補掃描覆蓋範圍之內的節點。
- 審核內部管理介面是否可從應用程式主機接達，以及是否有任何元件對源自 loopback 的請求授予較高信任級別。
- 將 SSRF 發現視為通往具特權內部層面的潛在踏腳石，而非可以擱置的獨立資料披露問題。
- 鑑於 ShinyHunters 已確立的勒索手法，應假設任何未經修補的實例在五月至今的時間窗內均在攻擊範圍之內。
- 留意 HKCERT 隨時發布的通告，並將本地修復記錄與 CERT 就此事發布的任何指引互相核對。
尚有一個問題懸而未決：攻擊鏈第二及第三個缺陷的技術細節仍未完全公開。若研究人員其後公開描述這些缺陷，應預期會有修訂指引出台 —— 現有的修補未必足以完全涵蓋該攻擊鏈所能觸及的範圍。
來源：The Hacker News。