Two Oracle stories landed on 28 October. BleepingComputer and The Register report that attackers have started probing for Oracle E-Business Suite (EBS) systems that are still exposed to CVE-2026-101767, a critical flaw Oracle fixed in its October Critical Security Patch Update on 20 October. Separately, researchers at TrendAI's Zero Day Initiative (ZDI) say the PeopleSoft zero-day that the ShinyHunters extortion group exploited from May onward is three distinct vulnerabilities, not one.
For teams running either product, the practical point is the same. Installing the patch is necessary but may not be enough. Scanning tends to come before exploitation attempts, and The Register notes that a PeopleSoft system already compromised may stay compromised after patching, particularly if a web shell is in place.
Scanning for the EBS flaw has started
CVE-2026-101767 is an unauthenticated SQL injection in the Thin Client Framework servlet, which sits in a core component of EBS's Application Object Library. Horizon3, which found the bug and reported it to Oracle, says a crafted request lets an attacker run SQL with the privileges of the APPS database user, and that the chain extends to operating system commands running as the EBS application account. Horizon3 adds that, depending on the deployment, the data at risk may include financial, payroll, HR and procurement records. BleepingComputer describes the attack as low-complexity and needing only HTTP network access.
Threat intelligence firm Defused said its EBS decoys recorded "exploratory exploits" against the flaw on the morning of 27 October. According to BleepingComputer, Oracle had not marked the bug as exploited in the wild, and The Register says Oracle did not immediately answer its question about whether any successful exploitation had been documented. In its patch advisory, Oracle said some past attacks had worked because customers had not applied available patches, and it urged customers to patch without delay.
Shadowserver counts more than 670 EBS instances reachable from the internet, most with US IP addresses. BleepingComputer notes that the count does not show how many are honeypots or how many are already patched.
One PeopleSoft CVE, three underlying bugs
Oracle shipped a fix for the PeopleSoft issue under a single identifier, CVE-2026-35273, after ZDI reported it on 10 June. BleepingComputer says ShinyHunters exploited it between 27 May and 9 June to get unauthenticated remote code execution and steal data. Mandiant later confirmed the zero-day exploitation, which at first was aimed mostly at the education sector. By late September, Mandiant said the group had placed web shells on dozens of systems in higher education, technology, IT services, healthcare, agriculture, transportation and government.
In a blog post on 27 October, ZDI researcher Bobby Gould wrote that he and TrendAI colleagues Minh Giang and Lucas Miller had reported three separate bugs in June. He said each should get its own CVE and that ZDI is coordinating with Oracle to assign them.
The first is a server-side request forgery in the PeopleSoft Integration Gateway (PSIGW). In June, Oracle added a validateClient method so administrators could limit who reaches sensitive functionality. Gould points out that localhost is allowed by default, so the SSRF lets an attacker send requests that pass the check and reach the PeopleSoft Environment Management Hub (PSEMHUB). The second is a file path control flaw in PSEMHUB's ExecuteProcessActivityCommand handler, which is meant to let remote clients write log entries. Because it does not validate requests properly, an attacker can write a web shell to a chosen path. The third is an unsafe deserialization flaw in PSEMHUB. An XML file planted in the directory that holds environment configuration is deserialized the next time PSEMHUB initializes, for example after a service or system restart, which can lead to code execution.
Why patching is not the end of it
The PeopleSoft chain has two consequences for defenders. An attacker who got in before the fix may already have a web shell, and a patch does not remove one. The deserialization bug also works on a delay. A malicious file written to the configuration directory does nothing until PSEMHUB starts again, so a restart, including one done to apply a patch, is when it would fire.
Gould's account also shows how much the June mitigation relied on configuration. Trusting localhost by default is what made the SSRF useful, so administrators should look at what their validateClient setup actually allows. For EBS, the issue is timing. A patch has been available since 20 October, scanning was seen on 27 October, and any instance still reachable from the internet and unpatched is the kind of system those scans are looking for.
What to do
- Apply Oracle's October 2026 Critical Security Patch Update to every EBS instance, starting with any that can be reached from the internet.
- On PeopleSoft servers, search for web shells and for unexpected files written through PSEMHUB, since patching alone may not remove an attacker who is already inside.
- Before restarting PSEMHUB, check the PeopleSoft environment configuration directory for XML files you cannot account for.
- Review which hosts your PeopleSoft validateClient configuration trusts, including the default localhost allowance, and watch for Oracle's separate CVEs and fixes for the three bugs.