PeopleSoft zero-day campaigns: what teams need to verify after patching

TL;DR: ShinyHunters exploited a critical unauthenticated PeopleSoft RCE zero-day, continued activity after Oracle patched CVE-2026-35273, and may have breached 110 U.S. education organisations plus victims in government and commercial sectors, according to Intel 471. The operational lesson is that patching closes exposure, but only retroactive log hunting and behaviour-based detection can confirm whether compromise already occurred.

Editorial analysis by NHI Mgmt Group, based on content published by Intel 471: “ShinyHunters’ 0-day attacks: After patching, find out if you were breached”.

By the numbers:

• The main blockers for 44% of CTI teams are lack of time and funding, according to the 2026 SANS CTI survey cited by Intel 471.
• Oracle released patches for CVE-2026-35273 on June 10, 2026, after ShinyHunters had been exploiting the flaw since late May, according to Intel 471.
• ShinyHunters has claimed to have breached 110 U.S. education organisations, according to Intel 471.

Key questions

Q: What should teams do first when a zero-day is disclosed before scanning can finish?

A: Start with the most current inventory data you already trust, then query that inventory for the affected CVE, package, or version.

Q: Why does patching not tell you whether a PeopleSoft zero-day breach already happened?

A: Because a patch removes the vulnerable condition, not the historical evidence of prior abuse.

Q: What are the signs that a retroactive hunt is missing the real intrusion path?

A: If your searches only check one indicator type or one log source, you will miss activity that was hidden by tradecraft changes.

Practitioner guidance

• Preserve the pre-patch telemetry window Retain DNS, firewall, process creation, authentication, and network connection logs covering the period before and after patching so you can answer whether the campaign touched your environment.
• Run indicator look-backs against the right data sources Translate each IP, domain, hash, and file artefact into the specific log types it can reasonably appear in, then search those sources instead of relying on broad keyword matching.
• Add behaviour hunts for campaign tradecraft Search for unusual SMB communication, suspicious Java child processes, and remote administration tool activity that may persist even when indicators change.

Bottom line: The article shows that a successful patch does not prove a system was not already compromised before remediation.

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →