CVE-2026-46817: the unauthenticated Oracle EBS file read that leaks your payment secrets

CVE-2026-46817 lets an attacker who can merely reach your Oracle E-Business Suite over HTTP read files off the server -- no login, no user interaction. The bug lives in the Oracle Payments (iPayment) File Transmission component, and the demonstrated attack reads arbitrary files by abusing an internal file-transmission function. On EBS, "read any file" is nearly as bad as "run any command": the readable files include database credentials, the EBS wallet, and payment-processor API keys.

What CVE-2026-46817 actually is

Oracle Payments ships a File Transmission capability whose HTTP entry point sits under the EBS web zone at POST /OA_HTML/ibytransmit (Content-Type: text/xml). The servlet parses an XML DeliveryRequest. In the attacks seen in the wild, that request selects the CODEX_PULL transmission scheme and sets a FULL_FILE_PATH parameter -- coercing the internal transmit routine into reading a server file and returning it. The published proof-of-concept read /etc/passwd.

Underneath, it is a missing-authentication bug. Oracle and NVD assign three CWEs that together describe one failure: the File Transmission function is exposed with no authentication check (CWE-306), the auth boundary that should gate it is not enforced (CWE-287), and the internal function the anonymous caller reaches runs with privileges it should not (CWE-269). An unauthenticated HTTP request reaches straight into a privileged internal routine.

The exploitation chain

From a single unauthenticated request to stolen credentials. Each stage has a cheap chokepoint -- the most effective is simply not exposing /OA_HTML/ibytransmit to untrusted networks.

Am I affected?

Oracle lists Oracle E-Business Suite 12.2.3 through 12.2.15 (the whole supported 12.2.x band), Oracle Payments product, File Transmission component. It is fixed in the Oracle Critical Patch Update of May 2026. Do not trust the web-server banner to tell you the patch level -- verify with select release_name from fnd_product_groups; plus AD_PATCH.IS_PATCH_APPLIED / ad_adop_session_patches on the app tier.

Exploited in the wild

Threat-intel firm Defused recorded the first exploitation against its Oracle EBS honeypots on 27 June 2026 -- a single source IP making unauthenticated file-read requests to /OA_HTML/ibytransmit, with a tool that self-identified as ibytransmit-lab-poc/1.0. That is roughly six weeks after Oracle's patch and before any public PoC existed, which means someone built the exploit privately. BleepingComputer, SecurityWeek, The Hacker News, Help Net Security and Security Affairs all corroborated the activity, and Shadowserver tracks around 900-950 internet-exposed EBS instances.

Detection & hunting

There is no official Nuclei or Sigma rule yet, so detection is DIY. The durable signal is the endpoint plus payload, not the first attacker's IP or user-agent (both are trivially changed). Watch Oracle HTTP Server access logs for the /OA_HTML/ zone, and use a body-inspecting sensor (WAF/IDS) for the payload -- OHS does not log request bodies by default.

• Request-side: anonymous POST /OA_HTML/ibytransmit with no valid EBS session cookie -- an unauthenticated 200 here is the anomaly.
• Payload: XML <DeliveryRequest> containing CODEX_PULL, FULL_FILE_PATH, oracle.apps.iby, or absolute/../ file paths.
• Response-side (a successful read): responses from ibytransmit carrying file content -- root:x:0:0 (a leaked /etc/passwd), jdbc:oracle: / APPS strings (a leaked config), or an unexpectedly large text/plain body.
• First-wave IoCs (retro-hunt only, ephemeral): source IP 45.84.137.125, user-agent ibytransmit-lab-poc/1.0.

# PROPOSED, NOT OFFICIAL - request-side detection on OHS access logs
title: Oracle EBS Payments File Transmission Exploitation Attempt (CVE-2026-46817)
status: experimental
logsource:
  category: webserver          # Oracle HTTP Server access log, OA_HTML zone
detection:
  selection_path:
    cs-method: 'POST'
    cs-uri-stem|contains: '/OA_HTML/ibytransmit'
  filter_authenticated:
    cs-cookie|contains: 'icx_session_ticket'   # tune to your real EBS session cookie
  condition: selection_path and not filter_authenticated
fields: [c-ip, cs-user-agent, cs-uri-stem, sc-status]
level: high

What to do now

1. Patch: apply the Oracle Critical Patch Update of May 2026 for your exact 12.2.x level (look up the patch number in My Oracle Support). There is no supported workaround.
2. If you cannot patch today: block /OA_HTML/ibytransmit from untrusted sources at the reverse proxy/WAF, and pull the EBS web tier behind a VPN. Add a WAF virtual-patch on CODEX_PULL + FULL_FILE_PATH + path traversal.
3. Assume compromise if you were exposed and unpatched after ~28 May 2026: hunt the logs above, then rotate every secret a file read could have captured -- DB/APPS passwords, the EBS wallet/dbc secrets, and payment-processor API keys. Patching does not undo credential theft.
4. Prioritise: internet-facing Payments installs first (24-72h); internal-only EBS on the next accelerated window.

FAQ

Sources

• NVD -- CVE-2026-46817
• Oracle Security Alerts -- Critical Patch Update, May 2026
• Defused -- CVE-2026-46817 in-the-wild disclosure (primary honeypot source)
• Help Net Security -- Oracle Payments CVE-2026-46817 exploitation
• BleepingComputer -- new Oracle EBS flaw now exploited
• SecurityWeek -- exploitation of recent Oracle EBS vulnerability begins
• Security Affairs -- attackers exploit CVE-2026-46817
• SOCRadar -- CVE-2026-46817 Oracle Payments takeover
• Rapid7 -- vulnerability DB entry