← Back to Feed CACHED · 2026-10-02 00:31:24 · CACHE_KEY CVE-2026-46817
CVE-2026-46817 · CWE-269 · Disclosed 2026-05-28

Oracle Payments File Transmission Unauthenticated Arbitrary File Read

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

Someone left the vault door open and the combination taped to the frame — and burglars already walked in

CVE-2026-46817 is an unauthenticated arbitrary-file-read vulnerability in the File Transmission component of Oracle Payments within Oracle E-Business Suite versions 12.2.3 through 12.2.15. An attacker sends a crafted HTTP POST to the /OA_HTML/ibytransmit endpoint containing an XML DeliveryRequest with a CODEX_PULL transmission scheme and a FULL_FILE_PATH parameter pointing at any local file — no credentials, no session, no user interaction required. The immediate impact is disclosure of sensitive server-side files (database credentials, encryption keys, payment-processor API tokens), with a direct escalation path to full Oracle Payments module takeover and lateral movement into the backing Oracle database. Oracle patched this in the May 2026 Critical Patch Update on May 28, 2026. Exploitation was observed in the wild on June 27, 2026 — six weeks post-patch — by Defused honeypots, with no public proof-of-concept in existence at the time. CISA added it to KEV on July 15, 2026, with a three-day federal remediation deadline.

Oracle's CRITICAL / 9.8 rating is fully justified and if anything understates the urgency given active exploitation. The CVSS vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) accurately captures the pre-auth, low-complexity, full-impact nature of the flaw. The only mild caveat is that the *immediate* exploit primitive is file read, not direct code execution — but the gap between reading /etc/passwd and extracting dbc or wdbsvr.app files containing database credentials is measured in seconds, not hours. Shadowserver tracked ~950 internet-exposed EBS instances (majority US-based) as of July 2026, and the threat actors who weaponized this bug reverse-engineered the patch diff rather than waiting for a public PoC — a hallmark of well-resourced, financially motivated adversaries targeting ERP payment systems.

"KEV-listed, unauthenticated Oracle Payments takeover actively exploited in the wild — patch now."
02 · The Attack Path

5 steps from start to impact.

STEP 01

Discover internet-facing Oracle EBS instance

The attacker identifies an Oracle E-Business Suite instance reachable over HTTP/HTTPS. Shadowserver tracked ~950 such instances globally as of July 2026. Discovery uses Shodan/Censys/FOFA dorks for Oracle EBS login pages (/OA_HTML/AppsLogin) or direct fingerprinting of the Oracle Application Server headers. Internally, any employee or compromised workstation on the corporate network can reach the EBS web tier.
Conditions required:
  • Target EBS web tier is network-reachable over HTTP/HTTPS (port 443 or 8000)
Where this breaks in practice:
  • Most enterprise EBS deployments sit behind VPN or corporate firewall — ~950 of potentially tens of thousands of global installs are internet-exposed
  • Organizations following Oracle's own deployment guidance restrict EBS to internal networks
Detection/coverage: Shadowserver foundation domain-based scanning; Shodan/Censys queries for Oracle EBS fingerprints; external ASM tools (Qualys EASM, CrowdStrike Falcon Surface) flag exposed EBS instances
STEP 02

Send crafted POST to /OA_HTML/ibytransmit

The attacker sends an unauthenticated HTTP POST request to the /OA_HTML/ibytransmit endpoint. The payload is a crafted XML DeliveryRequest document specifying the CODEX_PULL transmission scheme and a FULL_FILE_PATH parameter pointing to a target file (e.g., /etc/passwd). This bypasses authentication and authorization checks entirely and invokes an internal Oracle Java function that processes the file-read request. No valid session cookie, CSRF token, or any form of credential is required.
Conditions required:
  • Network access to the EBS HTTP interface (step 1 complete)
  • Target runs Oracle Payments 12.2.3–12.2.15 without May 2026 CPU applied
Where this breaks in practice:
  • Single HTTP request — essentially zero friction once network access is achieved
  • No authentication barrier, no brute force, no social engineering required
Detection/coverage: WAF rules matching POST to /OA_HTML/ibytransmit with CODEX_PULL or FULL_FILE_PATH in body; Snort SID 1:53250; IDS/IPS signature for ibytransmit endpoint; web server access logs showing unauthenticated POST to this path
STEP 03

Read server-side configuration files

The attacker escalates from the initial /etc/passwd probe to high-value targets: Oracle dbc files (containing database connect strings and credentials), wdbsvr.app (PL/SQL gateway configuration), context.xml files, and any file readable by the Oracle Application Server process user. These files typically contain plaintext or reversibly-encrypted database passwords, encryption keys, and payment processor API credentials. The file-read primitive returns content in the HTTP response.
Conditions required:
  • Successful exploitation in step 2
  • Knowledge of Oracle EBS filesystem layout (well-documented in Oracle's install guides and public security research)
Where this breaks in practice:
  • Oracle EBS filesystem paths are standardized and well-known — no guesswork required
  • File permissions on a default Oracle EBS install allow the app server user to read these files
Detection/coverage: SIEM correlation: multiple rapid-fire POST requests to /OA_HTML/ibytransmit with varying FULL_FILE_PATH values; Oracle EBS audit logs may capture abnormal file-access patterns if custom auditing is enabled
STEP 04

Authenticate to Oracle database with stolen credentials

Using the database credentials extracted from the dbc or configuration files, the attacker connects directly to the Oracle database backend (typically on port 1521). This provides full DBA-level access to all Oracle EBS schemas — including AP (Accounts Payable), IBY (Payments), HR (Human Resources), and FND (Foundation/security). The attacker can now exfiltrate payment data, modify bank account routing information, create backdoor application accounts, or deploy PL/SQL-based persistence.
Conditions required:
  • Database credentials extracted in step 3
  • Network access to Oracle DB listener (often co-hosted or on same network segment as EBS app tier)
Where this breaks in practice:
  • If the database listener is firewalled from the attacker's source network, a direct connection fails — but the attacker can often tunnel through the compromised web tier
  • Database passwords in dbc files are obfuscated with a reversible algorithm well-documented by Oracle security researchers
Detection/coverage: Database audit logs showing connection from unexpected source; Oracle Database Vault or Audit Vault alerts; network IDS detecting SQL*Net traffic from the web tier to database on unusual patterns
STEP 05

Full ERP compromise and data exfiltration

With database access, the attacker achieves the terminal objective: mass exfiltration of financial records, payment card data, vendor bank accounts, employee PII, and corporate financial statements. They can also modify payment routing (redirect wire transfers), plant persistent backdoors via stored procedures, or pivot laterally to other systems using harvested credentials. This represents complete compromise of the organization's financial ERP platform — a SOX, PCI-DSS, and potentially GDPR-reportable event.
Conditions required:
  • Database access achieved in step 4
Where this breaks in practice:
  • Data Loss Prevention (DLP) on the network egress may detect bulk data exfiltration
  • Database Activity Monitoring (DAM) solutions may flag anomalous query patterns
Detection/coverage: DLP alerts on large data transfers; DAM alerts on bulk SELECT against payment/HR tables; SIEM correlation of the full chain from web access → file read → database connection → data exfiltration
03 · Compensating Control

1
CRITICAL 9.8→LOW 2.5
SEVERITY REDUCED
Block /OA_HTML/ibytransmit at the WAF or reverse proxy immediately — Deploy a WAF rule or reverse-proxy ACL that drops all HTTP requests matching the path /OA_HTML/ibytransmit. This is a File Transmission endpoint used for automated payment file delivery — blocking it breaks the payment file-pull workflow but eliminates the attack surface entirely. Under the noisgate mitigation SLA for CRITICAL, deploy within 3 days. Most organizations can push a WAF rule in hours. Validate that the rule blocks both GET and POST methods and covers all URL-encoded variants.
2
CRITICAL 9.8→HIGH 7.5
SEVERITY REDUCED
Restrict EBS web tier to internal/VPN-only access — Remove any internet-facing exposure of the Oracle EBS web tier. Place it behind a VPN concentrator or zero-trust network access (ZTNA) gateway. This eliminates the unauthenticated remote attack vector for external adversaries. Under the noisgate mitigation SLA for CRITICAL, deploy within 3 days. Note this does NOT protect against internal attackers or compromised endpoints on the corporate network — it only reduces the reachable population.
3
CRITICAL 9.8→IGNORE 0.0
SEVERITY REDUCED
Apply Oracle May 2026 CPU to all EBS 12.2.x instances — This is the definitive fix. Apply the Oracle May 2026 Critical Patch Update, which patches the ibytransmit endpoint's missing authentication check. Under the noisgate remediation SLA for CRITICAL, complete patching within 90 days — but given KEV status and active exploitation, treat this as an immediate priority. Oracle EBS CPU application requires downtime; coordinate with change management but do not let process delay exceed the active-exploitation urgency. Test in a non-production clone first, but compress the test cycle to days, not weeks.
4
CRITICAL 9.8→CRITICAL 9.8
Hunt for indicators of prior compromise since May 28, 2026 — Search web server access logs for any POST requests to /OA_HTML/ibytransmit since the patch release date (May 28, 2026). Look for the known IOC User-Agent ibytransmit-lab-poc/1.0 and source IP 45.84.137.125 (ASN AS136787), but do not limit the hunt to these — other actors will use different indicators. Check Oracle database audit logs for unexpected connections from the EBS app-tier host. If any hits are found, treat the EBS instance and its backing database as fully compromised and initiate incident response: rotate all database credentials, payment-processor API keys, and encryption keys.
5
CRITICAL 9.8→HIGH 8.0
SEVERITY REDUCED
Deploy IDS/IPS signatures for ibytransmit exploitation — Deploy Snort SID 1:53250 or equivalent Suricata rule matching POST requests to /OA_HTML/ibytransmit containing CODEX_PULL or FULL_FILE_PATH in the request body. This provides detection-in-depth but is NOT a substitute for patching or WAF blocking — an attacker who reaches the endpoint over an encrypted channel or bypasses the IDS still succeeds. Deploy alongside the WAF block for defense-in-depth.
What doesn't work
  • Oracle EBS application-level authentication/SSO — the vulnerability bypasses all application authentication. Enabling SSO, Oracle Access Manager, or any front-end authentication layer does NOT protect the /OA_HTML/ibytransmit endpoint because the flaw is precisely that this endpoint lacks authentication enforcement.
  • Database encryption (TDE/network encryption) — encrypting data at rest or in transit within the database does not prevent an attacker who obtains valid database credentials from the file-read step. They authenticate as a legitimate user and read data through normal channels.
  • Patching only internet-facing instances — the vulnerability is equally exploitable from the internal network. Patching only externally-exposed EBS while leaving internal instances unpatched creates a false sense of security. Any compromised workstation or malicious insider reaches the internal EBS web tier.
04 · Intelligence Metadata

The supporting signals.

In-the-Wild ExploitationConfirmed. Defused honeypots captured six targeted exploitation attempts on June 27, 2026 — six weeks post-patch, before any public PoC existed. Shadowserver logged 456 attack hits on June 28 across multiple regions (North America and Asia leading). Source IP 45.84.137.125 (ASN AS136787), User-Agent ibytransmit-lab-poc/1.0.
CISA KEV StatusListed. Added July 15, 2026 under BOD 26-04. Federal agencies given a 3-day remediation deadline (July 18, 2026) — the shortest window CISA issues, reserved for actively-exploited critical flaws.
Proof-of-Concept AvailabilityNo public PoC. As of October 2026, no GitHub repository, Metasploit module, ExploitDB entry, or Nuclei template exists for CVE-2026-46817. The in-the-wild exploit was built by reverse-engineering the Oracle patch diff — a hallmark of well-resourced threat actors. Hive Security documented this as "exploited before the PoC existed."
EPSS Score0.00814 (user-provided). This is relatively low for an actively-exploited KEV entry — EPSS models lag on Oracle EBS vulns due to low public exploit signal. Do NOT use EPSS as a downgrade justification here; KEV status overrides EPSS for prioritization.
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — Network-attackable, low complexity, no privileges required, no user interaction, full confidentiality/integrity/availability impact. This is the maximum-severity profile for a pre-auth vulnerability.
Affected VersionsOracle Payments within Oracle E-Business Suite 12.2.3 through 12.2.15. All supported EBS 12.2.x releases are affected. EBS 12.1.x (desupported) is not listed but may be vulnerable — Oracle does not test desupported versions.
Fixed VersionOracle May 2026 Critical Patch Update (CPU), released May 28, 2026. No individual one-off patch — the full CPU bundle is required. Oracle MOS Doc ID references the specific Payments patch within the CPU.
Internet ExposureShadowserver (via domain-based + IP-based scanning with Validin) tracked ~950 internet-facing Oracle EBS instances globally as of July 1, 2026. Majority located in the United States. These are confirmed *reachable*, not confirmed *vulnerable* — patch status unknown.
Disclosure & Patch TimelineMay 28, 2026: Oracle CPU released with fix. June 27, 2026: First exploitation (Defused). June 29–30, 2026: Public reporting (Help Net Security). July 1, 2026: Shadowserver exposure data. July 15, 2026: CISA KEV listing.
Reporting EntityExploitation discovered by Defused (threat intelligence firm specializing in honeypot-based detection of ERP/enterprise application attacks). Technical analysis by Hive Security, SOCRadar, Xcitium ThreatLabs.

Sources.

  1. CISA KEV Alert — July 15, 2026
  2. Help Net Security — Oracle Payments flaw under attack
  3. Hive Security — Exploited before the PoC existed
  4. Security Affairs — 950 EBS instances exposed
  5. Xcitium ThreatLabs — Technical breakdown
  6. SOCRadar — Oracle Payments takeover analysis
  7. Oracle May 2026 Critical Patch Update Advisory
  8. BleepingComputer — Hackers exploit critical Oracle EBS flaw
05 · The Call

Final Verdict
= UNCHANGED to CRITICAL (9.8/10)

Why this verdict

  • Pre-auth remote with zero friction: The attack requires a single unauthenticated HTTP POST to a well-known endpoint (/OA_HTML/ibytransmit). No credentials, no user interaction, no session hijacking, no brute force. The CVSS vector's PR:N/UI:N/AC:L is accurate — this is the lowest-friction attack path possible.
  • Active exploitation confirmed, KEV-listed with 3-day federal deadline: CISA added this to KEV on July 15, 2026, with the shortest remediation window they issue. Defused caught exploitation on June 27, Shadowserver logged 456 hits the next day. Threat actors reverse-engineered the patch without waiting for a public PoC — indicating financially-motivated, well-resourced adversaries targeting ERP payment systems specifically.
  • Role multiplier: Oracle E-Business Suite is canonically a high-value-role component. Oracle Payments handles wire transfers, vendor disbursements, bank account credentials, and payment-processor API keys. The vast majority of EBS Payments deployments (>>10%) are production financial systems processing real money. The documented chain (file read → credential extraction → database compromise) succeeds in this canonical role with blast radius of tenant/domain-scale financial data compromise — SOX-reportable, PCI-DSS-reportable, potential wire-fraud enabling. This sets a CRITICAL floor that friction cannot breach.
  • ~950 internet-exposed instances are enough: While most EBS deployments are internal, 950 internet-reachable instances (per Shadowserver) represent the concentrated financial infrastructure of large enterprises. A single compromised EBS Payments instance can hold millions in payment routing data. For internally-deployed EBS (the majority), the vuln is still exploitable by any attacker with internal network access — a post-compromise lateral movement dream target.
  • File read to full compromise is not theoretical: The escalation from arbitrary file read to database takeover via dbc credential extraction is a well-documented, deterministic path in Oracle EBS security research. Oracle EBS stores database credentials in predictable filesystem locations with reversible obfuscation. This is not a speculative chain — it is the standard Oracle EBS post-exploitation playbook.

Why not higher?

The CVSS 9.8 is already at the ceiling for a Scope:Unchanged vulnerability. A 10.0 would require Scope:Changed, which is arguable (the web-tier compromise pivots to the database tier) but Oracle's own assessment uses S:U. The vendor rating is already maximum severity for the scope model used.

Why not lower?

The combination of active exploitation, KEV listing, zero authentication requirement, canonical high-value financial system, and a deterministic escalation path to full database compromise makes any downgrade indefensible. The ~950 internet-exposed instances and the sophistication of threat actors (patch-diffing without public PoC) confirm this is not theoretical risk — it is an active campaign targeting financial ERP infrastructure. Even for internally-deployed EBS, any insider or post-compromise attacker reaches this endpoint trivially.

06 · Verification

Crowdsourced verification payload.

Run this script on each Oracle EBS application-tier host as the Oracle applmgr user (or any user with read access to $CONTEXT_FILE). Example: chmod +x check_cve_2026_46817.sh && ./check_cve_2026_46817.sh. The script checks the Oracle EBS patch level and probes whether the vulnerable endpoint responds to unauthenticated requests.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# check_cve_2026_46817.sh — Verify Oracle EBS patch status for CVE-2026-46817
# Run on: Oracle EBS application-tier host
# Privileges: Oracle applmgr user (needs read access to adpatch logs)
# Output: VULNERABLE / PATCHED / UNKNOWN

set -euo pipefail

RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
NC='\033[0m'

echo "=== CVE-2026-46817 Check: Oracle Payments File Transmission ==="
echo "Date: $(date -u +%Y-%m-%dT%H:%M:%SZ)"
echo ""

# Method 1: Check if the May 2026 CPU is applied via adpatch log
CPU_APPLIED=0
if command -v adpatch &>/dev/null || [ -d "${APPL_TOP:-/dev/null}" ]; then
  # Look for the May 2026 CPU patch number in applied patches
  # Oracle May 2026 CPU for EBS 12.2 — check AD_BUGS table
  if [ -n "${ORACLE_HOME:-}" ] && [ -n "${TWO_TASK:-}" ]; then
    PATCH_CHECK=$(sqlplus -S / @- <<'EOSQL' 2>/dev/null || true
SET HEADING OFF FEEDBACK OFF PAGESIZE 0
SELECT COUNT(*) FROM ad_bugs WHERE bug_number IN ('37014892','37014893','37014894') AND ROWNUM = 1;
EXIT;
EOSQL
)
    PATCH_CHECK=$(echo "$PATCH_CHECK" | tr -d '[:space:]')
    if [ "$PATCH_CHECK" = "1" ] || [ "$PATCH_CHECK" = "2" ] || [ "$PATCH_CHECK" = "3" ]; then
      CPU_APPLIED=1
    fi
  fi
fi

# Method 2: Probe the ibytransmit endpoint locally
ENDPOINT_VULN=2  # 0=not vuln, 1=vuln, 2=unknown
if [ -n "${EBS_URL:-}" ]; then
  TEST_URL="${EBS_URL}/OA_HTML/ibytransmit"
else
  # Try localhost on common EBS ports
  for PORT in 8000 8001 443 8443; do
    if curl -sk --connect-timeout 3 "https://localhost:${PORT}/OA_HTML/AppsLogin" -o /dev/null 2>/dev/null; then
      TEST_URL="https://localhost:${PORT}/OA_HTML/ibytransmit"
      break
    elif curl -sk --connect-timeout 3 "http://localhost:${PORT}/OA_HTML/AppsLogin" -o /dev/null 2>/dev/null; then
      TEST_URL="http://localhost:${PORT}/OA_HTML/ibytransmit"
      break
    fi
  done
fi

if [ -n "${TEST_URL:-}" ]; then
  # Send a benign probe — do NOT send an actual exploit payload
  # A patched endpoint returns 401/403; an unpatched one returns 200 or processes the request
  HTTP_CODE=$(curl -sk -o /dev/null -w '%{http_code}' \
    -X POST "${TEST_URL}" \
    -H 'Content-Type: text/xml' \
    -d '<?xml version="1.0"?><DeliveryRequest><test/></DeliveryRequest>' \
    --connect-timeout 5 --max-time 10 2>/dev/null || echo "000")
  
  if [ "$HTTP_CODE" = "401" ] || [ "$HTTP_CODE" = "403" ] || [ "$HTTP_CODE" = "404" ]; then
    ENDPOINT_VULN=0
  elif [ "$HTTP_CODE" = "200" ] || [ "$HTTP_CODE" = "500" ]; then
    # 200 = endpoint processes unauthenticated request (vulnerable)
    # 500 = endpoint reached unauthenticated, threw error on malformed XML (still vulnerable)
    ENDPOINT_VULN=1
  fi
fi

# Verdict
echo "--- Results ---"
if [ "$CPU_APPLIED" -eq 1 ]; then
  echo -e "${GREEN}PATCHED${NC} — May 2026 CPU patch detected in AD_BUGS table."
  exit 0
elif [ "$ENDPOINT_VULN" -eq 0 ]; then
  echo -e "${GREEN}PATCHED${NC} — /OA_HTML/ibytransmit returns $HTTP_CODE (authentication enforced)."
  exit 0
elif [ "$ENDPOINT_VULN" -eq 1 ]; then
  echo -e "${RED}VULNERABLE${NC} — /OA_HTML/ibytransmit accepts unauthenticated POST (HTTP $HTTP_CODE)."
  echo "ACTION: Apply Oracle May 2026 CPU immediately. Block /OA_HTML/ibytransmit at WAF."
  exit 1
else
  echo -e "${YELLOW}UNKNOWN${NC} — Could not determine patch status."
  echo "Verify manually: check AD_BUGS for May 2026 CPU patches, or test ibytransmit endpoint."
  echo "Set EBS_URL=https://your-ebs-host:port and re-run for endpoint probe."
  exit 2
fi