CVE-2026-101767 · Oracle E-Business Suite Application Object Library Core…

01 · The Real Story

A wide-open back door to the company's financial nerve center

This vulnerability in Oracle E-Business Suite's Application Object Library (AOL) Core allows an unauthenticated attacker to compromise a core component of the ERP stack over HTTP. Oracle's advisory lists affected versions as all Oracle EBS 12.2.x releases up to, but not including, the October 2026 Critical Patch Update.

Oracle's CRITICAL 9.8 rating assumes the vulnerable endpoint is reachable from the internet with no authentication. In practice, Oracle EBS is an internal line-of-business system; most production deployments sit behind firewalls, VPNs, or SSO portals, which sharply reduces the population an external attacker can reach. The impact is still severe when reached—full business data exposure and ERP process manipulation—so this is a HIGH-priority internal patching issue rather than a screaming internet-wide CRITICAL.

"Unauthenticated ERP compromise in Oracle EBS — critical on paper, but most deployments sit behind VPN."

02 · The Attack Path

4 steps from start to impact.

STEP 01

Locate exposed Oracle EBS web endpoints

Attacker enumerates internet-facing Oracle EBS services using Shodan/FOFA queries for /OA_HTML/AppsLogin, Oracle EBS headers, or default port 8000/4443. The target endpoint is the AOL Core servlet mapped under the EBS web root.

Conditions required:

Internet-reachable Oracle EBS application tier
Default HTTP/HTTPS listener exposed

Where this breaks in practice:

Most Oracle EBS deployments are internal-only behind corporate firewalls or VPN concentrators
Public internet exposure of EBS is uncommon except in DMZ/partner portal scenarios

Detection/coverage: Shodan/Censys can enumerate; perimeter NGFW logs may show inbound scans

STEP 02

Send crafted request to AOL Core servlet

Attacker sends a specially crafted HTTP request to a vulnerable AOL Core component, exploiting insufficient validation in parameter or object handling to trigger server-side code execution. No public exploit name exists; this would be a custom Burp/curl payload.

Conditions required:

Vulnerable AOL Core component present and unpatched
Request reaches the EBS Java servlet engine

Where this breaks in practice:

Oracle has not released details; exploit construction requires reverse-engineering the CPU diff
WAF may block malformed Oracle-specific patterns once signature exists

Detection/coverage: HTTP access logs may show unusual requests to /OA_HTML/ servlets; WAF/IPS signature after CPU

STEP 03

Gain unauthenticated code execution as applmgr

The exploit executes arbitrary code within the Oracle EBS application tier process, running as the applmgr OS user. That provides immediate access to application files, DBC database credentials, and job scheduling.

Conditions required:

Successful deserialization/code injection
No O/S-level sandbox blocking JVM process execution

Where this breaks in practice:

EDR or host-based IDS on the app tier may flag unusual child processes or file writes
Segmentation may block outbound C2 from the app tier

Detection/coverage: EDR/HIDS alerting on Java child process anomalies; AV may catch dropped payloads

STEP 04

Pivot to the Oracle database and exfiltrate business data

Using credentials stored in DBC files or application configuration, the attacker connects to the backend Oracle database as APPS or a privileged schema. From there they can read/modify financial, HR, and supply-chain data, or schedule concurrent programs.

Conditions required:

App-to-DB credentials accessible from app tier
Database listener reachable from app tier

Where this breaks in practice:

DB firewall/network segmentation may restrict app tier to only required DB ports
Database audit and UEBA may detect unusual APPS queries

Detection/coverage: Database audit trails, UEBA for abnormal APPS activity, DLP on egress

03 · Compensating Control

HIGH 8.5→MEDIUM 5.5

SEVERITY REDUCED

Restrict Oracle EBS web tier to internal/VPN networks — Block internet access to EBS listener ports (typically 8000/4443) at the network edge, and require VPN/ZTNA for remote employees. This removes the unauthenticated external path and buys you time. Deploy within 30 days per the noisgate mitigation SLA for HIGH severity.

HIGH 8.5→IGNORE 0.0

SEVERITY REDUCED

Apply Oracle Critical Patch Update October 2026 — Patch the AOL Core component following Oracle's adop patch cycle. This is the permanent fix; deploy within 180 days per the noisgate remediation SLA for HIGH severity.

HIGH 8.5→HIGH 7.0

Enable WAF/IPS signatures for Oracle EBS endpoints — If EBS must be public-facing, deploy WAF rules for Oracle-specific AOL endpoints and anomaly detection. This may block crafted HTTP requests. Deploy within 30 days.

What doesn't work

Changing default passwords or enabling MFA on EBS logins does not mitigate the unauthenticated flaw, which bypasses the login flow entirely.
Database encryption/TDE does not stop app-tier code execution or exfiltration of data through authorized DB credentials.

04 · Intelligence Metadata

The supporting signals.

In-the-wild status	No exploitation observed; no GreyNoise tags; absent from CISA KEV as of assessment.
Proof-of-concept availability	No public PoC found on pocindex.io or GitHub repositories named after the CVE.
EPSS score / percentile	Not available for this future CVE; pre-release or insufficient data.
KEV status	Not listed in CISA Known Exploited Vulnerabilities Catalog.
CVSS vector	`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H` — network, low complexity, no privileges, no interaction; trivial if reachable.
Affected versions	Oracle EBS Application Object Library (Core) — all Oracle EBS 12.2.x releases before CPU October 2026.
Fixed versions	Apply Oracle Critical Patch Update October 2026; exact patch number is in Oracle Support Doc for CPU Oct 2026.
Scanning/exposure	Shodan/Censys show limited public exposure for Oracle EBS; typical deployments are internal-only.
Disclosure date	2026-10-20
Reporting researcher/org	Oracle internal or credited researcher; not disclosed in available advisory.

Sources.

05 · The Call

Final Verdict

↓ DOWNGRADED to HIGH (8.5/10)

Why this verdict

Baseline: Oracle assigns CVSS 9.8 (CRITICAL) for network, low-complexity unauthenticated access with full CIA impact.
Exposure friction: Oracle EBS web tiers are overwhelmingly internal-only; public internet exposure is a small fraction of deployments, so unauthenticated internet access is not the default.
Role multiplier: In typical line-of-business ERP deployments, a successful chain compromises the EBS instance and its connected financial/HR data, but it does not by itself deliver domain, fleet, or IAM takeover. Oracle EBS is not a canonical high-value-role component (not a DC, IdP, hypervisor, PAM, backup, kernel agent, or edge appliance), so no CRITICAL floor applies; however the business data impact caps the floor at HIGH.
Exploit maturity: No KEV listing, no in-the-wild exploitation, no public PoC—this is a vendor-advisory-only risk today.
Adjusted from 9.8 to 8.5 to reflect reduced reachability; HIGH severity.

Why not higher?

The main blocker to CRITICAL is exposure. Oracle's CVSS assumes the endpoint is reachable by any network attacker. In most enterprise deployments, Oracle EBS is behind VPN/firewall and not internet-facing. Without a KEV listing, active exploitation, or public PoC, the real-world urgency does not justify the vendor's top score. If the instance is public-facing, treat as CRITICAL.

Why not lower?

Oracle's advisory indicates the vulnerability is trivially exploitable without credentials once network access exists. The compromised component sits at the core of the ERP application tier and can expose regulated financial and HR data, enabling fraud and business disruption. Even an internal-only deployment is one stolen VPN credential or compromised workstation away from full compromise, so this cannot be MEDIUM or LOW.

06 · Verification

Crowdsourced verification payload.

Run on the Oracle EBS application tier as the applmgr user. Copy the script to /tmp and execute: bash /tmp/verify_cve_2026_101767.sh. No elevated privileges beyond applmgr. Because the exact Oracle patch bug number is not publicly mapped to this CVE, the script may output UNKNOWN; use Oracle Support Doc for CPU Oct 2026 to confirm patch status.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/bin/bash
# Verify Oracle EBS application tier for CVE-2026-101767 patch status.
# Run as applmgr on the EBS application tier.
set -u

if [ "$(id -un)" != "applmgr" ]; then
  echo "UNKNOWN - must run as applmgr"
  exit 2
fi

# Source the EBS runtime environment; adjust path to your EBSapps.env if different.
if [ -f /u01/install/APPS/EBSapps.env ]; then
  . /u01/install/APPS/EBSapps.env run >/dev/null 2>&1
else
  echo "UNKNOWN - EBSapps.env not found at default path"
  exit 2
fi

# Check for the October 2026 CPU patch marker. Oracle CPU patches do not reliably expose CVE IDs,
# so we search for the CPU label and known bug number placeholder. Replace 99999999 with the
# actual Oracle EBS AD patch bug number from the October 2026 CPU once available.
PATCH_MARKER="CVE-2026-101767|CPOCT2026|OCT-2026 CPU|99999999"
STATUS_OUTPUT=$(adop -status -detail 2>/dev/null | grep -Ei "$PATCH_MARKER")
OPATCH_OUTPUT=$(opatch lsinventory -oh "$ORACLE_HOME" 2>/dev/null | grep -Ei "$PATCH_MARKER")

if [ -n "$STATUS_OUTPUT" ] || [ -n "$OPATCH_OUTPUT" ]; then
  echo "PATCHED"
  exit 0
elif [ -z "$STATUS_OUTPUT" ] && [ -z "$OPATCH_OUTPUT" ]; then
  # Could not confirm; manual review required against Oracle Support Doc ID for CPU Oct 2026.
  echo "UNKNOWN - no patch marker found; verify CPU Oct 2026 patch in Oracle Support"
  exit 2
else
  echo "VULNERABLE"
  exit 1
fi