Oracle WebLogic T3 and IIOP Hardening: Eliminating the Attack Surface Behind CVE-2024-21182

Oracle WebLogic Server’s T3 and IIOP protocols have produced a steady stream of critical vulnerabilities since CVE-2019-2725 brought them to widespread attention. Each new vulnerability triggers a response cycle: patch, update scanner signatures, close the immediate exposure. The underlying attack surface — T3/IIOP accessible from untrusted networks — remains.

The correct architecture eliminates that attack surface. The specific CVE then becomes irrelevant.

Understanding T3 and IIOP

T3 (Thin Third party) is Oracle’s proprietary protocol for Java RMI communication between WebLogic components and remote clients. It transmits serialized Java objects and is the primary vector for WebLogic deserialization attacks. T3 listens on the WebLogic listen port (default TCP 7001, TLS 7002).

IIOP (Internet Inter-ORB Protocol) is the CORBA standard protocol for distributed object communication, used for EJB remote access. It shares the same listen port as T3 in WebLogic and is subject to the same deserialization attack class.

Both protocols are designed for communication between trusted Java components within an enterprise infrastructure boundary — not for internet-accessible services. The architectural error is deploying WebLogic with these ports reachable from untrusted networks.

Restricting T3 Access

Connection Filters (recommended): WebLogic’s connection filter mechanism allows source IP restriction at the protocol level:

1. Log into the WebLogic Administration Console
2. Navigate to: Servers → <server name> → Protocols → General
3. Check “Enable WebLogic Plugin” is disabled unless required
4. Navigate to: Domain → Security → Filter
5. Configure a Connection Filter class: weblogic.security.net.ConnectionFilterImpl
6. Set Connection Filter Rules:

   # Allow only internal management network to T3/IIOP
   10.0.1.0/24 * 7001 allow t3 t3s iiop iiops
   10.0.1.0/24 * 7002 allow t3 t3s iiop iiops
   # Deny all T3/IIOP from other sources
   * * 7001 deny t3 t3s iiop iiops
   * * 7002 deny t3 t3s iiop iiops

Replace 10.0.1.0/24 with the actual IP range of your management network or application servers that legitimately use T3.

Perimeter network controls: In addition to WebLogic-level connection filters, firewall rules should restrict TCP 7001/7002 to authorised source networks. Perimeter controls provide defence-in-depth even if WebLogic connection filter configuration is inadvertently changed:

# Example iptables rule (adapt to your firewall platform)
iptables -A INPUT -p tcp --dport 7001 -s 10.0.1.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 7001 -j DROP

Disabling IIOP if Not Required

If your WebLogic deployment does not use EJB remote access via IIOP (many modern deployments use REST/HTTP for inter-service communication), disable IIOP entirely:

1. Navigate to: Domain → <domain name> → Configuration → General
2. Under “Advanced”, uncheck “Enable IIOP”
3. Restart the WebLogic server

Reducing the enabled protocol surface eliminates entire vulnerability classes — disabling IIOP means IIOP deserialization vulnerabilities are simply not applicable to the deployment.

WebLogic Deserialization Defence-in-Depth

Even with network controls in place, additional defences reduce the impact of a future T3 vulnerability:

JVM Global Deserialization Filters (Java 17+): Configure a JVM deserialization filter to restrict which classes can be deserialized from T3 streams:

-Djdk.serialFilter=oracle.*;java.*;sun.*;com.oracle.*;!*

This allows Oracle’s own classes while rejecting third-party gadget chain classes. It is not a complete defence (Oracle-internal gadget chains may exist) but significantly raises the exploitation bar.

WebLogic Diagnostic Framework (WLDF) rule for anomalous T3 traffic: Configure WLDF to log T3 messages that include class names outside the expected Oracle package hierarchy. Anomalous class names in T3 messages are a reliable exploitation indicator.

Disable T3 in untrusted environments: For WebLogic nodes that only serve HTTP/HTTPS traffic and do not participate in WebLogic clustering or EJB remoting, T3 can be disabled entirely:

• In config.xml: set <t3-channel-disabled>true</t3-channel-disabled> for the relevant server
• Or configure the listen port to reject T3 protocol using connection filters

The Long-Term Architecture Decision

Every Oracle WebLogic T3/IIOP vulnerability since 2019 has the same remediation recommendation: restrict T3/IIOP to trusted networks. This has not changed in six years of critical vulnerabilities. Organisations that have not implemented this restriction are choosing to remain exposed to the entire T3/IIOP vulnerability class indefinitely.

The restriction can be implemented in hours and requires no WebLogic license changes, no application code changes, and no recompilation. It is an infrastructure change — firewall rules and WebLogic connection filter configuration — that permanently reduces the attack surface for the entire T3/IIOP vulnerability class.