Secretus logo
newsoraclee-business-suitecve-2026-101767

Oracle E-Business Suite CVE-2026-101767: Probing Started Days After the Patch, and the APPS Account Is the Prize

Horizon3.ai found an unauthenticated SQL injection in Oracle E-Business Suite that can chain to code execution. Oracle patched it on 20 October, and decoy systems saw exploit attempts a week later. What to patch, hunt and rotate.

·8 min read·Secretus Editorial

An ERP system is where an organisation's payroll, procurement and finance data live, and its database account is one of the most powerful credentials the company owns. Oracle's October 2026 Critical Patch Update, released on 20 October, fixed CVE-2026-101767, a flaw in Oracle E-Business Suite's Application Object Library rated 9.8. Horizon3.ai, which found it, describes an unauthenticated SQL injection that can be chained to remote code execution. On 27 October, the threat-intelligence firm Defused Cyber recorded exploratory exploit attempts against its decoy EBS systems.

That is probing, not confirmed compromise. It is also the pattern that tends to precede real exploitation, and Horizon3 has published technical details and indicators.

What is confirmed

According to The Hacker News and to summaries of Horizon3's advisory, researchers Brandon Peterson, Jimi Sebree and Noah King reported the flaw to Oracle on 24 July. The vulnerable component is the Thin Client Framework servlet reached at a path under /OA_HTML, which Horizon3 says is allowed through the default E-Business Suite URL firewall configuration. One summary lists supported versions 12.2.3 to 12.2.15 as affected; check the Oracle patch documentation for your release rather than relying on that.

The Hacker News reports that exploitation gives SQL execution as the APPS database user, which can read or modify application data, and that chaining to operating-system commands runs as the E-Business Suite application account. It cites financial, payroll, human-resources and procurement records as the kind of data in reach.

Horizon3's indicators include unauthenticated POST requests to the servlet that instantiate a particular data-server class, followed by activity in the backend database. The workarounds reported are to remove the servlet from the URL firewall allowlist, restrict web-tier access to trusted networks and monitor the application host and database.

What is not established

  • Confirmed compromises. The reporting we read describes scanning and exploratory attempts on decoys. It reports no confirmed victims, and the flaw was not on CISA's known-exploited list when we checked.
  • How many systems are exposed. A summary cites Shadowserver tracking over 670 internet-exposed E-Business Suite instances. We have not verified that figure, and it counts exposure, not vulnerability.
  • A public exploit. The reporting does not say one is circulating. Horizon3 has published technical details and indicators, which is not the same thing but shortens the path.
  • Who is probing. No attribution.

Why the database account matters

The APPS user is the account the application tier uses to talk to the database. Access as that user is not limited to rows in tables: it can reach the application's configuration tables, scheduled-job parameters and any credentials the installation stores for integrations with banks, payment processors, mail servers, directories and other systems. What exactly is there depends on how your instance was set up, which is why an inventory is the first piece of useful work.

The step from SQL injection to operating-system commands, if it works in your environment, places the attacker on the application server with the E-Business Suite account's file access, which commonly includes configuration files and wallets for the same integrations.

What to do

  1. Apply the October 2026 patch. Use Oracle's patch documentation for your release. If you cannot patch yet, remove the servlet from the URL firewall allowlist and restrict the web tier to trusted networks.
  2. Take the web tier off the open internet where you can. Many deployments expose E-Business Suite for supplier or employee self-service. Put it behind a VPN, a reverse proxy with an allowlist or a managed access gateway.
  3. Hunt now. Search web and database logs for unauthenticated POSTs to the servlet and for unusual database activity from the web tier, starting from 20 October. Preserve logs before changes.
  4. Inventory what the instance stores. List the credentials in application configuration, scheduled jobs and integration setups: bank and payment interfaces, mail relay, directory and single sign-on, database links and wallets.
  5. If you find signs of exploitation, rotate by dependency. The APPS password and the application account first, then integration credentials, then anything those could reach. Rebuild the application server if code execution is suspected.
  6. Plan for the extortion pattern. If sensitive records were read, involve legal and communications early; we have no evidence this flaw has been used that way.

The handover step

A rotation across an ERP produces new passwords for integration owners in finance, payroll and IT, often spread across teams and vendors. Under pressure these go into a ticket or a chat thread. Keep new values out of the incident record, and send each one once, to the one person who needs it, over a channel that does not keep it.

Where Secretus fits, and where it does not

Secretus covers that handover: a person encrypts a short text secret in the browser and shares a link that stops working after the expiry they set or the first successful open. Team Split can require several holders to reconstruct a high-value text secret.

It is not an ERP security tool. It cannot patch Oracle, search your logs, inspect what an instance stores or rotate a database password for you. Use Oracle's guidance and your own process for that, and a one-time link for the moment one person gives another a new credential.

Sources