Oracle ships 673 patches, including an unauthenticated WebLogic takeover over T3 and IIOP
On September 15, 2026, Oracle released its September Critical Security Patch Update with 673 fixes across 17 product families, including several unauthenticated remote takeovers of WebLogic Server. Inventory every exposed WebLogic instance and cut T3/IIOP before a diffable exploit turns your servers into a target.
September 15, 2026. Oracle publishes its September Critical Security Patch Update. 673 fixes span 17 product families, including several unauthenticated remote takeovers of WebLogic Server. Why it matters: the patch closes at least five maximum-severity flaws in Oracle’s middleware, and the vendor itself concedes that its patches are regularly exploited in the wild when customers fail to apply them.
A heavy month for the middleware stack
September’s CSPU is not an ordinary bulletin. Fusion Middleware alone absorbs 153 fixes, of which 78 vulnerabilities are remotely exploitable without authentication. E-Business Suite absorbs 159, including 19 remotely exploitable without authentication. The concentration is stark: Oracle’s Java application servers, LDAP directories, and identity management carry most of the critical load.
Three products concentrate the immediate risk. WebLogic Server accumulates several takeover flaws, Oracle Internet Directory carries two CVSS 9.9 issues (CVE-2026-83057 and CVE-2026-83058), and Oracle Identity Manager exposes an unauthenticated HTTP flaw rated 9.8 (CVE-2026-70913). The common thread: these are components exposed by design, found in front of business portals, service buses, and identity federation.
WebLogic: the same door, still open
The most watched flaw is CVE-2026-70756, in the core of WebLogic Server. An unauthenticated attacker with network access to the T3 or IIOP protocols can compromise the server and take full control of it. Oracle rates it CVSS 9.8, “easily exploitable,” with no privileges and no user interaction.
What makes this dangerous is the attack surface. WebLogic listens for T3 and IIOP on the same ports as HTTP traffic — TCP/7001 and TCP/7002 by default. An instance that looks, from the outside, like an ordinary web application server therefore accepts T3/IIOP requests without anyone intending it to. Load balancers that forward the full listen port rather than HTTP paths only leave these protocols reachable even when the intended exposure was a web application.
WebLogic’s core has a long history of deserialization flaws reached through these same T3 and IIOP surfaces. Once a fix ships, exploit developers diff it to rebuild the deserialization gadget, and exploitation has historically followed fast. The flaw is not isolated: the same bulletin fixes CVE-2026-70757 and CVE-2026-70748 (both 9.8, same protocols), CVE-2026-83021 in the web container rated 10.0, and CVE-2026-83038 in the TopLink integration rated 9.9.
Which patch, exactly
Oracle ships WebLogic fixes as cumulative bundles (CPU/PSU), not point releases. The artifact to apply is therefore the September 2026 CPU patch for the installed version — 12.2.1.4.0, 14.1.1.0.0, 14.1.2.0.0, or 15.1.1.0.0 — rather than an upgrade to a newer WebLogic release. All four lines are affected: a recent version offers no protection.
Two traps await. The first is contractual: 12c lines still in production depend on Premier or Extended support, which conditions patch access. The second is technical: the patch level reported by a third-party scanner is not proof of application — verification must run against Oracle’s advisory for the exact version.
Until the patch lands, the workaround is a connection filter that rejects T3/IIOP from untrusted networks, or disabling IIOP on ports where no client requires it:
# weblogic.security.net.ConnectionFilterImpl — deny T3/IIOP outside the internal network
# in weblogic.properties (WebLogic 12c):
weblogic.security.net.ConnectionFilterImpl=0.0.0.0/0 * * 7001 deny t3 t3s
weblogic.security.net.ConnectionFilterImpl=10.0.0.0/8 * * 7001 allow t3 t3sThe filter is also declared through the console, Environments → Servers → Protocol → Connection Filter. The idea stays the same: T3/IIOP should never be reachable from the outside, patched or not.
What exposure data shows
Measurements from CyCognito, published on September 16, 2026, sketch the profile of exposed instances. Information technology leads with 30.2% of observed assets, industrials with 29.9%, consumer discretionary with 13.3%. The recurring driver is not the absence of a patch process but the absence of a complete inventory of what is reachable: most assets were identified by service fingerprinting rather than confirmed version detection. The actually vulnerable population is therefore larger than internal records suggest.
Non-production environments — staging, UAT, development — stand out. Often owned by an application team rather than the infrastructure team, they escape production patch discipline while staying just as reachable. Oracle itself notes that attackers have repeatedly succeeded because customers had failed to apply patches that were already available.
Verdict
September’s CSPU restates a truth infrastructure teams know and application teams often ignore: WebLogic is not an ordinary web server, it is an application server whose native protocols open doors that HTTP-only exposure keeps invisible. If you run exposed WebLogic, apply the September 2026 CPU patch without delay and cut T3/IIOP with a connection filter while you wait for a window. If your estate is mostly internal, your real problem is the inventory: before patching, enumerate every instance, non-production included, because that is exactly where external scans find what the inventory forgot. 12c lines must confirm patch access through their support contract before assuming it is available.