On June 1, CISA added CVE-2024-21182 — an unauthenticated flaw in the core of Oracle WebLogic Server — to its Known Exploited Vulnerabilities catalog. CISA only adds CVEs to the KEV list when it has evidence of real-world exploitation, and this one has carried a public proof-of-concept since late 2024. Oracle patched it in the July 2024 Critical Patch Update, which means the exposure here is not a missing fix. It is the long tail of internet-facing WebLogic instances that nobody has touched in two years.

If you run WebLogic anywhere a hostile network can reach it, this is your morning’s work.

The bug

CVE-2024-21182 lives in the Core component of Oracle WebLogic Server, part of Oracle Fusion Middleware. An unauthenticated attacker with network access over the T3 or IIOP protocols can compromise the server. Oracle scores it CVSS 7.5 with the vector AV:N/AC:L/PR:N/UI:N/C:H/I:N/A:N — network attack vector, low complexity, no privileges, no user interaction, high confidentiality impact. Affected releases are 12.2.1.4.0 and 14.1.1.0.0.

T3 is WebLogic’s proprietary binary RMI protocol, and it has been the soft underbelly of the product for the better part of a decade. The T3 listener rides on the same port as the admin/managed server — 7001 by default, 7002 for TLS — and it accepts serialized Java objects. That object stream is the recurring problem: WebLogic’s history of T3/IIOP deserialization flaws (CVE-2015-4852, CVE-2020-2551, CVE-2020-14882, and a long line after) all trace back to the server deserializing attacker-controlled data before any authentication completes. CVE-2024-21182 is the latest entry in that lineage, and because the listener answers before a credential exchange, the vulnerable code path is reachable pre-auth.

Why it is being exploited now

Nothing about the bug changed. The exposure did. WebLogic backs core business systems — ERP, banking middleware, government portals — that are slow to patch and frequently left listening on 7001 far longer than anyone intends. A public PoC plus a two-year patch gap is exactly the profile attackers automate against.

Security researchers reported an uptick in exploitation attempts through mid-to-late May 2026, with honeypots logging scans and payloads against ports 7001 and 7002. Reported post-exploitation activity tracks the usual WebLogic playbook: cryptocurrency miners dropped onto the host, Cobalt Strike beacons for persistence, and in some cases ransomware staging. Treat those reports as directional rather than gospel, but the KEV listing itself is confirmation enough that this is live.

Am I affected?

You are in scope if you run WebLogic 12.2.1.4.0 or 14.1.1.0.0 and have not applied the July 2024 CPU or any quarterly CPU since. The fastest triage:

  • Inventory every WebLogic instance and check the patch level against the July 2024 CPU baseline.
  • Identify which instances expose a T3/IIOP listener (default 7001/7002) to untrusted networks. Anything reachable from the internet is a priority-one finding.
  • Hunt for compromise already in progress: unexpected child processes spawned by the WebLogic JVM, new cron/scheduled tasks, unfamiliar JSP files in deployment directories, outbound connections to mining pools or C2.

Mitigation

  1. Patch. Apply the July 2024 Critical Patch Update or, better, the most recent quarterly CPU. This is the only real fix.
  2. If you cannot patch today, throttle T3. Use a WebLogic connection filter (weblogic.security.net.ConnectionFilterImpl) to allowlist only the hosts that legitimately need T3/IIOP, and deny the rest. Disable T3/IIOP entirely on servers that do not require it.
  3. Get the listener off the internet. Block 7001/7002 at the perimeter. A WebLogic T3 port should never face the public network — put it behind a VPN or management segment.
  4. Monitor. Watch for deserialization-style payloads against the T3 endpoint and for the post-exploitation indicators above.

Federal civilian agencies fall under BOD 22-01 and have the standard three-week KEV remediation window. Everyone else should move faster — the patch has been sitting on Oracle’s download server since July 2024, and the attackers already have the exploit.

References