SURIQ
Oracle shipped the fix for this one in May. Six weeks later, attackers are using it against live systems, and there is no public exploit for them to have copied. That pairing, a patched bug going hot with no proof-of-concept anywhere in circulation, is the tell: someone read Oracle's patch, diffed it, and rebuilt the exploit from the change itself. The flaw is CVE-2026-46817, and the part that should hold your attention is not the bug. It is that roughly 450 Oracle E-Business Suite systems are sitting on the public internet waiting to be hit.
The vulnerability carries a CVSS score of 9.8. It lives in Oracle Payments, the part of E-Business Suite that moves money, and specifically in its File Transmission flow, according to BleepingComputer. An unauthenticated attacker with HTTP access to the application can take over a vulnerable instance through a low-complexity request, no credentials required. Oracle fixed it in its May 2026 Critical Patch Update; every Payments build numbered 12.2.3 up to 12.2.15 falls in scope.
What CVE-2026-46817 breaks in Oracle Payments
Oracle classifies the bug as an authentication and privilege-management failure. In plain terms, the File Transmission component trusts a request it should not, and that trust is enough to hand an attacker control of the Payments instance. There is no documented workaround. The only fix Oracle offers is the May patch, which is why an unpatched, internet-reachable instance has no safe configuration to fall back on.
Payments is not a public service. It is the back-office function that settles transactions inside an enterprise resource planning system, so it should never have been reachable from the open internet in the first place. Yet Shadowserver counted roughly 450 E-Business Suite instances online, about 200 of them in the United States and Europe, with patch status unknown. That exposure number is the real headline. The CVE is the match; the 450 exposed instances are the kindling.
Why a patched bug suddenly went live
The detail that separates this from a routine advisory is the absence of a public exploit. The threat intelligence firm Defused caught the first in-the-wild attempts on its honeypots over the weekend before the June 29 reporting, and confirmed no proof-of-concept code is circulating. When a flaw with no published exploit starts getting hit weeks after a patch, the most likely explanation is that an attacker reverse-engineered the fix. Oracle's patch told them where the bug was; they built the rest.
That changes the math on quarterly patching. Oracle ships security fixes on a fixed Critical Patch Update cadence, so the May release effectively published a map of the vulnerability to anyone willing to diff it. The window between a fix landing and an exploit appearing is now measured in weeks, and E-Business Suite is one of the hardest products to patch quickly because of the customizations bolted onto it. A six-week gap here is not slow by EBS standards. It is normal, and that is the problem.
The honeypot signal also tells you the shape of the threat. Defused saw the activity on internet-wide decoys, not in a single targeted victim. That points to opportunistic scanning of every reachable EBS instance, the same playbook that turns patch backlogs, not zero-days, into the driver of most ransomware. If your Payments module is exposed, assume it has already been probed.
The second pre-auth takeover of EBS in nine months
This is not the first time E-Business Suite has been a mass-exploitation target this cycle. In late 2025, the Cl0p ransomware group weaponized CVE-2025-61882, a separate pre-authentication flaw in the same product, against universities and large organizations. Two unauthenticated takeover bugs in the same enterprise suite inside nine months is a pattern, not a coincidence.
EBS is following the trajectory of edge appliances: a high-value, widely deployed, hard-to-patch system that sits at the network boundary and draws repeat attention from attackers who know it will be slow to update. The same dynamic has played out across enterprise platforms recently, from PeopleSoft's PSEMHUB zero-day to the Windchill flaw under active exploitation. The lesson defenders should carry forward is that any internet-facing enterprise application is now a recurring target, and its exposure, not its individual CVEs, is the thing to fix permanently.
Apply the May update, then assume you were scanned
Patch first. Apply Oracle's May 2026 Critical Patch Update to any EBS instance running Payments in the 12.2.3 to 12.2.15 range. There is no mitigation that substitutes for the fix.
Then close the exposure. Move Oracle Payments behind a VPN or a restricted network segment so the File Transmission flow is not reachable from the public internet. This is the durable control: it neutralizes both this CVE and the next one Oracle has not disclosed yet.
Finally, hunt. Because exploitation predates public reporting, a clean patch today does not mean you were not hit last week. Review web and application logs back to mid-May for unexpected requests to the Payments File Transmission endpoint, and treat any exposed instance as a system to investigate, not just to update. Patching closes the door; it does not tell you whether someone already walked through, the same reason patching the gateway is only step one.