Talk to an expert
PricingNewsTalk to an expert
Back to Newsroom
Threat Intel

Attackers Probe Critical Oracle E-Business Suite Flaw Days After It Was Patched

A critical unauthenticated SQL injection in Oracle E-Business Suite (CVE-2026-101767, CVSS 9.8) chains to remote code execution and is already being probed days after Oracle's patch. Here is what it does and how to close it.

4T4Tify Team4Tify
Oct 28, 2026·5 min read
Attackers Probe Critical Oracle E-Business Suite Flaw Days After It Was Patched

Attackers Probe Critical Oracle E-Business Suite Flaw Days After It Was Patched

Oracle E-Business Suite (EBS) administrators have a short window to act. A critical vulnerability fixed in Oracle's latest Critical Patch Update is already drawing exploit attempts, with decoy EBS systems recording unauthenticated probes on 27 October, barely a week after the fix shipped.

What happened

The flaw is tracked as CVE-2026-101767 and carries a CVSS score of 9.8. It sits in the Oracle Application Object Library component of EBS, specifically in the Thin Client Framework (TCF) servlet exposed at the path /OA_HTML/AppsTCFServer. A remote attacker who can reach that servlet, with no credentials at all, can inject SQL that runs with the privileges of the APPS database user. From there, the chain continues to operating-system command execution under the EBS application account.

The vulnerability was privately reported to Oracle in late July 2026 and closed in the October Critical Patch Update. Within days, honeypot telemetry showed exploratory exploitation attempts against it. At this stage the activity looks like reconnaissance and testing rather than a confirmed mass-compromise campaign, but the pattern is familiar: EBS has been hit by two other critical, actively exploited flaws in the past year, CVE-2025-61882 and CVE-2026-46817, the first of which was used by the Cl0p extortion crew.

Why it matters

EBS is the system of record for finance, payroll, HR, procurement and supply-chain data in many large organisations. The APPS schema holds essentially all of it. An attacker who gains SQL execution as APPS can read or alter that data, and OS execution as the application account opens the door to persistence, lateral movement and extortion.

Internet-facing EBS web tiers are the obvious first targets. Internal-only deployments are not safe by default: anyone who has already compromised a workstation or another network segment that can reach the web tier can use the same servlet.

What to do

  1. Patch now. Apply the October 2026 Critical Patch Update to every EBS environment, including test and disaster-recovery instances that mirror production.
  2. If you cannot patch immediately, cut off the servlet. Remove /OA_HTML/AppsTCFServer (the oracle.apps.fnd.tcf.SocketServer entry) from the EBS URL firewall allowlist.
  3. Shrink exposure. Restrict access to the EBS web tier to trusted networks and VPN ranges. It should not be reachable from the open internet.
  4. Hunt for signs of compromise. Look for:
    • unauthenticated POST requests to /OA_HTML/AppsTCFServer that instantiate the oracle.apps.jtf.gantt.server.GanttDataServer class, followed by database activity;
    • SQL reconnaissance shortly after unauthenticated web requests (database version, current user, directory objects);
    • unexpected files in $APPLPTMP;
    • the oracle account spawning /bin/sh through the Concurrent Manager.
  5. Verify from the outside. Confirm that the servlet is no longer reachable and that the patch level really is what you believe it to be.

Large ERP platforms like EBS are patched on slow cycles, and the gap between a Critical Patch Update and the first exploit attempts is now measured in days. Our vulnerability scanning service continuously checks exposed hosts for missing patches and reachable high-risk endpoints such as this one, so a flaw like CVE-2026-101767 is flagged before an attacker finds it.

SHARE