CVE-2021-2394

What it actually does

CVE-2021-2394 is an unauthenticated remote code execution vulnerability in Oracle WebLogic Server Core reachable over the T3 and IIOP protocols. An attacker with network access to a vulnerable WebLogic listening service can send crafted protocol traffic that causes the server to execute attacker-controlled logic in the WebLogic process context. Because WebLogic commonly runs with high application privileges and access to deployed applications, credentials, data sources, and administrative functions, successful exploitation can result in full WebLogic Server takeover with complete confidentiality, integrity, and availability impact.

Why it matters to the business

A successful attack can give an external or internal attacker control of an application server, allowing theft or modification of application data, deployment of web shells or malware, interruption of business applications, and pivoting deeper into connected systems. The CVSS score is critical at 9.8 and the EPSS probability is high at approximately 76.6%, indicating meaningful real-world exploit likelihood even though it is not currently listed in CISA KEV. Organizations running internet-facing or broadly reachable WebLogic T3/IIOP services should treat this as urgent because affected versions are widely deployed in enterprise middleware environments.

How an attack unfolds

An attacker first identifies an exposed Oracle WebLogic Server instance and determines whether T3 or IIOP is reachable, often on ports such as 7001, 7002, or other configured WebLogic listen ports. The attacker then sends specially crafted unauthenticated protocol traffic to the vulnerable Core component. If the target is running an affected and unpatched version, the malicious request triggers server-side execution in the WebLogic process. From there, the attacker may execute operating system commands, deploy a JSP web shell, create or modify WebLogic deployments, access configured data sources, dump credentials or configuration files, and establish persistence. Follow-on activity commonly includes process spawning from the Java/WebLogic service account, suspicious outbound connections, archive or script uploads into WebLogic application directories, and attempts to move laterally using credentials recovered from the compromised middleware host.

How to fix it

Apply the relevant Oracle Critical Patch Update for WebLogic Server that fixes CVE-2021-2394, or upgrade to a currently supported WebLogic Server release containing the July 2021 CPU or later security fixes. Because no exact fixed package versions were provided, validate remediation directly against Oracle’s advisory and the installed WebLogic version and patch inventory. If immediate patching is not possible, restrict T3 and IIOP access to only trusted administrative and cluster peers, block external access to WebLogic listen ports at network boundaries, disable unused protocols where operationally feasible, and place WebLogic behind tightly controlled reverse proxies or firewalls. Review WebLogic service account permissions and ensure the server does not run as root or a highly privileged operating system account. After patching, restart affected Managed Servers and Admin Servers as required and confirm the active runtime is using the patched binaries, not only that the patch is present on disk.

How to confirm the fix worked

Confirm the installed WebLogic Server version and Oracle patch inventory using Oracle OPatch, WebLogic version output, and the Oracle Central Inventory. Verify that all affected Admin Servers and Managed Servers have been patched or upgraded, including standby, disaster recovery, development, and batch-processing instances. From an untrusted network segment, confirm that T3 and IIOP listener access is blocked unless explicitly required. Review WebLogic startup logs after remediation to ensure the expected patched version is loaded. Run authenticated vulnerability scanning or configuration assessment against WebLogic endpoints to confirm CVE-2021-2394 is no longer reported. Validate that compensating controls are effective by testing that unauthenticated T3/IIOP handshakes are not accepted from unauthorized sources.

Typical attack path

1. Scan for Oracle WebLogic Server endpoints and open WebLogic protocol listeners, especially T3 or IIOP on WebLogic listen ports.
2. Confirm the target is likely running an affected WebLogic Server version: 10.3.6.0.0, 12.1.3.0.0, 12.2.1.3.0, 12.2.1.4.0, or 14.1.1.0.0.
3. Send crafted unauthenticated T3 or IIOP traffic to the vulnerable WebLogic Core component.
4. Achieve code execution in the WebLogic Java process context.
5. Run commands, deploy a malicious JSP/web shell, or add a malicious application deployment.
6. Collect credentials and configuration from WebLogic domains, data source definitions, keystores, or application files.
7. Use the compromised server for persistence, data theft, service disruption, cryptomining, ransomware staging, or lateral movement.

How to detect it

To determine whether exploitation has already occurred, review WebLogic Server logs, access logs, Admin Server audit logs, deployment logs, operating system process telemetry, EDR events, firewall logs, proxy logs, and network flow data for WebLogic listen ports. Look for unauthenticated T3 or IIOP connections from unusual sources, protocol handshakes followed by Java exceptions, serialized-object errors, abnormal spikes in WebLogic traffic, or connections from scanners and unknown internet hosts. On the host, hunt for child processes spawned by the WebLogic Java process, especially shell interpreters, command execution utilities, download tools, scripting engines, archive tools, or reverse-shell behavior. Inspect WebLogic domain directories, application deployment directories, temporary extraction paths, and web application roots for recently created JSP files, WAR files, class files, or modified deployment descriptors. Review Admin Server audit and deployment history for unexpected application deployments, changes to startup classes, changes to data sources, or new administrative users. If suspicious activity is found, preserve volatile evidence, collect relevant logs and file metadata, isolate the server, and rotate credentials that may have been accessible to WebLogic.

• T3
• t3://
• IIOP
• iiop://
• HELO:
• weblogic.rjvm
• weblogic.iiop
• weblogic.kernel.Default
• InboundMsgAbbrev
• java.io.InvalidClassException
• java.io.StreamCorruptedException
• java.lang.ProcessBuilder
• Runtime.getRuntime().exec
• cmd.exe /c
• powershell.exe
• /bin/sh -c
• /bin/bash -c
• curl http
• wget http
• .jsp
• /_WL_internal/
• /servers/AdminServer/tmp/
• /servers/AdminServer/upload/
• /servers/AdminServer/stage/
• /servers/AdminServer/logs/AdminServer.log
• /servers/AdminServer/logs/access.log
• config.xml
• SerializedSystemIni.dat

What your security team should do

• Prioritize patching or upgrading all affected Oracle WebLogic Server instances, especially internet-facing systems and servers reachable from user networks.
• Inventory WebLogic Admin Servers and Managed Servers, including non-production, clustered, and disaster recovery environments, to identify unsupported or unpatched versions.
• Restrict T3 and IIOP protocol exposure to only required trusted hosts; block these protocols from the internet and general corporate networks.
• Hunt for evidence of prior exploitation before or during remediation, focusing on Java-spawned command shells, suspicious JSP files, unexpected deployments, and unusual WebLogic protocol traffic.
• Review WebLogic deployments, domain configuration, data source credentials, startup scripts, and application directories for unauthorized changes.
• Rotate credentials stored or used by WebLogic if compromise is suspected, including data source passwords, application secrets, admin credentials, keystore passwords, and service account credentials.
• Enable centralized logging for WebLogic server logs, access logs, operating system process telemetry, EDR, network flow logs, and firewall logs covering WebLogic ports.
• Ensure WebLogic runs with least privilege and that application server file-system permissions prevent unnecessary write access to deployment and webroot directories.