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.
5 steps from start to impact.
Discover internet-facing Oracle EBS instance
/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.- Target EBS web tier is network-reachable over HTTP/HTTPS (port 443 or 8000)
- 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
Send crafted POST to /OA_HTML/ibytransmit
/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.- 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
- Single HTTP request — essentially zero friction once network access is achieved
- No authentication barrier, no brute force, no social engineering required
/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 pathRead server-side configuration files
/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.- Successful exploitation in step 2
- Knowledge of Oracle EBS filesystem layout (well-documented in Oracle's install guides and public security research)
- 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
/OA_HTML/ibytransmit with varying FULL_FILE_PATH values; Oracle EBS audit logs may capture abnormal file-access patterns if custom auditing is enabledAuthenticate to Oracle database with stolen credentials
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.- Database credentials extracted in step 3
- Network access to Oracle DB listener (often co-hosted or on same network segment as EBS app tier)
- 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
dbcfiles are obfuscated with a reversible algorithm well-documented by Oracle security researchers
Full ERP compromise and data exfiltration
- Database access achieved in step 4
- Data Loss Prevention (DLP) on the network egress may detect bulk data exfiltration
- Database Activity Monitoring (DAM) solutions may flag anomalous query patterns
/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.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./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./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.- 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/ibytransmitendpoint 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.
The supporting signals.
| In-the-Wild Exploitation | Confirmed. 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 Status | Listed. 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 Availability | No 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 Score | 0.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 Vector | CVSS: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 Versions | Oracle 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 Version | Oracle 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 Exposure | Shadowserver (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 Timeline | May 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 Entity | Exploitation 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.
- CISA KEV Alert — July 15, 2026
- Help Net Security — Oracle Payments flaw under attack
- Hive Security — Exploited before the PoC existed
- Security Affairs — 950 EBS instances exposed
- Xcitium ThreatLabs — Technical breakdown
- SOCRadar — Oracle Payments takeover analysis
- Oracle May 2026 Critical Patch Update Advisory
- BleepingComputer — Hackers exploit critical Oracle EBS flaw
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'sPR:N/UI:N/AC:Lis 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
dbccredential 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.
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.
#!/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