Oracle EBS Vulnerability Probed Days After Patch: What to Check

Attackers began probing CVE-2026-101767, a critical Oracle EBS vulnerability rated CVSS 9.8, on the morning of October 27, about a week after Oracle shipped the fix. If your company runs E-Business Suite for payroll, HR or finance, the server hosting your public website may be closer to that data than anyone has checked.

Why should a website owner care about an Oracle EBS vulnerability?

Because Oracle E-Business Suite is where many companies keep their most damaging records: payroll, HR files, the general ledger, supplier payments. Website owners rarely log into EBS. They often share a network, a hosting team or a firewall with it, and that is enough to make this flaw their problem.

The bug, CVE-2026-101767, sits in the Oracle Application Object Library, a core layer most EBS modules depend on. Oracle fixed it in its October Critical Patch Update, released the week before The Hacker News reported the first probing on October 28, 2026.

It scores 9.8 out of 10, a near-perfect score, and the missing 0.2 offers little comfort: no login is required and the end result is code execution on the server.

Horizon3.ai, whose researchers found the flaw, states the stakes plainly. Depending on the deployment, exposed data “may include financial, payroll, HR, and procurement records.” On the operating system, the attacker gets whatever the EBS application account can do.

Horizon3.ai’s own indicators show what that looks like in practice: files written to the EBS temporary directory and shells launched through the Concurrent Manager, the component that runs EBS batch jobs. That is narrower than root, but still wide.

What did attackers try on October 27?

They aimed exploratory exploitation attempts at fake EBS servers. Defused Cyber, a threat intelligence firm that runs decoys built to look like real targets, posted on X that its Oracle E-Business Suite decoys recorded “exploratory exploits” against CVE-2026-101767 on the morning of October 27, one day before the story went public.

A decoy is bait. Hits on bait show that someone understands the bug well enough to aim at it and is hunting for targets. They do not show that any real company was breached. The Hacker News report names no victim, no confirmed compromise and no group behind the traffic.

The timeline still shapes your planning:

• July 24, 2026: Horizon3.ai reports the flaw to Oracle.
• Week before October 28: Oracle ships the fix in its quarterly Critical Patch Update.
• October 27, morning: Defused Cyber’s decoys record probing.
• October 28: The Hacker News reports the activity, citing Horizon3.ai’s advisory and indicators.

Roughly three months passed between the report and the fix. Roughly one week passed between the fix and the first recorded probing. That week was the head start, and it is already gone for anyone who treats Oracle patches as a next-quarter project.

What can CVE-2026-101767 actually do?

It lets anyone who can reach one specific EBS web address run database commands without a password, then turn that into commands on the server itself. Horizon3.ai researchers Brandon Peterson, Jimi Sebree and Noah King describe it as an unauthenticated SQL injection that chains to remote code execution.

The weak point is the Thin Client Framework (TCF) servlet, reachable at /OA_HTML/AppsTCFServer on the EBS web tier. The chain has two stages:

1. Database. The attacker runs SQL as the APPS user. APPS is the central EBS schema with broad access to application data, so the attacker can change records as well as read them. Quietly altered vendor bank details or payroll entries cause quieter and slower-burning damage than a straightforward data dump.
2. Operating system. From there, the attacker runs commands as the EBS application account on the host. The chain ends with a foothold on the machine that runs your ERP.

The public reporting lists no affected EBS versions and no patch ID. Oracle’s guidance is to update to the latest version as soon as possible. Your EBS team should take exact patch numbers and prerequisites from Oracle’s October CPU advisory and EBS patch documentation, because EBS fixes often carry their own installation steps.

Could a hacked WordPress or Joomla site be the way in?

Yes, if that site’s server can reach the EBS web tier. Internet-facing EBS carries the highest risk, but The Hacker News notes that internal systems can also be exploited when an attacker reaches the servlet “from a compromised system or another accessible network segment.”

A hacked public website is a classic foothold. An outdated plugin gives an attacker a web shell on the marketing server. If that server sits on a flat network with finance applications, or the firewall lets it talk to internal web ports, the attacker now has the only thing this flaw requires: network access.

No phishing, no stolen VPN password. We break down how those first footholds get found in how attackers find and target vulnerable websites.

The published workarounds for teams that cannot patch immediately map directly onto this risk:

• Remove /OA_HTML/AppsTCFServer (associated with oracle.apps.fnd.tcf.SocketServer) from the EBS URL firewall allowlist.
• Restrict EBS web-tier access to trusted networks.
• Monitor the EBS application host and database for signs of compromise.

Two cautions. Pulling the servlet from the allowlist blocks the path but leaves the vulnerable code in place, so record it as a mitigation, not a fix. It may also break features that rely on TCF, so test first.

Then push the change through your normal EBS configuration process. Otherwise a routine change later may silently restore the old allowlist entry. And “trusted networks” should never include the subnet hosting your public website.

What should leadership decide this week?

Three things: whether EBS gets an out-of-cycle patch window, who owns the network boundary between the website and the ERP, and whether legal should be on standby.

Patch window. Oracle releases Critical Patch Updates four times a year, in January, April, July and October. Many companies batch EBS updates into a quarterly or semiannual slot because testing an ERP change is expensive.

With probing already recorded, waiting means running a known 9.8 hole for weeks. An emergency weekend has a price you can estimate. Payroll data on a leak site does not.

Ownership. In smaller organizations, marketing or an agency runs the website, while finance IT or an outsourced Oracle partner runs EBS. Nobody owns the gap between them. Ask one person to confirm in writing whether the web host can reach EBS.

Regulatory exposure. Payroll and HR records are personal data almost everywhere. A confirmed compromise of the APPS schema can trigger breach notification duties, such as the GDPR 72-hour clock in Europe and state breach laws in the US, plus contractual notices to banks or customers.

Brief counsel now so a notification decision does not stall for days if your team finds evidence later.

What should you ask the person who runs EBS today?

Start with one question: is the October 2026 Critical Patch Update installed on every EBS instance, including test and disaster-recovery copies? If not, get a date. Then work through the rest:

1. Is /OA_HTML/AppsTCFServer reachable from the internet? From the web server subnet? From office Wi-Fi?
2. If patching is delayed, has the servlet been removed from the URL firewall allowlist, and was that change tested?
3. Were web, database and host logs from mid-October onward preserved before anyone patched or restarted services?
4. Has anyone checked for the indicators Horizon3.ai published?

Those indicators, summarized (full details are in the Horizon3.ai advisory):

• Unauthenticated POST requests to /OA_HTML/AppsTCFServer that instantiate the Gantt data-server class (oracle.apps.jtf.gantt.server.GanttDataServer), followed by backend database activity.
• SQL reconnaissance shortly after anonymous web requests: queries for the database version, current user and directory objects.
• Unexpected files in the EBS temporary directory, $APPLPTMP.
• The oracle account spawning /bin/sh through the Concurrent Manager.

Practitioner’s note. A common mistake in incident response is treating one log line as a verdict. A single request to the servlet is often a scanner and proves little. The sequence is what counts: an anonymous TCF request, then odd SQL from APPS within minutes, then a new file in $APPLPTMP or a shell under Concurrent Manager.

Concurrent Manager runs legitimate batch jobs all day, but it has no reason to launch an interactive shell, so that parent-child pair is a strong signal that does not depend on any malware name.

If you see the full chain, treat it as a host and APPS-schema compromise: isolate, collect evidence, review what data was touched and rotate credentials. Patching will not evict an attacker who is already inside.

Then check the other end of the path. If your public website shares a network with EBS, confirm it is clean. A scan with SiteGuarding Antivirus, plus a review of recently modified PHP files and unfamiliar admin accounts, rules out the most likely pivot.

How is this different from the EBS bugs Cl0p already used?

It is a separate flaw, and nothing in the reporting ties it to Cl0p. Over the past year, two other critical EBS bugs, CVE-2025-61882 and CVE-2026-46817, both also scored 9.8, came under active exploitation. The Cl0p ransomware and extortion crew used the first one.

For CVE-2026-101767, the only recorded activity is exploratory traffic against decoys, with no attribution and no named malware.

The pattern still deserves attention. EBS has now produced three critical bugs in a year, and at least one already fed an extortion operation. The product offers what such crews want: an entry point that needs no login and a pile of sensitive records behind it. That is a reason to patch fast, not evidence of who is probing now.

What is still unknown?

Several basics are missing from the public record as of October 28:

• Which EBS versions are affected and the exact patch IDs.
• Whether any probing has succeeded against a real production system.
• Who is behind the October 27 activity.
• How many EBS instances expose the TCF servlet to the internet.

Published indicators help defenders and attackers alike, and the next report may describe real victims rather than decoys.

FAQ

Is CVE-2026-101767 already patched?

Yes. Oracle fixed it in its October 2026 Critical Patch Update. Take exact patch IDs and prerequisites from Oracle's advisory, since the press reporting does not list them.

Does probing on October 27 mean my company was breached?

No. The recorded attempts hit decoy systems run by Defused Cyber. Check your own logs for the published indicators before drawing conclusions either way.

Will updating WordPress or Joomla fix this?

No. The flaw is in Oracle EBS. Keeping your website clean matters because a hacked site can become the network foothold an attacker needs to reach an internal EBS server.

Can attackers reach Oracle EBS if it is not on the internet?

Yes, if they control another system that can reach the TCF servlet, such as a compromised web server or a host on an adjacent network segment.

What if we cannot install the Oracle patch this week?

Remove /OA_HTML/AppsTCFServer from the EBS URL firewall allowlist after testing, restrict the web tier to trusted networks, and monitor the host and database. Schedule the real patch anyway.

If your public site shares a network with business systems, make sure it is not the weak link. SiteGuarding offers website protection and malware removal that closes off the foothold attackers look for first.