Attackers began exploiting a critical unauthenticated remote-code-execution flaw in Oracle E-Business Suite (EBS) on June 27, 2026 — about six weeks after Oracle shipped a fix, and before any public proof-of-concept was available. Honeypot infrastructure recorded 456 distinct attack attempts against the flaw in a single 24-hour window, and Shadowserver currently tracks more than 450 internet-exposed EBS instances, nearly 200 of them in the US and Europe.

The vulnerability

CVE-2026-46817 carries a CVSS 3.1 base score of 9.8 and lives in the File Transmission component of Oracle Payments, the payment-processing module bundled with Oracle E-Business Suite. The flaw stems from a combination of improper privilege management, improper authentication, and a missing authentication check on a critical function — together allowing an unauthenticated attacker with plain HTTP access to the application to take over the system with low attack complexity.

The exploited entry point is the ibytransmit servlet under /OA_HTML/. In a legitimate deployment, this endpoint is used by Oracle Payments to transmit and receive batch files (e.g., funds-transfer files) between EBS and external banking systems. Because the endpoint fails to enforce session authentication on certain request paths, an attacker can call internal Oracle Java classes directly through crafted parameters. Observed in-the-wild requests redirect the servlet’s internal file-handling logic to read arbitrary files from the host filesystem — researchers documented attackers using the technique to pull /etc/passwd as a low-risk exploitation probe, with the same primitive usable to stage further file writes and command execution.

Affected versions: Oracle E-Business Suite 12.2.3 through 12.2.15 (all customers on the EBS 12.2 line who had not applied the May 2026 Critical Patch Update).

Oracle fixed the issue in its May 2026 Critical Patch Update (CPU). The roughly six-week gap between patch release and first observed exploitation, combined with the absence of any published exploit code at the time attacks began, indicates the attackers either reverse-engineered the patch diff or independently rediscovered the flaw — both plausible given EBS’s long history as a target for financially motivated intrusion groups (the same Oracle EBS product line was hit by Cl0p’s mass-exploitation campaign against a different RCE chain in 2025).

Impact

Oracle Payments handles funds transfers, credit card processing configuration, and bank-account data for EBS customers — predominantly large enterprises and government agencies running ERP/financial workloads. Unauthenticated takeover of the File Transmission component gives an attacker a foothold inside the application tier with access to financial transaction data and a base from which to pivot toward the database tier and connected banking interfaces. Given EBS’s footprint in finance, manufacturing, and government back-office systems, a successful compromise has direct fraud and data-exfiltration implications, not just availability impact.

The scale of scanning — 456 hits in 24 hours against honeypots alone — suggests broad, automated reconnaissance rather than a narrowly targeted campaign, consistent with opportunistic mass exploitation of internet-facing EBS instances ahead of more selective follow-on activity.

Mitigation

  1. Patch immediately. Apply Oracle’s May 2026 Critical Patch Update if it has not already been applied. There is no later out-of-band patch for this specific CVE — the May CPU is the fix.
  2. Treat unpatched, internet-facing instances as potentially compromised. Any EBS deployment that was reachable from the internet and left unpatched past May 28, 2026 should be assumed compromised pending investigation.
  3. Hunt for indicators. Review web server and application logs for anomalous POST requests to /OA_HTML/ibytransmit, unexpected file-read operations targeting system files like /etc/passwd, and unusual outbound connections from the EBS application tier.
  4. Restrict exposure. EBS web interfaces — and the Oracle Payments module specifically — should not be directly reachable from the public internet. Place EBS behind a VPN or restrict access by source IP at the network perimeter.
  5. Rotate credentials and review financial transaction logs for any EBS instance with confirmed or suspected compromise, given the Payments module’s access to banking data.

References