CISA added CVE-2026-21962 to its Known Exploited Vulnerabilities catalog on August 24 after confirming that attackers are exploiting the flaw. The vulnerability sits in Oracle HTTP Server and the Oracle WebLogic Server Proxy Plug-in, where an unauthenticated HTTP request can cross an access-control boundary and reach or alter critical data.
The agency gave US federal civilian departments an August 27 remediation deadline. Oracle shipped the fix seven months earlier in its January 2026 Critical Patch Update. Organizations that put WebLogic applications behind the affected Apache or IIS plug-in now need an immediate exposure review.
CISA’s catalog entry says exploitation can provide unauthorized access to critical data or allow its creation, deletion, or modification. CISA does not name the attackers, victims, method, or scale. It lists ransomware use as unknown.
Oracle’s January advisory assigns the flaw a CVSS 10.0 score. Oracle marks the attack vector as network, the protocol as HTTP, attack complexity as low, and both required privileges and user interaction as none. Its risk matrix records high confidentiality and integrity impact without an availability impact. Oracle says, “Oracle therefore strongly recommends that customers remain on actively-supported versions and apply Critical Patch Update security patches without delay.”
A proxy flaw crosses trust
The proxy is the trust boundary.
Oracle names the affected components as the WebLogic Server Proxy Plug-in for Apache HTTP Server and for IIS. The improper access-control issue sits in that layer between accepted HTTP requests and protected WebLogic application data.
Figure details
The diagram begins with an unauthenticated HTTP request. It reaches an Oracle WebLogic Server Proxy Plug-in running with Apache HTTP Server or IIS, then crosses the affected access-control boundary protecting application data. The path branches to the two outcome classes in CISA's entry: unauthorized reading, or unauthorized creation, modification, and deletion.
Oracle has not published the request structure or internal parser path. A suspicious URI or response code alone cannot verify exploitation. Combine patch state with front-end, proxy, and WebLogic logs plus records of data operations the requesting identity should not have performed.
The published outcome is unauthorized access to or modification of data. Neither source reports remote code execution, service disruption, ransomware deployment, or a post-exploitation tool.
Patch the affected plug-ins
Oracle lists supported releases 12.2.1.4.0, 14.1.1.0.0, and 14.1.2.0.0 as affected for CVE-2026-21962. Its note narrows the IIS plug-in exposure to 12.2.1.4.0. Apache HTTP Server deployments require checking all three listed release lines when the Oracle WebLogic proxy plug-in is present.
Oracle delivered the repair in its January 2026 Critical Patch Update rather than a new base product version. Obtain the matching patch from My Oracle Support. A later cumulative CPU for the same supported release supersedes the January bundle.
Network blocking can reduce exposure while a patch is staged, but it does not correct the flaw. Restrict direct internet access, preserve logs, and apply Oracle’s fix. CISA also directs agencies to discontinue use when mitigations are unavailable.
Patch the plug-in, then prove it.
A WebLogic Server version alone does not show whether the affected plug-in is loaded, exposed, or patched. Record the web server, plug-in release, patch inventory, listening address, routed applications, and log retention.
Verify patch and exposure
Test every serving node.
Identify every Apache and IIS instance that loads the plug-in. Compare its release with 12.2.1.4.0, 14.1.1.0.0, and 14.1.2.0.0; IIS is affected only at 12.2.1.4.0. Confirm the January fix or a later superseding CPU in installed patch inventory.
Review retained HTTP and proxy logs, prioritizing the period before patch installation. Correlate unusual unauthenticated requests, restricted routes, unexpected successful responses, and data changes with WebLogic and business audit records. The sources publish no attacker addresses or request signature, so a clean indicator search does not establish that an exposed server was untouched.
Run the verification test through each patched proxy path. Send an authorized request to a permitted route and an unauthenticated request to a protected route. Expect normal authorized service, rejection and logging of the unauthorized request, and patch inventory showing the January fix or a later superseding CPU on the serving node.
The strongest record binds three facts to one host: the plug-in was in scope, the installed patch supersedes Oracle’s January fix, and the protected route rejects unauthorized traffic. A version record or change ticket remains an expected-state claim until that test passes.