Oracle WebLogic CVE-2024-21182: Block T3 & IIOP Now

What You're Dealing With

CISA added CVE-2024-21182 to the Known Exploited Vulnerabilities catalog on June 1, 2026, with a remediation deadline of June 4 — a three-day window that should tell you everything about how seriously this is being taken.

The short version: an unauthenticated attacker with network access to your WebLogic server over T3 or IIOP can compromise the server and walk away with everything it can touch. No credentials required. No social engineering. Just network access and a working exploit.

This is not a theoretical risk. Oracle WebLogic has a well-documented history of being actively exploited in the wild, and unspecified vulnerabilities in this product line have repeatedly turned out to be remote code execution or full data exfiltration primitives. The Oracle CPU July 2024 advisory covers this fix, but a significant number of WebLogic deployments are still running exposed T3/IIOP interfaces on production networks.

If you manage WebLogic — or you support clients who do — stop and address this today.

---

Why T3 and IIOP Are the Problem

T3 is Oracle's proprietary protocol for WebLogic cluster communication and remote management. IIOP (Internet Inter-ORB Protocol) is used for CORBA-based remote object access. Both are legitimate protocols with real operational purposes inside a properly segmented internal network.

The problem is how often they're exposed:

• Default WebLogic installations listen on T3 on port 7001 (HTTP) and 7002 (HTTPS/TLS)
• IIOP typically runs on port 2809, though this varies by configuration
• Many deployments leave these ports open because internal applications or monitoring tools historically used them
• Cloud-lifted WebLogic instances frequently inherit on-premises network rules that made sense internally but are dangerously permissive in a cloud VPC or flat network

When CISA says "unauthenticated attacker with network access via T3, IIOP," they mean anyone who can reach those ports can attempt exploitation. In a misconfigured environment, that's the entire internet.

---

Immediate Triage: Find Your Exposure

Before you patch or mitigate anything, know what you're working with.

Find listening T3/IIOP ports:

Run a targeted port scan against your WebLogic hosts. You're looking for:

• TCP 7001 (default T3/HTTP)
• TCP 7002 (default T3S/HTTPS)
• TCP 2809 (IIOP)
• TCP 2810 (IIOP/TLS)
• Any custom ports defined in your config.xml

Use nmap or your existing vulnerability scanner. If you're an MSP, pull this across all client environments that run Java EE middleware — don't assume WebLogic is only in the obvious places.

Check internet exposure:

If you have internet-facing IP blocks, run a quick Shodan or Censys check against your ranges for WebLogic fingerprints. You may find exposure you didn't know existed.

Check WebLogic version:

Log into the Admin Console or check the server logs for the WebLogic version string. The patch is included in the Oracle CPU July 2024 release. If you're running a version older than that release cycle, you're unpatched.

---

Fix Option 1: Patch First

The authoritative fix is applying the Oracle CPU July 2024 patch. If you have an active Oracle support contract, this should be your primary path.

Practical steps:

• Pull the patch from Oracle's My Oracle Support (MOS) portal
• Test in a staging environment before production if you have one — WebLogic patches occasionally introduce compatibility issues with custom deployments
• Review Oracle's patch readme for version-specific instructions; the process differs between WebLogic 12.x and 14.x
• Schedule a maintenance window; WebLogic typically requires a restart to apply security patches fully

If patching in the next 24–72 hours isn't realistic, move immediately to the network-level mitigations below. Do not wait on patching as your only action.

---

Fix Option 2: Block T3 and IIOP at the Network Level

This is your fastest risk reduction lever and should be done regardless of whether you can patch immediately.

Firewall rules:

Block inbound T3 and IIOP traffic to WebLogic hosts from any source that isn't explicitly required. In most environments:

• External access to ports 7001, 7002, 2809, 2810 should be blocked at the perimeter — full stop
• Internal access should be restricted to specific source IPs (app servers, CI/CD runners, admin jump hosts) — not open to the entire internal subnet
• If you're in AWS, Azure, or GCP, update your security groups/NSGs/firewall rules now; don't wait for a change management cycle on a CISA KEV with a three-day deadline

Use WebLogic's built-in connection filter:

WebLogic has a native connection filter that can restrict T3 access at the application layer as a defense-in-depth measure. This is documented in Oracle's own hardening guidance and is worth configuring even on patched systems.

In the Admin Console:

1. Navigate to Domain > Security > Filter
2. Set the Connection Filter to weblogic.security.net.ConnectionFilterImpl
3. Define Connection Filter Rules to whitelist only trusted source IPs for T3 and IIOP
4. Restart the affected managed servers for the rules to take effect

This won't replace patching, but it meaningfully reduces your attack surface while you work through the patching process.

Disable IIOP if you don't need it:

Most modern WebLogic deployments don't actually use IIOP. If your applications don't rely on CORBA/RMI-IIOP, disable the IIOP protocol entirely:

1. In the Admin Console, navigate to each server's Protocols configuration
2. Disable the IIOP channel
3. Restart the server

---

Fix Option 3: Discontinue Use

CISA's required action explicitly includes "discontinue use of the product if mitigations are unavailable." That's not boilerplate — it's a real option worth evaluating.

If you're running WebLogic for a legacy application that's in the process of being migrated, has no active business owner, or exists purely because nobody got around to decommissioning it: this vulnerability is a forcing function. An unpatched, internet-exposed WebLogic instance hosting a dead application is not a calculated risk — it's an open door.

---

For MSPs: Client Conversations to Have Right Now

If you manage infrastructure for clients running WebLogic:

• Identify all WebLogic instances across your client base. Check your CMDB, your RMM agent inventory, and your patch management tooling. WebLogic sometimes hides in Java EE middleware stacks for ERP systems, CRM platforms, or legacy custom apps.
• Treat this as an emergency change. The CISA KEV deadline was June 4. If you're past that date and clients are unpatched and exposed, document your risk communication and get sign-off from the client if they're choosing to delay.
• Network segmentation is a conversation, not just a technical task. Many SMBs have flat internal networks where every host can reach every other host. This vulnerability is a good hook for a broader segmentation discussion.
• Check cloud-lifted environments. Clients who migrated on-premises WebLogic to IaaS (AWS EC2, Azure VM, etc.) often have the most exposure because cloud security groups were configured to mirror on-premises network access rather than implement a least-privilege posture.

---

What "Unspecified Vulnerability" Actually Means

Oracle's CPU advisories frequently describe vulnerabilities as "unspecified" to limit the information available to attackers before patches are widely deployed. This is a vendor disclosure policy, not a statement about severity or exploitability.

In practice, WebLogic vulnerabilities affecting T3/IIOP have historically enabled remote code execution and full server compromise. The CVSS scoring and the CISA KEV addition both reflect that this is being treated as a high-severity, actively-exploited issue. Don't let the word "unspecified" read as ambiguous severity — treat it as critical until your environment is patched and your network controls are in place.

---

Summary: Your Action Checklist

• Identify all WebLogic instances in your environment (and client environments)
• Check version against the Oracle CPU July 2024 patch level
• Audit firewall rules — block external access to T3/IIOP ports immediately
• Restrict internal T3/IIOP access to explicitly required source IPs
• Configure WebLogic's built-in connection filter as a defense-in-depth layer
• Disable IIOP if it's not in use
• Apply the Oracle CPU July 2024 patch through a supported maintenance window
• Consider decommissioning unneeded WebLogic instances rather than maintaining patching obligations indefinitely

The three-day CISA deadline is aggressive by design. Network controls can be implemented in hours. Patching takes longer but is non-negotiable. Do both.