high

CVE

CVE-2024-21182

CWE

Not mapped

Affected Surface

Oracle WebLogic Server 12.2.1.4.0, Oracle WebLogic Server 14.1.1.0.0, Oracle Fusion Middleware deployments exposing T3 or IIOP, Java applications hosted on affected WebLogic domains

CISA added CVE-2024-21182 to the Known Exploited Vulnerabilities catalog on 1 June 2026, turning an Oracle July 2024 Critical Patch Update item into an active-response issue for WebLogic operators.

Oracle’s description is intentionally sparse: the flaw is in Oracle WebLogic Server Core, affects supported WebLogic Server versions 12.2.1.4.0 and 14.1.1.0.0, is remotely reachable without authentication over T3 and IIOP, and can result in unauthorized access to critical data or complete access to all WebLogic Server-accessible data. Oracle assigned CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, which means the public impact is confidentiality-only but the access is network, low complexity, and unauthenticated.

Affected projects

The affected application-server projects are:

ProductAffected versionsExposed protocols
Oracle WebLogic Server12.2.1.4.0T3, IIOP
Oracle WebLogic Server14.1.1.0.0T3, IIOP

The practical exposure is broader than the WebLogic binary version. Any Java application deployed into an affected WebLogic domain inherits the server-side protocol surface, especially if public or semi-public load balancers, firewalls, Kubernetes services, or VPN routes expose the WebLogic listen ports.

Why T3 and IIOP matter

WebLogic does not expose only HTTP applications. Administrative, clustering, RMI, EJB, JMS, and remote-client paths can ride on WebLogic’s native protocols. The common mistake is to protect /console and application URLs while leaving the same listen address reachable for t3://, t3s://, iiop://, or iiops:// clients.

Typical Java clients make those protocol choices explicit:

import java.util.Hashtable;
import javax.naming.Context;
import javax.naming.InitialContext;

Hashtable<String, String> env = new Hashtable<>();
env.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");
env.put(Context.PROVIDER_URL, "t3://weblogic.example.com:7001");

Context ctx = new InitialContext(env);
Object remote = ctx.lookup("jms/ConnectionFactory");

That code is ordinary in old enterprise estates. From a defender’s point of view, every allowed t3:// or iiop:// route to an affected server is a vulnerability-relevant route, not just an application connectivity detail.

Exploitation preconditions

Based on the Oracle/NVD/CISA data, the important preconditions are:

WebLogic Server version is 12.2.1.4.0 or 14.1.1.0.0
The July 2024 CPU or later applicable WebLogic fix is missing
An attacker has network reachability to T3 or IIOP on the WebLogic listen address
No authentication or user interaction is required

No public root-cause patch diff is available from Oracle, so teams should avoid building detections around a guessed method name or class. Focus on version, patch inventory, network reachability, and protocol-level telemetry.

Inventory and exposure checks

On hosts, verify WebLogic version and patch inventory from the Oracle home used by the running domain:

$ORACLE_HOME/OPatch/opatch lsinventory

Find WebLogic listen addresses and protocol-related settings in domain configuration:

rg -n \
  "<listen-port>|<listen-address>|t3|t3s|iiop|iiops|IIOP|T3" \
  "$DOMAIN_HOME/config/config.xml" "$DOMAIN_HOME/config"

From network inventory, flag Internet, partner, and broad internal routes to WebLogic defaults and custom listen ports. WebLogic commonly listens on 7001 for plain traffic and 7002 for SSL in simple domains, but production domains often use custom ports, load balancers, and admin/managed-server separation.

# Example discovery from a scanner host allowed to assess the segment.
nmap -sT -p 7001,7002,8001,8002,9001,9002 --open <weblogic-subnet>

If you use Kubernetes, do not stop at pod images. Check whether a Service, Ingress, Gateway, or cloud load balancer exposes WebLogic ports:

kubectl get svc,ingress,gateway -A -o wide | rg "7001|7002|8001|8002|weblogic"

Detection

Because the public advisory does not describe a payload shape, detection should be conservative:

  1. Review WebLogic access logs and network telemetry for new external clients reaching WebLogic listen ports, especially non-HTTP traffic.
  2. Search for failed or unusual JNDI/RMI/EJB/JMS client activity around the CISA KEV date and before patching.
  3. Compare recent WebLogic domain configuration changes against approved deployment activity.
  4. Review application logs for unexpected data reads, administrative lookups, or service calls from unusual source IPs.

Example log triage:

rg -n \
  "T3|IIOP|RJVM|JNDI|InitialContext|weblogic\\.rmi|javax\\.management|BEA-" \
  "$DOMAIN_HOME/servers" /var/log

That search is intentionally broad. It should drive scoping, not serve as proof of exploitation.

Remediation

Patch first. Oracle fixed the issue in the July 2024 Critical Patch Update, and CISA now requires covered federal agencies to remediate the KEV entry by 4 June 2026. For non-federal teams, the KEV addition is still a strong signal that this should move out of routine quarterly patching.

If immediate patching is not possible, reduce exposure while preparing a fixed deployment:

Block public and untrusted network access to WebLogic T3 and IIOP.
Permit remote T3/IIOP only from explicitly required application hosts.
Separate admin-server access from managed-server application traffic.
Disable unused IIOP or remote-client features where the application does not require them.
Require VPN, bastion, or private network paths for administrative and remote-client protocols.

Oracle’s own CPU guidance is clear that protocol blocking can reduce risk but is not a substitute for applying the patch. Treat mitigation-only states as temporary and track them to closure.

References