Cloud Security

Oracle EBS CVE-2026-46817: Patched in May, Breached in June

July 1, 2026 · 6 min read · By CloudAI Security

Attackers are actively exploiting CVE-2026-46817, a critical CVSS 9.8 unauthenticated remote takeover flaw in Oracle E-Business Suite’s Oracle Payments component, weeks after Oracle shipped a patch on May 28, 2026. Honeypots captured live intrusions over the June 27–28 weekend, and roughly 950 internet-facing EBS instances remain unpatched and exposed — a textbook cloud-perimeter failure where legacy enterprise apps sit one public endpoint away from full compromise.

The Flaw, In One Paragraph

CVE-2026-46817 lives in the File Transmission component of Oracle Payments, reachable over HTTP through the /OA_HTML/ibytransmit endpoint. Because the flaw is unauthenticated (Privileges Required: None), attack complexity is Low, and the scope touches Confidentiality, Integrity, and Availability at High impact, a single crafted POST request can read arbitrary files and ultimately seize the payments subsystem. Affected versions span Oracle E-Business Suite 12.2.3 through 12.2.15, covering the bulk of deployments still in production today (SecurityVulnerability.io).

Patched In May, Pwned In June

Oracle closed the bug in its May 2026 Critical Patch Update, released May 28, 2026, alongside 34 other CVEs across its product lines. A follow-on June 16, 2026 supplemental CSPU reinforced the fix. So this is not a zero-day. It is the more embarrassing failure mode: a known, patched, vendor-documented flaw that organizations simply did not apply — and which attackers then weaponized roughly four weeks later (Oracle Security Alert).

The exposure gap is the story. According to tracking by Defused and Shadowserver, attackers hit vulnerable instances 456 times on June 28 alone, with North America (193 hits) and Asia (181) absorbing the bulk of the traffic, followed by Europe (53), South America (18), Africa (9), and Oceania (2). BleepingComputer and SecurityAffairs independently report that over 900, and up to 950, internet-facing EBS instances remain unpatched as of late June (BleepingComputer, SecurityAffairs).

How The Intrusion Unfolded

The first confirmed in-the-wild exploitation surfaced on Defused honeypots across the June 27–28 weekend. The captured traffic is blunt and revealing. A single attacker IP — 45.84.137[.]125, routing through AS136787 PacketHub S.A. in France — fired POST requests at /OA_HTML/ibytransmit carrying a crafted XML DeliveryRequest payload. The transmission scheme was CODEX_PULL, with the FULL_FILE_PATH parameter pointed squarely at /etc/passwd — the classic fingerprint of a local-file-read / path-traversal chain being walked toward credential and key exfiltration (Cyber Security News).

The tooling signature is distinctive: a User-Agent string of ibytransmit-lab-poc/1.0, suggesting private exploit code rather than a public script. No proof-of-concept existed in the open at the time of the first strikes, which means the operator either developed the exploit independently or purchased it — either way, the absence of a public PoC did not slow them down.

Why Cloud Deployments Bear The Risk

E-Business Suite is no longer a closeted on-prem workload. Oracle actively markets EBS-on-OCI deployment models (single-node compute, multi-tier, and hybrid Oracle Database@Azure architectures), and large enterprises run the suite across AWS, Azure, and OCI for ERP, financials, and payments processing. When an app tier lands on cloud compute with a public load balancer or a security group that exposes 443 to the world, the /OA_HTML/ path becomes a directly reachable attack surface — exactly the scenario that produced 900+ exposed instances (Oracle EBS on OCI).

The deeper lesson is structural. Cloud default networking tends to privilege reachability over containment. A WAF rule blocking anomalous POSTs to ibytransmit, a zero-trust policy that places EBS app tiers behind an identity-aware proxy, or simply a security group that never exposes the admin/payment path to 0.0.0.0/0 would each have stopped this exploit cold. None of those require Oracle to ship anything. This is the same class of failure we documented when Spring Security’s auth bypass silently neutralised cloud filters — the cloud control plane was never told what to protect.

Detection And Threat Hunting

If you run EBS, treat the four weeks since May 28 as a presumptive compromise window. Hunt for these indicators across web server, proxy, WAF, and SIEM logs:

Endpoint: any POST to /OA_HTML/ibytransmit from an untrusted source IP, especially carrying XML DeliveryRequest bodies.
Attacker IP: 45.84.137.125 (AS136787 PacketHub S.A., France) — block and search history.
User-Agent: the literal string ibytransmit-lab-poc/1.0 is a near-certain exploit signature.
Payload markers: CODEX_PULL transmission scheme and FULL_FILE_PATH set to system paths (/etc/passwd, /etc/shadow, application config and key stores).
Outcome signals: unexpected outbound connections from the EBS app tier, new files in payment staging directories, or anomalous read access to ap*/ and iby/ payment tables.

A POST to that endpoint from the public internet is not legitimate business traffic. If your SIEM cannot answer “did any external source hit /OA_HTML/ibytransmit in June?” within minutes, the visibility gap is itself the finding.

Remediation: Do These Today

Patch immediately — apply the May 2026 CSPU (and June supplemental) to all EBS 12.2.3–12.2.15 app tiers. There is no configuration-only workaround that Oracle endorses for this component.
Kill the exposure — move /OA_HTML/ behind a VPN, identity-aware proxy, or bastion. Payment and admin paths have no business being internet-reachable.
Contain the blast radius — restrict the EBS app tier’s outbound egress to known payment-gateway and Oracle endpoints. A payment server that can reach arbitrary internet IPs is exfiltration waiting to happen.
Run a compromise assessment if patching slipped past May 28. File-read primitives against /etc/passwd and key stores typically precede lateral movement into the database tier — where the real damage sits.
Draft the disclosure plan if payment data or financial credentials were reachable. Oracle Payments handles card and bank-routing data; a confirmed read of payment key material triggers regulatory notification clocks.

The Broader Pattern Worth Fixing

This is the recurring shape of 2026 enterprise-app breaches: a vendor ships a patch, customers stall on applying it, and attackers scan for the stragglers within weeks. We saw it when ShinyHunters chained a PeopleSoft zero-day into data theft, and again when SAP NetWeaver flaws moved from SAML spoofing to kernel RCE. Oracle EBS now joins that list, and the common denominator is never the exploit’s cleverness — it is exposure hygiene.

The strategic fix is unglamorous and overdue. Maintain a live asset inventory of every internet-facing enterprise app (EBS, PeopleSoft, SAP, ServiceNow, Splunk), map each to its patch status and CSPU cadence, and treat any admin or payment endpoint reachable from 0.0.0.0/0 as a P1 finding regardless of whether a CVE is public. The attacker who hit /OA_HTML/ibytransmit on June 27 was not clever. They were patient, and your perimeter let them in.