CVE-2020-14644

What is Oracle WebLogic's T3/IIOP Protocol?

Oracle WebLogic Server is a Java EE application server widely deployed in enterprises, financial institutions, and government systems for running Java-based applications. WebLogic supports multiple network protocols for remote Java component communication, including T3 (Oracle's proprietary protocol for WebLogic cluster communication) and IIOP (Internet Inter-ORB Protocol for CORBA/RMI communication). These protocols are used for inter-server communication, EJB (Enterprise JavaBean) invocation, and cluster coordination. They listen on the same HTTP/HTTPS ports (7001/7002) or can be configured on separate ports. Java deserialization vulnerabilities in WebLogic's T3/IIOP handling allow attackers to send specially crafted serialized Java objects that, when deserialized by WebLogic, execute arbitrary Java code — a class of vulnerability that has produced numerous critical WebLogic CVEs over multiple years.

Overview

CVE-2020-14644 is a remote code execution vulnerability in Oracle WebLogic Server affecting the core networking component via T3 and IIOP protocols. An unauthenticated attacker with network access to WebLogic on these protocols can exploit Java deserialization to achieve code execution on the WebLogic server. Oracle patched it in the July 2020 CPU. Notably, CISA added CVE-2020-14644 to the KEV catalog in September 2024 — more than four years after the patch was released — reflecting that threat actors continued targeting unpatched WebLogic deployments. The required action includes the option to discontinue use if mitigations are unavailable, indicating concern about long-term unpatched exposure.

Affected Versions

Technical Details

• Root cause: Java deserialization vulnerability in WebLogic's T3/IIOP protocol handling — WebLogic accepts serialized Java objects over T3 and IIOP for legitimate cluster communication and EJB invocation; the deserialization code path does not sufficiently validate or filter the incoming serialized data; an attacker sends a crafted serialized payload containing a malicious gadget chain that, when deserialized, executes arbitrary Java code in the WebLogic server process
• Gadget chain execution: Java deserialization attacks work by exploiting "gadget chains" — sequences of existing Java classes in the server's classpath whose methods, when invoked during deserialization, can be chained to execute arbitrary commands; WebLogic servers include many Java libraries in the classpath that provide exploitable gadget chains; attackers use tools like ysoserial to generate payloads for known WebLogic gadget chains
• T3/IIOP pre-authentication: Both T3 and IIOP are accessible before any authentication in default WebLogic configurations; the serialized object is processed during protocol handshake before credential validation, making this a fully unauthenticated attack
• WebLogic deserialization history: Oracle WebLogic has a multi-year history of deserialization vulnerabilities (CVE-2015-4852, CVE-2016-3510, CVE-2018-2628, CVE-2019-2725, CVE-2020-2555, CVE-2020-14644, etc.); the same fundamental attack class repeatedly produces new CVEs as different gadget chains or deserialization code paths are discovered
• 4-year KEV delay: CISA's September 2024 KEV addition (4+ years after the July 2020 patch) reflects that unpatched WebLogic servers remained in production and were actively exploited years after the vulnerability was public — a pattern common with complex enterprise middleware requiring careful upgrade testing

Discovery

Identified by Oracle security researchers as part of the July 2020 CPU vulnerability assessment cycle. The pattern of deserialization vulnerabilities in WebLogic was well-understood by the security community, and Oracle has patched numerous variants over multiple CPU cycles.

Exploitation Context

Oracle WebLogic is used in mission-critical enterprise Java deployments — financial trading systems, insurance claims processing, government portals, and ERP systems. These environments often have long patch validation and testing cycles (months to years) due to compatibility requirements, creating extended windows of vulnerability exposure. WebLogic deserialization vulnerabilities are particularly prized by attackers because they require no authentication and execute code with WebLogic server privileges. The 4-year gap between patch and KEV addition demonstrates the challenge of patching deeply embedded enterprise middleware, and threat actors actively maintain exploits for older WebLogic vulnerabilities knowing that some organizations will remain unpatched indefinitely.

Remediation

1. Apply Oracle July 2020 CPU patches for all affected WebLogic versions — primary fix for CVE-2020-14644
2. As a mitigation if patching is not immediately possible: disable T3 and IIOP protocols if not required for inter-server communication — WebLogic allows disabling T3 via the WebLogic Server Administration Console under Domain → Configuration → Security → Filter; disable IIOP if not used for EJB/CORBA communication
3. Block T3 (port 7001/7002 or custom port) and IIOP access from untrusted networks via firewall — T3 and IIOP should never be internet-accessible; restrict to internal application servers only
4. If discontinuing WebLogic is feasible, migrate Java EE applications to actively-maintained alternatives; Oracle's required action explicitly includes this option for this CVE
5. Investigate for prior exploitation: check WebLogic logs for unexpected outbound network connections, unusual process spawning from the WebLogic Java process, or file system changes in the WebLogic domain directory
6. Apply Oracle CPU patches on a quarterly schedule — WebLogic receives security updates in every Oracle CPU cycle; delayed patching creates compounding exposure from multiple CVEs