Defused says its decoys logged exploit attempts at Oracle EBS CVE-2026-101767 7 days after the patch

Seven days from Oracle's patch to a hit on a decoy, and what that does not show

Oracle published its October 2026 Critical Patch Update on 20 October 2026, with a fix for CVE-2026-101767 in Oracle E-Business Suite (EBS). On 27 October the threat intelligence company Defused said its EBS decoys "recorded exploratory exploits" against that flaw "this morning". That is 7 days from patch to first reported attempt (derived: 20 October to 27 October). The two news reports that carried the claim appeared on 28 October, 8 days after the patch (derived).

What the figure does not show is a breach. A decoy is a machine built to be attacked, so a hit on one means someone sent an exploit at something that looked like EBS. None of the sources read for this briefing names a compromised organisation, a count of attempts, an attacker or a source address. CISA's Known Exploited Vulnerabilities catalogue, in the version released at 19:00 UTC on 27 October, does not list the CVE. The seven days also say nothing about the 88 days before the patch, when Horizon3.ai says the flaw was already in Oracle's hands (derived below).

Read between 18:40 to 18:55 UTC on Wednesday 28 October 2026. The primaries are Oracle's own advisory and its full text version, the CVE.org and NVD records, CISA's catalogue file, and the advisory published by Horizon3.ai, the firm Oracle credits with the report. Defused's own post is on X, which tells crawlers not to fetch it, so it was not read: what Defused said comes from SecurityWeek and BleepingComputer quoting it, and the briefing says so each time. The Hacker News was not read at all because it answered with a Cloudflare challenge. Nothing was filled in, submitted or downloaded other than saved pages.

Stated and not stated: the record on CVE-2026-101767, field by field

The table takes each fact a defender needs and says where it is printed. "Not stated" means not found in a source that was read in full. It does not mean the answer does not exist. The affected range is copied as Oracle prints it, 12.2.3-12.2.15; Oracle gives no single fixed version number, because the fix is a set of patches listed in a My Oracle Support note that needs a login.

The dates, with the arithmetic

Every day count below is derived from dates printed in the sources, and the diagram says so. From 24 July to 20 October is 88 days (24 July to 24 October is 92 days, less 4). From 20 October to 27 October is 7 days, and to 28 October is 8 days. CISA's enrichment on the CVE record, dated 21 October at 10:55 UTC, rates exploitation as none, the flaw as automatable, and the technical impact as total. That is a statement about the day after the patch, not about the day of the decoy hit.

Zoom

One more date sets the scale. Horizon3.ai's page says that on 24 July it also assessed and notified customers of its own Rapid Response service. So for 88 days, by Horizon3.ai's account, at least one outside party held working knowledge of an unauthenticated flaw in a widely used ERP product. That is the normal cost of coordinated disclosure, and the page does not say more. It does explain why a patch day is also the day public technical detail starts to circulate: Horizon3.ai published the affected path and host indicators within a minute of the CVE record, at 21:23 UTC against 21:22 UTC.

How the flaw works, in Horizon3.ai's words, and how little Oracle says

Oracle's text for CVE-2026-101767 is one sentence on the product and one on the result: an easily exploitable flaw lets an unauthenticated attacker with network access over HTTP compromise Oracle Application Object Library, and a successful attack "can result in takeover" of it. It says nothing about SQL injection and nothing about running commands. The phrase "remote code execution" in headlines comes from elsewhere.

It comes from Horizon3.ai, whose advisory says the flaw is "an unauthenticated SQL injection vulnerability" in the Thin Client Framework (TCF) servlet that "can be chained to achieve remote code execution". In its account an attacker sends a crafted request to the servlet, runs SQL as the APPS database user, and then runs operating system commands as the EBS application account. It adds that the endpoint is "permitted through the default EBS URL firewall configuration". That one sentence matters most to a defender, because the control named a firewall is the control that does not stop it.

Zoom

How much weight does that chain bear? Horizon3.ai found the flaw, so it knows the code path. It also sells the product that tests for it: the same page carries a NodeZero Rapid Response test for this CVE and a button to book a demo. That does not make the account wrong. It does mean the one detailed public description of the mechanism comes from a firm with a commercial interest in the flaw being taken seriously, and no second source describing the SQL stage was read. CISA's own enrichment of the record points a different way on the weakness label, authentication rather than injection, so the label is not settled across sources. Oracle is the vendor of the product and the author of the advisory, which repeats that attackers have succeeded where customers failed to apply patches.

What "probing" covers: a scan, an exploit attempt, a compromise

The headlines use three different verbs for what happened. BleepingComputer's headline says hackers are scanning for the flaw. SecurityWeek's says they are probing it, and its body calls the flaw "exploited". Defused's own words, as both outlets quote them, are "exploratory exploits" recorded on "decoys". Those are three different claims. Scanning is looking for a version or a banner. An exploit attempt sends something designed to trigger the flaw. A compromise means a real system was taken. Only the second is reported, and only against machines built to be attacked.

Zoom

Who is the source, and what does it gain? Defused is described by both outlets as a threat intelligence firm that runs decoys. A sighting on its network is a data point and also publicity for the firm. This briefing did not check Defused's pricing or product range, and did not read its post. BleepingComputer adds a figure from the Shadowserver Foundation: over 670 Internet exposed EBS instances, most in the United States, and it notes that Shadowserver does not say how many are decoys or already secured. That figure was read in BleepingComputer's text, not on the Shadowserver dashboard, which loads its numbers by script.

A precedent from this year shows how the next weeks can go. SecurityWeek reported on 30 June 2026 that Defused had seen exploitation of a different EBS flaw, CVE-2026-46817 in the Payments product, on its honeypots over the preceding weekend, about a month after Oracle's late May fix. CISA's catalogue file lists that CVE with a date added of 15 July 2026, which is 15 days after SecurityWeek's report (derived). The catalogue file also holds three older EBS entries: CVE-2022-21587, CVE-2025-61882 and CVE-2025-61884. A decoy sighting followed by a catalogue entry is a pattern, not a forecast: nothing in the sources says CVE-2026-101767 will follow it.

Friendly labels on this story, and what each one hides

A comforting or alarming label is not a control and not a finding. Five appear in the coverage of this flaw.

The same pattern, a named control that did not do the job, appears in an earlier briefing on this site about Oracle PeopleSoft, where a firewall rule blocked one spelling of a path and attackers used another. The lesson here is smaller and sharper: check what the control actually does with the path, not what it is called.

One flaw in the news, thirty more that need no login

Oracle's EBS risk matrix in the same update states that it contains 194 new security patches for EBS and that 31 of the vulnerabilities "may be remotely exploitable without authentication". This briefing counted the matrix rows from the saved page and got the same totals: 194 rows, 31 with Remote exploit without auth marked Yes (derived). Four of the 31 score 9.0 or more (derived). The highest is not the one in the news: CVE-2026-101809, in Workflow Notification Mailer, scores 10.0 because its scope changes, one tenth of a point above the 9.8 of the probed flaw.

No source read says any of the other three is being probed or exploited. The point is narrower: a plan that patches only the CVE named in the news leaves 30 other unauthenticated fixes, including a 10.0, to chance. Oracle's page tells customers to apply the whole October update, and to apply the Database and Fusion Middleware parts too, because EBS exposure depends on them.

What to do, in the order worth doing

The first four items follow Oracle's and Horizon3.ai's published advice. The rest are this site's reading of it, and are marked.

Technical details

Oracle publishes no request, payload or indicator for this flaw. Horizon3.ai publishes a servlet path, two class names and three host indicators, which are reproduced below exactly as printed. No proof of concept and no request body is published by either, and none is reproduced or built here. Each block is attributed and dated in its caption, and anything this site derived is labelled.

Block 1 is Oracle's own entry, from the full text version of its advisory. It is what the vendor says is affected and at what score. A defender uses it to match versions and to record the score and vector that Oracle assigned.

CVE-2026-101767
Vulnerability in the Oracle Application Object Library product of Oracle E-Business Suite (component: Core). Supported versions that are affected are 12.2.3-12.2.15. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Application Object Library. Successful attacks of this vulnerability can result in takeover of Oracle Application Object Library.
CVSS 3.1 Base Score 9.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).

Block 2 is an extract, formatted by this site, from the CVE.org record and its CISA enrichment. The affected range, the score and the enrichment are the machine readable form of the same facts. The Exploitation field there says none as of 21 October, and the weakness labels are authentication ones.

cveMetadata.cveId: CVE-2026-101767
cveMetadata.dateReserved: 2026-09-28T15:40:09.505Z
cveMetadata.datePublished: 2026-10-20T21:22:48.577Z
cna.affected.versions: version 12.2.3, lessThanOrEqual 12.2.15, versionType custom
cna.cpeApplicability.criteria: cpe:2.3:a:oracle:application_object_library:*:*:*:*:*:*:*:*
cna.cpeApplicability.versionStartIncluding: 12.2.3
cna.cpeApplicability.versionEndIncluding: 12.2.15
cna.metrics.cvssV3_1.vectorString: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
cna.metrics.cvssV3_1.baseScore: 9.8
adp (CISA-ADP).ssvc.timestamp: 2026-10-21T10:55:05.355891Z
adp.ssvc.options: Exploitation none; Automatable yes; Technical Impact total
adp.problemTypes: CWE-306 Missing Authentication for Critical Function; CWE-287 Improper Authentication

Block 3 is Horizon3.ai's mitigation advice. It names the servlet path and class that the EBS URL firewall allowlist should not contain until the patch is in. A defender checks the allowlist and web server configuration for that path, and tests the change on a copy first.

Until the applicable patches are installed:
Remove /OA_HTML/AppsTCFServer, associated with oracle.apps.fnd.tcf.SocketServer, from the EBS URL firewall allowlist.
Restrict access to the EBS web tier to trusted networks.
Monitor the EBS application host and database for signs of compromise.
Apply access restrictions across all untrusted network paths to the servlet. These measures reduce exposure but do not replace patching.

Block 4 is Horizon3.ai's list of indicators of compromise. They are three things to hunt for: web requests, database activity and host activity. A defender searches web server, database and host logs for each, back to the oldest retained log.

Indicators of Compromise:
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 unauthenticated web requests (database version, current user, directory objects).
Unexpected files in $APPLPTMP and the oracle account spawning /bin/sh via the Concurrent Manager to run OS commands.

Block 5 is the sentence Defused is reported to have posted, as SecurityWeek quotes it. It is a second hand copy: Defused's post was not read. It is included because it is the only statement of what was seen and when.

Our Oracle E-Business Suite decoys recorded exploratory exploits against CVE-2026-101767 this morning, Oct 27

Block 6 is this site's own starting point for a search, built only from the path in block 3. It is derived, it is not a vendor rule, and it will not find requests that reach the servlet by another route or under another name. Adjust the log location and format to your setup.

grep -i "AppsTCFServer" /path/to/web/access_log*

What could not be verified

Defused's post on X was not read, because X's robots file tells automated readers not to fetch it. Every statement of what Defused saw rests on SecurityWeek and BleepingComputer, who print the same sentence. The time zone of "this morning, Oct 27" is not stated, so the 7 days is a calendar day count, not an hour count. The Hacker News was not read because it answered a challenge page. My Oracle Support Note KA923, which lists the patches, needs an account and was not read, so no fixed version number is given and none is invented. The Shadowserver count of over 670 comes from BleepingComputer's text. Horizon3.ai's mechanism, path and indicators were read in full but not tested, and no second source describing the SQL stage was found. Whether a working exploit is public was not established: Horizon3.ai's page prints none, and no search for one was made, by design. The late May fix date for CVE-2026-46817 is from SecurityWeek, not from an Oracle page. NVD's record shows "Awaiting Analysis", so its score and weakness fields may change.

The question that exposes the gap

A trap set for attackers was hit seven days after the patch existed, and the finder had held the flaw for 88 days before that. So the question is not whether your EBS is on the list of the exploited. It is this: if your EBS web tier received an unauthenticated POST to the TCF path on 21 October, which log would show it, and does that log go back far enough to tell you?

Key facts