Seven days. That is all the time it took for attackers to begin probing CVE-2026-101767, a CVSS 9.8 unauthenticated SQL injection flaw in Oracle E-Business Suite, after Oracle silently patched it in its October 2026 Critical Patch Update on October 20. By October 27, Defused’s threat intelligence honeypots were already logging exploratory requests against the vulnerable servlet. If your Oracle EBS instance is internet-accessible — and more than 670 are, according to Shadowserver’s global scan — you have a narrowing window to act.

Key Takeaways

  • CVE-2026-101767 (CVSS 9.8) — Unauthenticated SQL injection in Oracle EBS Application Object Library, chaining to OS-level RCE. No authentication required.
  • Attackers exploit a single servlet endpoint — /OA_HTML/AppsTCFServer — that is on Oracle’s default URL firewall allowlist.
  • Successful exploitation gives the attacker SQL access as the privileged APPS database user, followed by OS command execution as the EBS application account.
  • Affected: Oracle E-Business Suite versions 12.2.3 through 12.2.15. Patched in Oracle’s October 2026 Critical Patch Update.
  • Exploit probing detected on October 27, 2026 — just 7 days post-patch. Proof-of-concept code exists publicly.
  • Immediate action: apply the October CPU, remove AppsTCFServer from the EBS URL firewall allowlist, and ensure EBS is not directly internet-exposed.

What Is CVE-2026-101767?

Oracle E-Business Suite is the backbone of financial management, HR, supply chain, and procurement operations at thousands of large enterprises worldwide — including a substantial share of India’s largest banks, manufacturers, and public-sector undertakings. CVE-2026-101767 is a flaw in the Application Object Library component, one of EBS’s core shared services layers, rated CVSS 9.8 under the standard AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H vector. The weakness is classified as CWE-89 (SQL Injection).

The flaw was discovered and responsibly disclosed to Oracle by the research team at Horizon3.ai on July 24, 2026. Oracle included the fix in its October 2026 Critical Patch Update (CPU), released October 20. No public advisory or CVE description was issued alongside the patch — Oracle’s CPU notes only that it addresses a vulnerability in the Application Object Library component. The technical details emerged from Horizon3’s own research publication.

Technical Breakdown: From Servlet to Shell

The attack chain begins with a single unauthenticated HTTP POST request to the Thin Client Framework servlet endpoint:

POST /OA_HTML/AppsTCFServer HTTP/1.1
Host: <target-ebs-host>
Content-Type: application/x-www-form-urlencoded

[crafted Gantt data-server class instantiation payload]

The AppsTCFServer servlet handles requests that instantiate server-side Java objects for Oracle’s Thin Client Framework, including Gantt charting components. The SQL injection sits in the parameter handling of this instantiation path — and because EBS’s default URL firewall allowlist permits requests to this servlet without authentication, the attack reaches the vulnerable code before any EBS login check fires.

Once the injection is triggered, the attacker gains the ability to execute arbitrary SQL statements with the privileges of the APPS database account. In a default Oracle EBS deployment, the APPS account has extensive privileges across EBS schema objects. Horizon3.ai’s research shows the chain continues further: from APPS-level SQL, attackers can leverage Oracle’s built-in database mechanisms to escalate to OS command execution as the EBS application account — effectively full server compromise.

Indicators of Compromise (IoCs) published by Horizon3.ai include:

  • Unauthenticated POST requests to /OA_HTML/AppsTCFServer that reference the Gantt data-server class in the request body
  • Unexpected SQL reconnaissance queries originating from the APPS user in Oracle audit logs
  • Unexpected files appearing in the $APPLPTMP directory (Oracle’s application temporary directory, writable by the application OS account)
  • Exploratory /etc/passwd read attempts in OS-level logs (indicating confirmation-of-compromise activity after initial SQL injection success)
Attribute Detail
CVE ID CVE-2026-101767
CVSS Score 9.8 (Critical) — AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CWE CWE-89 — SQL Injection
Affected Component Oracle EBS Application Object Library — AppsTCFServer servlet
Affected Versions EBS 12.2.3 through 12.2.15 (inclusive)
Authentication Required None
Impact SQL as APPS → OS RCE as EBS app account
Disclosed to Oracle July 24, 2026 (Horizon3.ai)
Patch Date October 20, 2026 (Oracle October CPU)
First Exploit Probing October 27, 2026 (Defused honeypots)
Public PoC Exists Yes (Sploitus listing — Sable-Research)
CISA KEV Listed Not yet (as of October 31, 2026)
Internet-Exposed Instances 670+ (Shadowserver, October 2026 scan)

The Race Between Patches and Attackers

The seven-day gap between Oracle’s CPU release and the first recorded exploit probing illustrates a pattern that security teams must internalise: attackers reverse-engineer patches faster than most enterprises can apply them. Oracle’s October 2026 CPU addressed 334 vulnerabilities across its product portfolio. For a large EBS deployment, testing and applying a CPU is a multi-week exercise involving DBA resources, application owners, regression testing, and change control windows.

The exploitation activity recorded by Defused was characterised as “exploratory” — automated scanners confirming the vulnerable servlet is reachable and testing payload structures. The EBS instances logged in this activity were honeypots. But the clock is running: if the activity pattern matches other high-CVSS Oracle CVEs in 2026, operational exploitation targeting production EBS systems follows exploratory scanning within days to weeks.

SecurityWeek and The Hacker News both reported the probing activity on October 29–30, 2026. At time of writing, no confirmed production compromise has been disclosed — but the absence of disclosure does not mean the absence of compromise.

Why Indian Enterprises Are Especially Exposed

Oracle E-Business Suite enjoys deep penetration in India’s large-enterprise sector. Public-sector banks, insurance corporations, state electricity boards, steel and petrochemical manufacturers, and IT services companies with global delivery centres have standardised on Oracle EBS for financials, HR, payroll, and procurement. Many of these deployments date to the 12.2.x era and carry extensive customisations that slow CPU uptake — organisations routinely operate 2–3 CPU cycles behind current.

There is a second exposure vector specific to Indian deployments: remote access configurations that emerged from the pandemic era. From 2020 onward, many Indian enterprises published EBS login portals directly to the internet for remote workforce access, bypassing the firewall controls that had previously restricted EBS to internal networks. In several cases I have seen personally, the EBS web tier remains publicly reachable — only the login form was protected, while infrastructure-layer servlets like AppsTCFServer were silently exposed. CVE-2026-101767 does not require the login form at all.

What You Should Do Now

Here is the prioritised response I recommend for organisations running Oracle EBS in India and the wider region.

  1. Apply Oracle’s October 2026 Critical Patch Update immediately. This is the complete fix. If your change-management process requires extended testing cycles, treat this as a P1 emergency break-fix and schedule an expedited maintenance window. The window for “exploratory” exploitation to become “operational” exploitation is narrowing.
  2. Block /OA_HTML/AppsTCFServer at the EBS URL firewall now — even before patching. Horizon3.ai’s primary recommended mitigation is to remove this servlet from the URL Firewall allowlist in EBS. This eliminates the externally accessible attack path without any code change and can be done in minutes. Log in to Oracle Applications Manager → Security → URL Firewall and verify that AppsTCFServer is not listed. If your organisation requires this servlet for a legitimate business function, restrict it to specific internal IP ranges.
  3. Audit whether any EBS web tier is publicly internet-accessible. Use your perimeter firewall (FortiGate or equivalent) to confirm whether TCP 443/80 to EBS hosts is reachable from untrusted IP space. If it is, move EBS web access behind a VPN gateway or a zero-trust application proxy immediately. EBS is an enterprise internal application; it has no legitimate reason to accept unauthenticated connections from the open internet.
  4. Review Oracle APPS account activity in audit logs. Query the Oracle database audit tables for unusual SQL activity originating from the APPS user in the window from October 20 to present. Unexpected DDL/DML statements, calls to DBMS_SCHEDULER, or Java stored procedure executions from APPS are red flags. Also check $APPLPTMP for recently created unexpected files.
  5. Isolate the EBS database tier behind zero-trust segmentation. Even if the web tier is compromised, micro-segmentation can prevent the APPS-to-OS privilege chain from reaching your database. On a zero-trust campus architecture with FortiGate-enforced security zones, the EBS application server and Oracle database server should be in discrete zones, with explicit allow policies required for each communication path — not implicit trust between tiers.
  6. Enable FortiGate IPS signatures for Oracle exploit patterns. Oracle EBS RCE attempts generate distinctive HTTP signatures. Confirm that your FortiGate IPS profile includes Oracle Application Server and EBS exploit signatures, and that these are in block (not monitor) mode on the policies protecting EBS-facing segments.
  7. Communicate patch status to your CISO and leadership. CVE-2026-101767 carries a CVSS 9.8 score and has public PoC code. This warrants formal incident-management communication upward in the organisation. If you are an IT leader managing an EBS estate, your CISO should be aware of the patch status today.

Frequently Asked Questions

Does this affect Oracle Cloud ERP (Fusion), or only on-premises EBS?

CVE-2026-101767 affects Oracle E-Business Suite (the on-premises product, versions 12.2.3–12.2.15) only. Oracle Cloud ERP — also known as Oracle Fusion Cloud or Oracle Cloud Applications — is a separate product running on Oracle’s infrastructure and is not affected by this CVE. If you are fully cloud-migrated on Oracle Fusion, this specific vulnerability does not apply. However, hybrid deployments that maintain on-premises EBS alongside Oracle Cloud integrations should still audit and patch the EBS side.

Is exploitation confirmed in production environments, or only on honeypots?

As of October 31, 2026, the publicly confirmed exploitation activity is limited to exploratory probing on Defused’s honeypot systems, detected on October 27. SecurityWeek explicitly notes no other confirmed production exploitations have been publicly reported. However, honeypot telemetry captures only a fraction of total internet exploitation attempts — the absence of confirmed production compromises in public reporting does not mean no production systems have been targeted. Given the CVSS 9.8 score, the existence of public PoC code, and the historical pattern of Oracle EBS CVEs, treating this as an active exploitation risk is the correct posture.

Our Oracle EBS is behind a load balancer/WAF — are we protected?

Possibly — but verify specifically. A WAF rule that blocks requests to /OA_HTML/AppsTCFServer from untrusted sources would prevent exploitation. Many WAF configurations protect the EBS login path and application pages but may not have explicit rules for infrastructure-layer servlets like AppsTCFServer. Confirm with your WAF vendor or configuration that this specific path is blocked for unauthenticated external access. The safest approach remains applying the Oracle CPU patch and removing the servlet from the EBS URL firewall allowlist.

Our EBS upgrade to a newer version is planned for next quarter — do we still need to patch now?

Yes, unambiguously. The upgrade timeline does not reduce the risk of exploitation in the weeks between now and when the upgrade is complete. Attackers will not pause probing while your upgrade project runs. Apply the October CPU patch to your current 12.2.x environment now, and proceed with the version upgrade as planned. The CPU patch is additive and will not interfere with a subsequent version upgrade. If applying the full CPU in an expedited timeframe is not feasible, at minimum apply the URL firewall mitigation and restrict external access to EBS hosts as bridge controls.

Sources and Further Reading

Is Your Oracle EBS Patched — and Properly Segmented?

CVE-2026-101767 is a reminder that enterprise ERP systems are high-value targets and that a single misconfigured servlet can become a full server compromise. At P J Networks, I help organisations across India assess their Oracle EBS exposure, apply zero-trust segmentation around critical application tiers, and build patch processes that close the gap before attackers can exploit it. If you are unsure whether your EBS is exposed or behind the October CPU, let’s talk.

Request a Complimentary EBS Security Assessment →