SURIQ
The gap between a public exploit and CISA calling a flaw exploited is usually measured in days. For CVE-2026-21962 it ran seven months. On August 24, 2026, CISA placed this maximum-severity bug in Oracle's HTTP Server and WebLogic proxy plug-in on its Known Exploited Vulnerabilities catalog and gave federal agencies only until August 27 to patch, a three-day window that is far tighter than the usual three weeks. The fix has been available since Oracle's January 2026 Critical Patch Update. A working proof-of-concept has been public since the day after that patch shipped.
That timeline is the story. If your triage rule is "patch what CISA flags," this one sat below the line for two full quarters while an exploit circulated in the open. Here is what the flaw does, why the proxy plug-in is easy to miss, and how to check whether the long exposure window was used against you.
What the flaw actually is
CVE-2026-21962 is an improper access control bug (CWE-284) that Oracle rates a full 10.0 on CVSS. The vector describes an unauthenticated attacker reaching the component over the network, with no user interaction, and it carries a scope change: the impact can spread past the proxy into the components behind it. Oracle's own scoring covers an attacker being able to read, alter, or delete the data the proxy can reach. Some security researchers have assessed the flaw as a possible route toward code execution on the backend, but Oracle's own scoring stops at confidentiality and integrity, so treat full remote code execution as reported-possible rather than confirmed.
The affected releases are 12.2.1.4.0, 14.1.1.0.0, and 14.1.2.0.0. Public reporting, including the Canadian Centre for Cyber Security advisory, dates the proof-of-concept to January 21, 2026, one day after Oracle shipped the January Critical Patch Update.
The part teams miss: the proxy is not WebLogic
The name buries the exposure. The WebLogic Server Proxy Plug-in does not run on your WebLogic application servers. It is a module you install on an Apache HTTP Server or Microsoft IIS web server that sits in front of WebLogic and forwards requests to it. On many deployments that front-end web tier is owned by a different team than the Java application servers, patched on a different schedule, and tracked as "the web server," not "WebLogic."
That split is why an organization can read this advisory, confirm its WebLogic domain is current, and still be exposed. The plug-in ships and versions separately. Applying the January update to WebLogic does nothing for a plug-in binary sitting on an Apache or IIS host that nobody re-checked. Inventory this flaw by the web tier, not the app tier.
Why "not in KEV" was never "not urgent"
The seven-month gap carries a lesson beyond this one CVE. Exploitation did not begin on August 24; the KEV listing did. Researchers reported a spike in malformed requests against WebLogic paths as early as January 28, 2026, days after the exploit went public. CISA adds an entry once it can confirm exploitation, which is a lagging signal by design. Treating the KEV catalog as your urgency trigger means you move only after attackers have had a running start, and here that start was measured in quarters, not days.
How to know if the window was used
Patching stops the next attempt. It says nothing about the months the exploit was public and your plug-in was not. That distinction is the whole job on a bug like this. Because the flaw is an access-control bypass rather than a crash, a successful hit can look like an ordinary request in your logs, which is exactly why you have to go looking.
Pull the access logs from every Apache HTTP Server and IIS host running the plug-in and hunt backward to late January. Public reporting on the probing described traversal-style path sequences, including ..; segments, and manipulated request headers aimed at WebLogic backends. Those are your starting signatures. Pair them with any unexplained change to the data the proxy fronts, since data manipulation is the impact Oracle actually scored. None of these alone proves compromise. Together, on a host that ran an unpatched plug-in through the spring, they justify opening an incident.
What to do now, before the patch deadline passes
Three steps, in order. First, apply Oracle's January 2026 Critical Patch Update to the proxy plug-in on every Apache HTTP Server and IIS host that fronts WebLogic, and confirm the binary version actually changed rather than assuming the WebLogic update covered it. Second, if you cannot patch at once, restrict network access to those front-end web servers and put a web application firewall in front of them, watching for the traversal and header patterns above. Third, treat the exposure window as real: rotate any secrets the proxied applications handle and review backend data for tampering, because a patch cannot undo access that already happened.
This is the third Oracle emergency we have covered this cycle, after July's unauthenticated code-execution flaws in WebLogic and Coherence, a public exploit that forged WebLogic logins, and the continuing attacks on E-Business Suite. The pattern across all of them is the same: the fix was available well before the exploitation peaked, and the shops that got hurt were the ones tracking the wrong deadline.