CISA added CVE-2024-21182, an Oracle WebLogic Server flaw, to the Known Exploited Vulnerabilities catalog on June 1, 2026, with a remediation deadline of June 4, 2026. The three day window is one of the tightest CISA has issued this year and signals that federal incident responders are seeing active, in the wild exploitation against unpatched WebLogic instances reachable through the T3 and IIOP listeners. The bug carries a CVSS 3.1 base score of 7.5 and allows an unauthenticated network attacker to read every piece of data the server can touch, with no privileges and no user interaction required.
What CVE-2024-21182 actually does
The vulnerability lives in the Core component of Oracle WebLogic Server versions 12.2.1.4.0 and 14.1.1.0.0. Oracle described it in the July 2024 Critical Patch Update as easily exploitable by an unauthenticated attacker with network access via T3 or IIOP, resulting in unauthorized access to critical data or complete access to all WebLogic accessible data. The CVSS vector, AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, makes the impact profile clear: confidentiality is fully compromised while integrity and availability are not directly touched.
In practical terms, a remote attacker who can reach the T3 or IIOP port can pull credentials, session data, configuration files, JDBC connection strings, JMS payloads, and anything else the JVM has loaded or can serialize back over the wire. WebLogic deployments commonly hold integration secrets for downstream Oracle Database, SOA Suite, Identity Manager, and Forms instances, so a confidentiality only score badly understates the blast radius once those secrets move laterally.
Why CISA escalated almost two years after the July 2024 CPU
Oracle shipped the patch in CPU July 2024, almost twenty three months before this KEV listing. CISA only adds entries to the catalog when it has evidence of active exploitation, and the unusually short three day deadline suggests that evidence is recent and credible. WebLogic has a long history of being targeted by ransomware affiliates and cryptomining crews, including the Kinsing and 8220 Gang clusters that historically lean on T3 deserialization chains. Any new mass exploitation campaign against an unauthenticated T3 path would warrant exactly this kind of accelerated timeline.
The pattern mirrors other recent emergency listings. CISA gave agencies a similarly compressed window for the Palo Alto GlobalProtect authentication bypass earlier this cycle, and the operational lessons from that event remain relevant for any team scrambling against this WebLogic deadline. For background on how that drill played out, see our coverage of the Palo Alto GlobalProtect auth bypass and its CISA deadline.
The T3 and IIOP exposure problem
T3 is Oracle's proprietary RMI transport and the default protocol for WebLogic management traffic, cluster replication, and JNDI lookups. IIOP is the CORBA equivalent used for interop with legacy EJB clients. Both listeners are enabled by default on the admin server and any managed server, and both have a long track record as the entry point for serialization based attacks against WebLogic, going back to CVE-2015-4852 and continuing through the CVE-2020-2883, CVE-2020-14882, and CVE-2023-21839 families.
The historical mitigation guidance has been to filter T3 and IIOP at the network edge using the WebLogic connection filter, typically weblogic.security.net.ConnectionFilterImpl, and to disable IIOP outright where it is not required. Many environments never implemented those controls because internal management traffic was assumed to be safe, and decades of WebLogic deployments sit behind load balancers that quietly forward 7001 and 7002 to the outside world.
Operator take: inventory and listener triage in the next 72 hours
From an operator perspective, we are treating this as a two track exercise. Track one is the patch inventory itself. We need a defensible answer to a single question for every WebLogic 12.2.1.4 and 14.1.1 instance we run: is the July 2024 CPU or any later quarterly patch installed? We pull that from the Oracle inventory using opatch lsinventory on each domain home, then cross reference against the patch numbers Oracle published in the July 2024 advisory. Anything older than CPU July 2024 is presumed vulnerable. We are not trusting wrapper scripts, container base images, or change management tickets, because we have seen all three lie about the actual binary state of a WebLogic install.
Track two is the T3 and IIOP listener exposure map. For every domain, we are enumerating every managed server, every NetworkAccessPoint, and every channel definition that exposes a t3, t3s, iiop, or iiops protocol. We are pulling current connection filter rules from config.xml and validating them against an allowlist of expected source CIDRs. Where the connection filter is empty, default, or set to the permissive sample, we are deploying a deny by default ConnectionFilterImpl rule before the deadline, even on hosts that are already patched. Defense in depth on this listener has paid for itself across every WebLogic incident we have worked, and the cost of a tight allowlist is effectively zero.
We are also pulling 30 days of access logs from any reverse proxy or load balancer fronting WebLogic, looking for T3 handshake patterns on HTTP listeners, IIOP GIOP magic bytes, and unusual JNDI lookup strings in application logs. If any of those hits predate the patch, the box gets treated as compromised and rotated, not just patched in place.
What June 4 actually means and what happens if it slips
The June 4, 2026 deadline is binding under Binding Operational Directive 22-01 for Federal Civilian Executive Branch agencies. Those agencies must apply Oracle's CPU July 2024 patch or a later quarterly update, follow applicable BOD 22-01 cloud guidance, or discontinue use of the affected WebLogic instances. Missing the deadline does not trigger an automatic shutdown, but it does force the agency to report the exception to CISA, document a compensating control, and accept ongoing scrutiny from the agency's CIO and inspector general.
For private sector operators, the KEV listing is not legally binding, but cyber insurance underwriters, SOC 2 auditors, and most large enterprise customers now treat KEV entries as a de facto patch SLA. A WebLogic instance still vulnerable a week after the deadline is the kind of finding that ends up in a renewal questionnaire or a breach notification timeline. The defensible posture is to either patch to a current CPU, restrict T3 and IIOP to a tight management network, or take the listener offline entirely.
The broader lesson is the same one the recent cPanel incident reinforced: long lived management protocols on internet adjacent infrastructure remain a soft target, and the gap between vendor patch and active exploitation keeps shrinking. Our writeup of the cPanel authentication bypass that compromised more than 40,000 servers walks through what happens when an exposed admin surface meets a public proof of concept, and the WebLogic situation has every ingredient to follow the same arc if T3 and IIOP listeners stay open past June 4.
