Back to Intelligence

Oracle September 2026 CSPU: 672 CVEs, 104 Critical — E-Business Suite and WebLogic Patching Playbook

SA
Security Arsenal Team
September 15, 2026
13 min read

On September 15, 2026, Oracle shipped its September 2026 Critical Security Patch Update (CSPU), and it is a big one: 672 unique CVEs addressed across 673 security patches, with 104 fixes (15.5%) rated Critical. Oracle E-Business Suite (EBS) absorbed the largest share of any product family — 159 patches, or 23.6% of the entire release.

This is also the first cycle where defenders need to internalize Oracle's new release cadence. Since May 2026, Oracle has been shipping monthly CSPUs between the larger quarterly Critical Patch Updates (CPUs). The intent is to close high-severity gaps faster — but the operational consequence for your teams is that Oracle estate patch management is now a monthly fire drill, not a quarterly project. If your change-control process still assumes a January/April/July/October rhythm, you are structurally behind.

If you run EBS, WebLogic, Oracle Database, MySQL, Java SE, Fusion Middleware, or any of Oracle's Communications/Retail/Financial Services industry stacks, this CSPU touches your environment. The sections below walk through how to triage it, how to hunt for exploitation of the internet-facing components attackers target first, and how to verify remediation.

Why This Release Demands Immediate Attention

Three numbers matter here:

  • 672 CVEs in one release. Even by Oracle standards (CPUs routinely exceed 300–500 fixes), this is a heavy cycle. Volume matters because statistically, buried in a release this size are remotely exploitable, unauthenticated bugs in network-facing services — historically the class of Oracle flaws (WebLogic deserialization, EBS servlet issues) that get weaponized within days.
  • 104 Critical-rated issues. Oracle reserves Critical for flaws that are remotely exploitable without authentication or that carry high CVSS scores with broad impact. Fifteen percent of the release sitting at Critical severity means your triage list is not short.
  • 159 EBS patches. E-Business Suite is the crown jewel in most Oracle environments — it holds financial data, HR records, supply-chain data, and frequently sits partially internet-exposed for supplier/employee self-service portals. Nearly a quarter of this CSPU targets EBS, which strongly suggests a concentrated audit of EBS attack surface. Attackers read the same patch advisories you do; a patch cluster that dense tells them exactly where the soft spots were.

Technical Analysis

What the CSPU Covers

Oracle's CSPUs span the entire product portfolio. Based on the patch distribution in this release, the affected families include:

  • Oracle E-Business Suite — 159 patches (23.6% of the release), the single largest recipient. EBS patches typically span the applications tier (WebLogic-based), the concurrent processing tier, and the database-tier components. Expect fixes touching the OA Framework, servlets, and integrated SOA Gateway.
  • Oracle Fusion Middleware / WebLogic Server — historically the most exploited Oracle product family. WebLogic vulnerabilities (particularly deserialization and T3/IIOP protocol flaws) are perennial favorites of both ransomware operators and cryptomining crews because they yield unauthenticated RCE on internet-facing middleware.
  • Oracle Database Server — core RDBMS fixes, typically requiring authentication but relevant for privilege escalation and lateral movement once an attacker has any database credential.
  • Oracle Java SE — client and server-side Java fixes; relevant anywhere Java applications deserialize untrusted data.
  • Oracle MySQL — frequently bundled into enterprise stacks and often forgotten in patch cycles.
  • Industry applications (Communications, Financial Services, Retail, Health Sciences, Utilities) and Oracle Linux/Virtualization components.

The New Monthly Cadence: A Process Problem as Much as a Technical One

The shift from quarterly-only CPUs to monthly CSPUs changes the defensive math. Under the old model, organizations had roughly 90 days of exposure per batch. Under the new model, Oracle is telling you: these issues are severe enough that waiting for the quarter is unacceptable. That is an implicit admission that patch-to-exploit timelines have compressed — and it matches what we see in IR engagements, where working exploits for Oracle middleware flaws often appear within 5–14 days of patch release via patch diffing.

Exploitation Status

At the time of publication, the Tenable analysis and Oracle's advisory do not flag specific CVEs in this CSPU as under confirmed active exploitation. Treat that as a temporary condition, not a comfort. The historical pattern for Oracle patch cycles is well established:

  1. Patch released → 2. Researchers and threat actors diff patched vs. unpatched binaries → 3. PoCs surface for the remotely exploitable, unauthenticated issues → 4. Mass scanning and exploitation of WebLogic/EBS internet-facing instances follows.

Given 104 Critical issues, assume several are in the "unauthenticated remote" category and act accordingly. Check the CISA Known Exploited Vulnerabilities (KEV) catalog daily for the next two weeks — Oracle CVEs from large patch cycles are frequent KEV additions, and KEV inclusion carries a binding remediation deadline for federal agencies and a de facto deadline for everyone else.

The Defender's Attack-Surface View

From an attack-chain perspective, the realistic exploitation scenarios against unpatched Oracle estates look like this:

  1. External reconnaissance: Attackers scan for exposed WebLogic consoles (default ports 7001/TCP), EBS self-service portals (8000/8443), and T3/IIOP listeners.
  2. Initial access: Unauthenticated RCE against WebLogic (deserialization over T3/HTTP) or EBS servlet exploitation — no credentials needed.
  3. Execution: The Java process (java.exe / WebLogic's NodeManager or managed server JVM, or the EBS application-tier JVM) spawns a shell — cmd.exe, powershell.exe, /bin/sh, or /bin/bash. This is your highest-fidelity detection opportunity.
  4. Post-exploitation: Webshell drops into the WebLogic/EBS webroot, credential harvesting, crypto-miner deployment, or staging for ransomware.

The common thread across nearly every historical Oracle middleware compromise: the web server or JVM process spawns an operating-system shell or scripting interpreter. That behavior is rare in legitimate operation and is where your detection engineering should concentrate.

Detection & Response

Sigma Rules

The following rules target the post-exploitation behaviors most consistently observed in Oracle WebLogic and EBS compromises: JVM/web-tier processes spawning shells, and webshell-like file drops into Oracle web directories. Tune the path selections to your actual Oracle Home and domain directories before deployment.

YAML
---
title: Oracle WebLogic or Java Process Spawning OS Shell
description: Detects WebLogic server JVM or NodeManager processes spawning command shells or scripting interpreters, a hallmark of Oracle middleware exploitation via deserialization or servlet-based RCE.
references:
  - https://www.tenable.com/blog/oracle-september-2026-critical-security-patch-update-addresses-672-cves
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/09/16
status: experimental
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith:
      - '\java.exe'
      - '\javaw.exe'
      - '\NodeManager.exe'
      - '\startWebLogic.cmd'
    ParentCommandLine|contains:
      - 'weblogic'
      - 'oracle'
      - 'fmw'
      - 'oacore'
      - 'forms'
  selection_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
      - '\certutil.exe'
      - '\bitsadmin.exe'
      - '\curl.exe'
      - '\wget.exe'
      - '\whoami.exe'
      - '\net.exe'
      - '\nltest.exe'
  condition: selection_parent and selection_child
falsepositives:
  - Oracle Forms/Reports runtime spawning legacy utilities (rare; baseline per host)
  - Custom administrative wrappers invoking scripts from WebLogic start scripts
level: high
---
title: Webshell or Script File Dropped in Oracle Web or EBS Application Directory
description: Detects creation of executable script files (JSP, ASPX, PHP) in Oracle WebLogic server or E-Business Suite web deployment directories, consistent with webshell deployment following middleware exploitation.
references:
  - https://www.tenable.com/blog/oracle-september-2026-critical-security-patch-update-addresses-672-cves
  - https://attack.mitre.org/techniques/T1505/003/
author: Security Arsenal
date: 2026/09/16
status: experimental
logsource:
  category: file_event
  product: windows
detection:
  selection_path:
    TargetFilename|contains:
      - '\Oracle\Middleware\'
      - '\user_projects\domains\'
      - '\servers\'
      - '\FMW_Home\'
      - '\comn\html\'
      - '\oa_html\'
      - '\product\'
  selection_ext:
    TargetFilename|endswith:
      - '.jsp'
      - '.jspx'
      - '.jspf'
      - '.war'
      - '.ear'
      - '.class'
      - '.aspx'
      - '.php'
  filter_deployers:
    Image|endswith:
      - '\java.exe'
      - '\wlsdeploy.exe'
  condition: selection_path and selection_ext and not filter_deployers
falsepositives:
  - Legitimate application deployments via WLST, Oracle Enterprise Manager, or CI/CD pipelines — baseline deployment windows and service accounts, alert outside them
level: high
---
title: Linux Oracle Process Spawning Interactive Shell
description: Detects Oracle JVM, WebLogic, or EBS application-tier processes on Linux spawning shells or download utilities, a strong indicator of post-exploitation activity.
references:
  - https://www.tenable.com/blog/oracle-september-2026-critical-security-patch-update-addresses-672-cves
  - https://attack.mitre.org/techniques/T1059/004/
author: Security Arsenal
date: 2026/09/16
status: experimental
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentCommandLine|contains:
      - 'weblogic'
      - 'NodeManager'
      - '/oracle/'
      - 'oacore'
      - 'formsweb'
      - 'java'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/zsh'
      - '/curl'
      - '/wget'
      - '/nc'
      - '/ncat'
      - '/python'
      - '/python3'
      - '/perl'
      - '/base64'
  condition: selection_parent and selection_child
falsepositives:
  - Oracle Enterprise Manager agent jobs executing shell-based monitoring scripts — filter by known OEM agent parent PIDs and service accounts
  - Legitimate opatch/installer wrapper scripts during maintenance windows
level: high

KQL — Microsoft Sentinel / Defender

This hunt query surfaces Oracle middleware processes spawning shells or scripting interpreters across Windows endpoints via Defender process telemetry, plus a second query for Linux estates forwarding Syslog/CEF to Sentinel. Run both over a rolling 14-day window after patch release — that is the window in which exploitation typically begins.

KQL — Microsoft Sentinel / Defender
// Hunt: Oracle WebLogic/Java processes spawning shells or LOLBins (Windows)
DeviceProcessEvents
| where TimeGenerated > ago(14d)
| where InitiatingProcessFileName in~ ("java.exe", "javaw.exe", "NodeManager.exe")
   or InitiatingProcessCommandLine has_any ("weblogic", "oracle", "oacore", "fmw")
| where FileName in~ ("cmd.exe", "powershell.exe", "pwsh.exe", "wscript.exe", "cscript.exe",
                      "mshta.exe", "rundll32.exe", "certutil.exe", "bitsadmin.exe",
                      "curl.exe", "wget.exe", "whoami.exe", "net.exe", "nltest.exe")
| project TimeGenerated, DeviceName, AccountName,
          InitiatingProcessFileName, InitiatingProcessCommandLine,
          FileName, ProcessCommandLine, SHA256, FolderPath
| order by TimeGenerated desc;

// Hunt: Oracle-tier processes spawning shells/downloaders (Linux via Syslog)
Syslog
| where TimeGenerated > ago(14d)
| where Facility == "user" or Facility == "daemon"
| where SyslogMessage has_all ("java", "bash") or SyslogMessage has_all ("weblogic", "sh")
| extend ParentProc = extract(@"PPID.*?(java|weblogic|NodeManager)", 1, SyslogMessage)
| where SyslogMessage has_any ("/bin/sh", "/bin/bash", "curl ", "wget ", "nc ", "python")
| project TimeGenerated, Computer, ProcessName, SyslogMessage
| order by TimeGenerated desc;

Velociraptor VQL

This artifact hunts for the same behavioral pattern at scale — any process tree where a Java/WebLogic process is the parent of a shell, downloader, or enumeration tool — and works against both Windows and Linux endpoints in your fleet. Deploy it as a hunt across all servers tagged as Oracle application/database tiers.

VQL — Velociraptor
-- Hunt: Oracle middleware processes with suspicious child processes
-- Targets post-exploitation behavior observed in WebLogic/EBS compromises
LET procs = SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
  FROM pslist()

LET suspicious_children = SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
  FROM procs
  WHERE Name =~ '(?i)^(cmd|powershell|pwsh|wscript|cscript|mshta|rundll32|certutil|bitsadmin|curl|wget|whoami|net|sh|bash|dash|nc|ncat|python|python3|perl)(\.exe)?$'

SELECT suspicious_children.Pid AS ChildPid,
       suspicious_children.Name AS ChildName,
       suspicious_children.CommandLine AS ChildCmdLine,
       suspicious_children.Username AS ChildUser,
       suspicious_children.CreateTime AS ChildStartTime,
       parent.Pid AS ParentPid,
       parent.Name AS ParentName,
       parent.CommandLine AS ParentCmdLine
FROM suspicious_children
JOIN procs AS parent ON suspicious_children.Ppid = parent.Pid
WHERE parent.Name =~ '(?i)java|nodemanager|weblogic'
   OR parent.CommandLine =~ '(?i)weblogic|oracle|oacore|fmw_home'

Remediation Verification Script

Use this Bash script on Linux-based Oracle application and database tiers to inventory installed Oracle homes, capture current patch levels via opatch lsinventory, and flag internet-facing listeners that should be network-restricted until patching completes. Run it via your configuration management tooling across the fleet, and re-run after patch deployment to produce before/after evidence for change records.

Bash / Shell
#!/bin/bash
# Oracle September 2026 CSPU — patch level inventory & exposure audit
# Run as root or the Oracle software owner on each app/db tier host.

REPORT="/var/log/oracle_cspu_audit_$(date +%Y%m%d).log"
echo "=== Oracle CSPU Audit: $(hostname) — $(date) ===" | tee -a "$REPORT"

# 1. Locate Oracle inventories and enumerate installed Oracle homes
echo -e "\n[+] Oracle Homes discovered:" | tee -a "$REPORT"
for INV in $(find /u01 /opt /app -maxdepth 4 -name "oraInst.loc" 2>/dev/null); do
  INV_DIR=$(grep inventory_loc "$INV" | cut -d= -f2)
  [ -f "$INV_DIR/ContentsXML/inventory.xml" ] && \
    grep -oP 'HOME NAME="[^"]+" LOC="[^"]+"' "$INV_DIR/ContentsXML/inventory.xml" | tee -a "$REPORT"
done

# 2. Capture opatch inventory per Oracle home (adjust ORACLE_HOME list to your estate)
for OH in /u01/app/oracle/middleware/Oracle_Home /u01/app/oracle/product/*; do
  if [ -x "$OH/OPatch/opatch" ]; then
    echo -e "\n[+] opatch lsinventory for $OH:" | tee -a "$REPORT"
    sudo -u oracle "$OH/OPatch/opatch" lsinventory -oh "$OH" 2>/dev/null | \
      grep -E "Patch applied|Oracle Interim Patch|unique patch ID" | tee -a "$REPORT"
  fi
done

# 3. Flag exposure: listeners on WebLogic/EBS/T3 ports reachable beyond localhost
echo -e "\n[+] Network exposure check (7001/7002 WebLogic, 8000/8443 EBS, 1521 DB):" | tee -a "$REPORT"
ss -tlnp 2>/dev/null | grep -E ':(7001|7002|8000|8001|8443|8888|1521)\b' | tee -a "$REPORT"

# 4. Check whether T3/IIOP is externally reachable (should be blocked at the edge)
echo -e "\n[!] ACTION: Verify firewall rules restrict ports above to management/app tiers only." | tee -a "$REPORT"
echo "=== Audit complete. Evidence written to $REPORT ===" | tee -a "$REPORT"

Remediation

  1. Pull the official advisory and map your estate. Start with the Oracle Critical Patch Update Advisory for September 2026 at https://www.oracle.com/security-alerts/ and the Tenable breakdown at the source URL above. Cross-reference every Oracle product and version you run — including the ones teams forget: MySQL instances bundled with applications, Java SE runtimes embedded in third-party tools, and industry-specific stacks (Retail, Financial Services, Communications).

  2. Patch E-Business Suite first among equals. With 159 fixes, EBS is the highest-risk surface in this release. Oracle EBS patching requires applying patches via adop (online patching) in the correct sequence — do not attempt to cherry-pick individual CVE fixes. Schedule the patch cycle this week; if your EBS instance has any internet-facing self-service modules (iSupplier, iRecruitment, OTL), treat it as internet-exposed infrastructure and escalate accordingly.

  3. Prioritize by exposure and severity, in this order: (a) internet-facing WebLogic/EBS with Critical unauthenticated remote fixes; (b) internal middleware and application tiers; (c) database tier; (d) client-side Java. A 104-item Critical list requires ruthless triage — exposure beats raw CVSS when deciding what goes first.

  4. Apply interim mitigations while patches are staged:

    • Block T3/IIOP protocol access to WebLogic from untrusted networks at the firewall; restrict port 7001 to administrative jump hosts only.
    • Place EBS portals behind a WAF with virtual patching rules and disable unused self-service modules.
    • Enforce network segmentation so the database tier (1521/TCP) is reachable only from application-tier hosts.
    • Enable WebLogic connection filters to restrict T3 traffic to known application servers.
  5. Test in a cloned environment, then deploy within 14 days. Oracle patches historically carry regression risk (especially EBS and Fusion Middleware), so validate against a cloned tier first — but do not let testing become an excuse for indefinite delay. Given the patch-to-exploit compression discussed above, a 14-day maximum window for Critical, internet-reachable systems is a defensible standard; KEV additions would tighten that further.

  6. Deploy the detections now, not after patching. The Sigma rules, KQL queries, and VQL hunt above should be live in your SIEM/EDR before patching completes, because the window between advisory release and full deployment is exactly when exploitation attempts land. Any hit on the JVM-spawning-shell rules on an unpatched host should trigger IR escalation.

  7. Monitor CISA KEV daily. Oracle CVEs from large releases are routinely added to the KEV catalog once exploitation is confirmed. KEV inclusion converts your patching timeline from "risk-based" to "deadline-based" — build the KEV feed into your vulnerability management workflow (https://www.cisa.gov/known-exploited-vulnerabilities-catalog).

  8. Fix the process, not just the patches. With monthly CSPUs now Oracle's standard, retool your patch governance: a standing monthly Oracle patch window, pre-approved change templates for middleware/EBS patching, and an automated inventory (the audit script above is a starting point) so you always know which homes exist and what patch level they're at. The organizations that struggle with Oracle security updates are the ones treating each release as a bespoke project.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub

Is your security operations ready?

Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.