CISA Adds CVE-2026-21962 to KEV: Oracle Web Proxy Flaw Scores 10.0

Known exploited vulnerability

CVE-2026-21962 has moved from a patch-list item to an active-priority issue. CISA added the improper-access-control flaw affecting specific Oracle HTTP Server and WebLogic Server Proxy Plug-in releases to its Known Exploited Vulnerabilities catalog on August 24, 2026.^[1]

Reporting cutoff: 2026-08-26T22:51:36Z

Who should act

This advisory is for organizations running the named enterprise middleware components—not every Oracle product, every WebLogic installation or every web server.

An environment belongs in the urgent review group only when all three conditions align:

1. The affected component is present: the WebLogic Server Proxy Plug-in for Apache HTTP Server or Microsoft IIS.
2. The release matches Oracle’s affected list: 12.2.1.4.0, 14.1.1.0.0 or 14.1.2.0.0. Oracle says the IIS plug-in is affected only at 12.2.1.4.0.^[3]
3. Requests can reach that proxy layer: directly or through a load balancer, reverse proxy, CDN, gateway or another upstream service.

Finding a matching package on disk establishes potential exposure, not successful compromise. Conversely, checking only an internet-facing load balancer can miss an affected back-end path. Inventory every node, image, region and standby deployment that can serve traffic.

Why the vulnerability matters

Oracle describes the issue as remotely exploitable without authentication or user interaction. Its CVSS v3.1 vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N.^[3]

Successful exploitation can allow unauthorized access to critical—or all accessible—data and unauthorized creation, deletion or modification of critical—or all accessible—data through the affected components.^[1][3]

That description supports a high-priority data-confidentiality and data-integrity response. It does not, by itself, establish a particular exploit sequence, malware family, persistence method or post-compromise action. This article intentionally does not speculate about mechanics Oracle and CISA have not publicly documented.

Affected versions at a glance

Oracle’s public risk matrix identifies affected releases, but the retrieved public pages do not provide a complete branch-by-branch patch-ID matrix. Do not infer safety from an unlisted release string or from an upstream version alone. Confirm the applicable January 2026 Critical Patch Update package and platform support in Oracle’s current support documentation before deployment.^[2][3]

Non-destructive inventory: build the answer before changing anything

• Use the product’s supported inventory and patch-reporting tools. Preserve their output before remediation.
• Compare configured files with the effective running configuration. A dormant file is not the same as a loaded module; a patched file is not the same as a restarted worker.
• Record immutable container image digests and deployment revision IDs rather than relying on mutable tags.
• Ask the application owner which data and back-end services are reachable through each proxy route. That bounds business impact without probing the vulnerability.
• Do not run public exploit code or send destructive test requests to production or third-party systems.

Patch with evidence, not assumptions

Oracle recommends applying Critical Patch Update security patches as soon as possible.^[2] The safest objective is the applicable, supported Oracle-provided correction for each exact platform and release—not a guessed file replacement or an unsupported downgrade.

1. Preflight: capture configuration, patch inventory, package provenance, image digests, active process IDs, service dependencies, certificates and a tested recovery plan.
2. Select: obtain the matching Oracle CPU patch through the organization’s approved Oracle support channel. Recheck the live advisory, prerequisites and supersedence immediately before change.
3. Test: apply it first to a representative non-production or canary node. Exercise authentication, routing, uploads, writes, failover and back-end health—not only a landing-page check.
4. Roll out: replace or restart every affected worker, container, pod and node according to the supported procedure. Drain traffic gracefully and include secondary regions and standby capacity.
5. Forward-fix: do not use the vulnerable build as a normal rollback target. If service trouble appears, prefer a tested configuration rollback that retains the corrected binaries while the compatibility issue is resolved.

Oracle says blocking network protocols required by an attack may reduce risk before patching, but can break application functionality, must be tested outside production and does not correct the underlying vulnerability.^[2] Use only vendor-approved compensating controls and treat them as temporary. Network restriction is defense in depth, not proof that the flaw is fixed.

If compromise is suspected: preserve first

KEV status raises urgency, but ordinary web errors, changed records or unusual requests are not unique indicators of this CVE. Correlate evidence before attributing an incident.

• Preserve reverse-proxy, Oracle HTTP Server, Apache or IIS, WebLogic, load-balancer, WAF, authentication, database and operating-system logs with timestamps and time-zone information.
• Capture the effective configuration, package and patch inventory, loaded modules, process trees, worker start times, listening sockets, file metadata and container or VM identities.
• Retain suspicious request records, response codes, account and data-change audit trails, alert context and relevant edge telemetry. Restrict access and maintain chain-of-custody notes.
• Before deleting files, rebuilding nodes or rotating logs, involve the incident-response lead. Isolate affected systems using the organization’s approved process if evidence warrants it. CISA’s current required action also points stakeholders to its Forensics Triage Requirements.^[1]
• Review unauthorized data access and changes, identities, tokens, keys, persistence and trust paths. Patching closes the known entry point; it does not evict an actor who already gained access.

There are no vendor-published unique indicators of compromise in the official source set used here. Absence of a unique IOC is not proof of safety, and a generic anomaly is not proof of exploitation.

Verify the correction in the live service

A successful installer message or version string is only the start. Verification should show both the corrected artifact and the intended behavior:

• The approved Oracle patch appears in the supported inventory on every node, image and platform in scope.
• Every active worker started after remediation and loads the corrected module or library. No stale process maps an old or deleted file.
• Production traffic reaches only corrected nodes; old autoscaling images, pods, disaster-recovery copies and load-balancer targets are removed or updated.
• The effective configuration matches the reviewed design, including Apache/IIS plug-in loading, proxy routes, IPv4/IPv6 paths and any temporary restriction.
• Representative local and end-to-end tests confirm routing, authentication, reads, writes, uploads, health checks, failover and expected error handling.
• Logs, latency, error rates and availability remain stable through the observation window. Security monitoring continues for suspicious access or data changes that predate patching.

About the August 27 deadline

CISA’s KEV entry sets August 27, 2026 as the remediation due date. That federal requirement applies to the Federal Civilian Executive Branch systems and agencies within Binding Operational Directive 26-04’s scope; the KEV entry calls for vendor mitigations, applicable federal cloud guidance or discontinuation if mitigations are unavailable.^[1][4]

That date is not automatically a legal mandate for private-sector organizations. Private companies should treat KEV inclusion and the compressed federal window as a strong risk-prioritization signal, then act under their own contracts, regulatory duties, change controls and incident-response requirements.

Bottom line

Organizations running the listed Oracle HTTP Server/WebLogic proxy components should inventory now, preserve a pre-change record, apply the correct Oracle CPU package through an approved change process and verify that no stale runtime or deployment copy remains. Organizations that do not run the named components are not placed in scope merely because they use another Oracle or WebLogic product.

The defensible message is urgent but narrow: CISA confirms known exploitation of CVE-2026-21962; the official sources do not identify who is exploiting it, whom they compromised or how many victims exist.

Sources

1. CISA Known Exploited Vulnerabilities Catalog (JSON feed)

   Apply mitigations in accordance with vendor instructions, ensuring compliance with CISA’s BOD 26-04 Prioritizing Security Updates Based on Risk (see URL in Notes) guidance and CISA’s “Forensics Triage Requirements” (see URL in Notes). Follow applicable BOD 26-04 guidance for cloud services or discontinue use of the product if mitigations are unavailable. Stakeholders are responsible for evaluating each asset’s internet exposure and ensuring adherence to BOD 26-04 patching guidelines.

2. Oracle Critical Patch Update Advisory — January 2026

   “Oracle strongly recommends that customers apply Critical Patch Update security patches as soon as possible.”

   “Neither approach should be considered a long-term solution as neither corrects the underlying problem.”

3. Oracle January 2026 Critical Patch Update Risk Matrices — text form

   “Supported versions that are affected are 12.2.1.4.0, 14.1.1.0.0 and 14.1.2.0.0.”

   “Affected version for Weblogic Server Proxy Plug-in for IIS is 12.2.1.4.0 only.”

4. CISA Binding Operational Directive 26-04

   “This directive refers to the systems to which it applies as “Federal Civilian Executive Branch” systems, and to agencies operating those systems as “Federal Civilian Executive Branch” agencies.”