CVE-2026-101767: is my Oracle E-Business Suite vulnerable? The AppsTCFServer self-check

CVE-2026-101767 in 30 seconds

CVE-2026-101767 is a flaw in the Core component of Oracle Application Object Library, the foundation layer every Oracle E-Business Suite module sits on. An attacker who can reach the EBS web tier over HTTP, with no account, can send a crafted request to the Thin Client Framework servlet at /OA_HTML/AppsTCFServer and execute SQL with the privileges of the APPS database user. APPS owns the application schema, so that alone means read and write access to every table in the ERP. Horizon3 reports the chain continues to operating system command execution as the EBS application account. Oracle rates it CVSS 3.1 9.8 Critical (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) and lists it as remotely exploitable without authentication in the October 2026 Critical Patch Update. The reporters are Brandon Peterson, Jimi Sebree and Noah King of Horizon3.ai, who disclosed it to Oracle on July 24, 2026, 88 days before the fix.

The same CPU carries 194 EBS fixes, 31 of them unauthenticated and remote. One of them, CVE-2026-101809 in the Workflow Notification Mailer, is rated 10.0. If you have seen “Oracle EBS 10.0” in a headline this week, that is the one, not CVE-2026-101767. Both ship in the same patch set, so a single CPU application covers both.

What AppsTCFServer is, and why no login is needed

Every write-up names the servlet. None explains it, so here is the plain version. The Thin Client Framework (TCF) is a legacy bridge from the Oracle Forms era. Forms runs as a Java applet on the user’s desktop, and some Forms screens need server-side Java to do their work: the Gantt chart in Projects and in the CRM Assignment Manager and Scheduler is the canonical example. Rather than open a raw socket from the applet, Oracle routed those calls over HTTP through a servlet, oracle.apps.fnd.tcf.SocketServer, mapped at /OA_HTML/AppsTCFServer. The class Horizon3 names in its indicators, oracle.apps.jtf.gantt.server.GanttDataServer, is the server-side data provider for those Gantt views.

The part that makes this a 9.8 rather than an 8.8 is the first word of Oracle’s description: unauthenticated. The Forms applet that legitimately uses TCF carries its own session state, so the servlet was built to accept connections first and sort out identity later. Horizon3 reports the endpoint is permitted by the default EBS URL firewall configuration. The CISA enrichment on the CVE record assigns CWE-306, missing authentication for a critical function, and CWE-287, improper authentication; Horizon3 adds CWE-89, SQL injection. The honest summary is that an authentication gap and an injection bug met in a servlet nobody had on their inventory.

Am I affected? The 10-minute self-check

Three checks, in the order that changes your decision fastest. Run them on every environment, including the DR clone and the test instance refreshed from production last quarter; those run the same code and usually have weaker network controls.

1. Patch level: do not trust the About page

Oracle ships a checker for exactly this. Download ECPUC (Patch 35583866, refreshed for October 2026) and run ECPUC.sql as APPS; it writes ECPUC.lst with the CPU level you are actually on and every missing fix. For the Java tier, run EJCPUC (Patch 37171025). If you prefer a query, the applied-patch tables are authoritative; substitute the EBS CPU patch number from KA1818 (it is behind the My Oracle Support login, so we cannot reproduce it here):

-- Is the October 2026 EBS CPU patch applied? (bug_number from MOS KA1818)
SELECT bug_number, creation_date
FROM   ad_bugs
WHERE  bug_number = '&cpu_bug_number';

-- Current codelevels for the technology stack
SELECT abbreviation, codelevel
FROM   ad_trackable_entities
WHERE  abbreviation IN ('ad', 'txk', 'atg_pf');

Use ad_bugs rather than ad_applied_patches; merged patches hide the individual number in the latter.

2. Allowlists: is the servlet allowed?

EBS 12.2 has two allowlists and they are different things. Allowed Resources is the application-level attack-surface list that applies to every node; it is controlled by the FND_SEC_ALLOWED_RESOURCES profile option, which should read CONFIG (enforcing). ALL means it is switched off, which Oracle documents as a diagnostic setting. The URL firewall is the Apache rewrite rule set in url_fw.conf, and it only applies to external (DMZ) nodes. Check both:

-- Allowed Resources enforcing? Expect CONFIG at site level
SELECT p.profile_option_name, v.profile_option_value
FROM   fnd_profile_options p
JOIN   fnd_profile_option_values v ON v.profile_option_id = p.profile_option_id
WHERE  p.profile_option_name = 'FND_SEC_ALLOWED_RESOURCES';

# URL firewall on each external web node: is AppsTCFServer allowed?
find $IAS_ORACLE_HOME -name url_fw.conf -exec grep -Hn 'AppsTCFServer' {} +
# A live RewriteRule line (not commented out) means it is allowed through the DMZ

Then open Functional Administrator, Allowed Resources, Management by Resource, and search for AppsTCFServer. If it shows as allowed and you cannot patch today, that screen is also where you deny it (next section).

3. Reachability: what the internet sees

From a network position you do not trust (a phone on mobile data is fine), ask the web server whether the path is served. This is an ordinary request for the URL; it does not test the flaw.

curl -sk -o /dev/null -w '%{http_code}\n' https://ebs.example.com/OA_HTML/AppsTCFServer

Write down three dates while you are at it: the CPU release (October 20), the first public PoC (October 26), and the day you patched or denied the servlet. The gap is the window to review in the detection section. If you are still unpatched, the window is still open.

If you cannot patch today: deny the servlet, and know what breaks

Oracle has published no workaround specific to this CVE, only its standard language that blocking the protocol “may be possible to reduce the risk” but is “not a long-term solution.” Horizon3’s recommendation is to remove /OA_HTML/AppsTCFServer from the URL firewall allowlist and restrict the web tier to trusted networks. In practice that is three moves:

• Allowed Resources (all nodes): Functional Administrator, Allowed Resources, Management by Resource, find the AppsTCFServer servlet entry, Deny. Resource-level changes refresh in about 60 seconds; switching the profile option itself needs an oacore bounce. Set FND_SEC_LOG_RESOURCES so denied requests are logged; that log becomes your detection feed.
• URL firewall (DMZ nodes): copy url_fw_conf_FMW.tmp into $FND_TOP/admin/template/custom/, comment out the AppsTCFServer allow rule, run AutoConfig, restart OHS. Editing the generated url_fw.conf directly works until the next AutoConfig run silently puts the rule back.
• Edge: on the reverse proxy or WAF, deny every method to /OA_HTML/AppsTCFServer from untrusted sources. Restrict outbound egress from EBS hosts; that was the control that limited damage in the 2025 campaign.

What breaks. The TCF server exists to serve Forms. Oracle’s CRM documentation states the Assignment Manager requires it “to connect to Scheduler and for Gantt charts to display,” and Integrigy noted years ago that TCF “can not be disabled without a customization.” Expect Forms-based Gantt and scheduling views (Field Service Assignment Manager and Scheduler, Projects and ASCP Gantt screens) to fail with a “unable to establish a connection with the TCF SocketServer” style error on any node where it is denied. Those users are almost always internal, which is why the low-regret sequence is: deny on external nodes immediately, deny on internal nodes if Forms Gantt is not in use, and patch everything regardless.

What does not help. Requiring SSO or MFA for EBS logins changes nothing; the servlet is reached before any login. A WAF signature on one proof of concept buys hours, not weeks. “Our EBS is internal only” reduces urgency, not exposure: the 2025 Cl0p intrusions and the ShinyHunters PeopleSoft campaign this summer both reached ERP web tiers from positions that were nominally inside.

Detection: where the published indicators show up

Horizon3 published four indicators of compromise with its advisory: unauthenticated POST requests to /OA_HTML/AppsTCFServer that instantiate GanttDataServer, followed by database activity; SQL reconnaissance shortly afterwards (database version, current user, directory objects); unexpected files in $APPLPTMP; and the oracle account spawning /bin/sh through the Concurrent Manager. The news coverage repeats them without saying where to look. By layer, for 12.2 (the $INST_TOP/logs/ora/10.1.3/Apache/ convention is 12.1 only):

• Web tier. OHS access logs live under $IAS_ORACLE_HOME/instances/*/diagnostics/logs/OHS/EBS_web_*/. Every TCF call is a POST to the one path, and legitimate traffic comes from Forms clients on internal ranges with Java user agents. Count POSTs to the servlet by source address since October 20 and compare the list against your Forms client ranges; anything from outside them is the first thing to explain. The common log format does not record request bodies, so the class name is only visible if a proxy or WAF logs bodies. If you denied the servlet with Allowed Resources and enabled FND_SEC_LOG_RESOURCES, that log shows every attempt since.
• Database. Review FND_CONCURRENT_REQUESTS for requests since October 20 whose program is a host, Java or spawned type and whose requester you cannot account for, and DBA_OBJECTS for Java sources, Java classes and directory objects created since the same date. If database auditing covers APPS, the reconnaissance signature is version, current-user and directory-object queries arriving from the web tier’s connection pool sessions rather than from a DBA workstation.
• Host. Shells or download tools running as the oracle or applmgr user whose parent is a Concurrent Manager process or the oacore JVM, and files newer than October 20 in $APPLPTMP, $APPLTMP and /tmp that no job accounts for. If you find a shell under the JVM, follow the 2025 playbook from Google’s Threat Intelligence Group and capture memory before restarting; the EBS implants seen then were memory-resident Java.

Exploitation status: probing yes, compromise unconfirmed

The headlines say “actively exploited.” The evidence is narrower, and the distinction matters for how you prioritize. On October 27 at 15:15 UTC, Defused Cyber posted that its EBS decoys “recorded exploratory exploits against CVE-2026-101767” that morning, with a screenshot and no further detail. Every news story since (SecurityWeek, BleepingComputer, Help Net Security) is single-sourced to that post. Censys’s advisory of October 28 states no exploitation in the wild had been identified as of October 27, and counts 2,246 web properties running EBS on the internet; Shadowserver puts exposed instances at over 670, mostly in the United States. The Canadian Centre for Cyber Security updated AV26-1071 to say open-source reporting indicates exploitation; it is the only government body to say so, and it is citing the same post. CISA has not added the CVE to KEV, and Oracle has said nothing beyond its CPU boilerplate.

The timing tells you what the probes are. Proof-of-concept repositories appeared on GitHub from October 26, one day before the honeypot hits. That is scanners and curious operators validating a new tool, not a pre-positioned campaign. It is also exactly how the CVE-2026-46817 story in EBS Payments began this summer: honeypot hits on June 27, KEV listing on July 15. Assume this one follows the same arc.

On the repositories. Treat all of them as untrusted. The 2025 EBS campaign included trojanized “exploit” archives, and a repository that asks you to run it against your own ERP deserves the same suspicion as a phishing attachment. Horizon3 said in its disclosure that technical details would follow and had not published them at the time of writing. Plan on the assumption that working capability is public, because the honeypot hits say it is close enough.

Timeline, and how it compares with the 2025 Cl0p campaign

Most coverage mentions Cl0p in one sentence. The comparison is more useful side by side, because the bugs have opposite timelines.

Two lessons carry over. First, the 2025 pattern was one actor, pre-positioned, exfiltrating quietly for weeks and extorting in bulk afterwards, so the absence of named victims today says very little about what is happening on unpatched hosts. Second, no source links CVE-2026-101767 technically to any earlier EBS bug; it is a different servlet family and not a bypass of a previous patch. The only thing the four recent EBS criticals share is that each lives in an unauthenticated web-tier endpoint that was on the default allowlist.

The dates for this one: July 24, 2026, reported to Oracle; September 28, CVE reserved; October 20, CPU released and Horizon3 advisory published; October 26, first public PoC repositories; October 27, honeypot probing; October 28, Censys and Shadowserver exposure counts, Canadian advisory updated; October 29, this page.

Myths worth correcting

• “It is a 10.0.” It is 9.8. The 10.0 in the same CPU is CVE-2026-101809, Workflow Notification Mailer. Both matter; apply the CPU.
• “It is actively exploited.” It is actively probed on decoys. Nobody has published a confirmed production compromise. Prioritize as if it were exploited, because the gap is days, but do not report it to your board as a known breach vector yet.
• “Oracle calls it a SQL injection.” Oracle’s text says “easily exploitable vulnerability allows unauthenticated attacker” and the CVE record is tagged as improper authentication; the SQL injection framing is Horizon3’s. Both are right: the servlet lacks authentication, and the code behind it has an injection.
• “We are on 12.1, so we are not affected.” You are not listed because you are not supported. The servlet predates 12.2. Treat 12.1 as vulnerable with no fix.
• “SSO in front of EBS covers it.” Only if the SSO layer rejects the request before OHS does. The servlet itself asks nobody for credentials.
• “The GitHub repositories are all fake.” Do not bet your ERP on it. Assume capability, not just scanning.

After the patch: the allowlist nobody audited

You do not need a penetration test to find a CPU you have not applied. Run ECPUC, patch, bounce, verify. That part has a clean ending.

The part that does not is how this bug existed in the first place. Oracle ships an allowlist precisely so that only intended endpoints are reachable, and the vulnerable servlet was on it, as were the endpoints behind the last three EBS criticals. An allowlist is only as good as the inventory it was built from, and this one was built from “what the Forms applet needs,” not from “what an anonymous client can call.” Those are different questions, and the second one is almost never asked of ERP web tiers, REST gateways or the APIs that integrate with them.

That second question is what Operator answers. Give it the surface and a token per role, and it enumerates every operation, tries each one as an anonymous client and as each real identity, and reports a finding only when it can attach a runnable proof: the request that reached data or a function it should not have, replayable by your engineer. For EBS specifically, that means the Integrated SOA Gateway and REST services, the custom integrations that sit beside them, and any servlet the allowlist happens to permit. The free first scan maps which operations are reachable without credentials; it does not run exploits against your ERP. If this week left you unsure what your EBS web tier exposes and to whom, start there, or read how we approach API authorization testing.

Changelog

• 2026-10-29 23:30 UTC: First published. Status reflects Oracle, Horizon3, Censys, CISA KEV (catalog 2026.10.29) and the Defused Cyber report as of the evening of October 29.