A mailroom clerk who opens every envelope and executes the contents, no questions asked
The Workflow Notification Mailer in Oracle E-Business Suite processes inbound email to drive workflow events. A crafted email with a malicious serialized Java object or JNDI reference triggers unsafe deserialization in the Mailer, allowing remote code execution in the context of the EBS application tier. Affected versions: Oracle EBS 12.1.3, 12.2.3 through 12.2.13.
Oracle's CRITICAL 10 CVSS assumes an unauthenticated attacker can reach the vulnerable component over the network with no user interaction. In reality, the Mailer polls an internal mailbox (IMAP/POP3) and is not exposed as a public HTTP service; external delivery of the malicious email is often blocked by email gateways or the mailbox is internal-only. The severity is real if an attacker can get email through, but most deployments see far less exposure than the CVSS vector suggests.
4 steps from start to impact.
Identify target Oracle EBS Workflow Notification Mailer inbox
- Attacker knows or guesses the mailbox address
- Mailer is enabled and actively polling
- Mailer inbox addresses are rarely public
- External mail to application mailboxes is often rejected by email gateway policy
Deliver crafted email with malicious serialized payload
- Attacker can send email to the Mailer inbox (internet or internal SMTP)
- Email passes spam and malware filters
- Email gateway sandboxing may block unusual attachments
- DLP or attachment filters often strip executable-like content
- Internal-only mailboxes reject external senders by default
Mailer processes email, triggers deserialization and code execution
- Vulnerable version without CPU Oct 2026 patch
- Java deserialization filter not configured
- Mailer service must have network access to attacker-controlled callback for JNDI if used
- Java 8u121+ default serialization filters may block some gadgets
- EBS patching often disables dangerous protocols via configuration
Pivot to Oracle database and exfiltrate business data
- EBS app server must be able to reach the database over the network
- Database credentials accessible from application tier
- No database activity monitoring
- Database network segmentation limits direct access
- Database audit and DAM may alert on mass queries
- Privileged access management may require additional authentication
- WAF on Oracle EBS web UI: The vulnerability is in email processing, not HTTP; WAF cannot inspect IMAP/POP3 traffic.
- Network segmentation alone: If attacker is already inside the internal network, segmentation between mail server and EBS may not block the attack if email can still be delivered.
- Standard antivirus on the mail server: Custom Java serialized payloads may not have signatures and can bypass signature-based AV.
The supporting signals.
| In-the-wild status | No known active exploitation as of 2026-10-21; not in CISA KEV. |
|---|---|
| Proof-of-concept | No public PoC on pocindex.io, GitHub, or ExploitDB as of 2026-10-21; no repos named CVE-2026-101809. |
| EPSS score | 0.021 (34th percentile) — low for brand-new Oracle CVE. |
| KEV status | Not listed (checked 2026-10-21). |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H — network, low complexity, no auth, no interaction, changed scope, full CIA. |
| Affected versions | Oracle EBS 12.1.3, 12.2.3 through 12.2.13. |
| Fixed versions | Oracle EBS 12.2.14; 12.1.3 with CPU Oct 2026 patch (patch 38291012). |
| Exposure data | Shodan/Censys show <1% of Oracle EBS instances reachable from the internet; Workflow Notification Mailer inboxes even less exposed. |
| Reporting | Disclosed by Oracle in Critical Patch Update Advisory October 2026; no external researcher credited. |
Sources.
Why this verdict
- Friction audit: The attack path requires delivering a crafted email to an internal Mailer inbox, which is normally blocked by email gateways and internal-only mailbox policies. Public internet exposure of EBS is <1% per Shodan/Censys, so the vendor CVSS 10 overstates reach.
- Role multiplier: Production Oracle EBS deployments are canonical high-value business systems; compromise leads to mass financial data egress and potential Oracle DB takeover. That outcome keeps the verdict at HIGH despite the external reach friction.
- No public exploit: As of 2026-10-21, no PoC or active exploitation observed, lowering immediate risk but not the long-term exposure.
Why not higher?
The prerequisite of sending a malicious email to an internal Mailer inbox is not trivially satisfied from the internet; most enterprises block external email to internal service accounts. No KEV listing or public exploit means widespread automated exploitation is unlikely in the near term.
Why not lower?
If an attacker gains internal network access or can deliver email to the Mailer, the impact is severe: remote code execution on a system handling regulated financial data. Oracle EBS is a high-value target and the vulnerability is unauthenticated once reachable.
Crowdsourced verification payload.
Run on the Oracle EBS application tier as the applmgr user. Example: ./check_cve-2026-101809.sh. The script reads $APPL_TOP or defaults to /u01/install/APPS/fs1/EBSapps/appl. Requires read access to the APPL_TOP directory.
#!/bin/bash
# CVE-2026-101809 Oracle EBS Workflow Notification Mailer check
# Run as applmgr on the EBS application tier
APPL_TOP="${APPL_TOP:-/u01/install/APPS/fs1/EBSapps/appl}"
VERSION_FILE="$APPL_TOP/admin/adconfig.txt"
if [ ! -f "$VERSION_FILE" ]; then
echo "UNKNOWN: APPL_TOP or version file not found at $VERSION_FILE"
exit 2
fi
# Try to extract release from adconfig.txt; may contain RELEASE=12.2.13
REL=$(grep -i '^RELEASE=' "$VERSION_FILE" | cut -d= -f2 | tr -d '[:space:]')
if [ -z "$REL" ]; then
REL=$(grep -i '^AD_VERSION=' "$VERSION_FILE" | cut -d= -f2 | tr -d '[:space:]')
fi
case "$REL" in
12.1.3*)
if grep -q "38291012" "$APPL_TOP/admin/ad_bugs.txt" 2>/dev/null; then
echo "PATCHED: $REL with CPU Oct 2026 patch"
exit 0
else
echo "VULNERABLE: $REL without CPU Oct 2026 patch"
exit 1
fi
;;
12.2.3*|12.2.4*|12.2.5*|12.2.6*|12.2.7*|12.2.8*|12.2.9*|12.2.10*|12.2.11*|12.2.12*|12.2.13*)
echo "VULNERABLE: $REL in affected range"
exit 1
;;
12.2.14*|12.2.15*|12.2.16*|12.2.17*)
echo "PATCHED: $REL"
exit 0
;;
*)
echo "UNKNOWN: Unable to determine status for release '$REL'"
exit 2
;;
esac