CVE-2026-21962: Oracle HTTP Server & WebLogic Proxy Plug-in Improper Access Control — KEV-Listed, Detection and Remediation Guide

On August 24, 2026, CISA added CVE-2026-21962 to the Known Exploited Vulnerabilities (KEV) catalog, confirming that an improper access control flaw in Oracle HTTP Server (OHS) and the Oracle WebLogic Server Proxy Plug-in is being actively exploited in the wild. The vulnerability allows an unauthenticated or improperly authorized remote attacker to gain unauthorized creation, deletion, or modification of critical data — and in worst-case scenarios, complete access to all data accessible through the affected components.

The federal remediation deadline under BOD 22-01 is August 27, 2026 — a three-day window that signals how serious CISA considers the observed exploitation. If you run OHS as a front-end for WebLogic, Fusion Middleware, or any Oracle enterprise application stack, assume internet-facing instances are being probed and attacked right now.

This post breaks down what we know, how to hunt for compromise, and how to remediate on an emergency timeline.

Technical Analysis

Affected Products

• Oracle HTTP Server (OHS) — the Apache-based web tier commonly deployed in front of Oracle Fusion Middleware and WebLogic domains
• Oracle WebLogic Server Proxy Plug-in — the connector module (mod_wl_ohs for OHS, plus the IIS and Apache httpd plug-in variants) that proxies requests from the web tier to backend WebLogic servers

These components sit at the perimeter of the enterprise application stack. They terminate TLS, route requests, and broker access to backend business logic — which means compromise at this layer exposes everything downstream: application data, session state, and in many deployments, a pivot path into the internal network.

The Vulnerability

CVE-2026-21962 is classified as an improper access control vulnerability (CWE-284 family). Per Oracle's advisory and the CISA KEV entry, successful exploitation can result in:

• Unauthorized creation, deletion, or modification of critical data
• Unauthorized read access to critical data
• Complete access to all data accessible through OHS and the WebLogic Proxy Plug-in

From a defender's perspective, the practical attack model looks like this:

1. Attack vector: Network. The attacker sends crafted HTTP/HTTPS requests to the exposed web tier. No prior authentication is the expected model for a flaw of this impact class — treat it as remotely exploitable without credentials.
2. Affected component: Request handling / access enforcement logic. The proxy plug-in and OHS fail to properly enforce authorization boundaries on certain request paths, headers, or methods, allowing the attacker to reach functionality or data that should be restricted.
3. Impact: Full data compromise at the web tier. Because the proxy plug-in brokers traffic to backend WebLogic applications, improper access control here frequently translates to unauthorized interaction with backend application endpoints — effectively bypassing the application tier's own access decisions.

Exploitation Status

• CISA KEV: Confirmed active exploitation (added 2026-08-24)
• Federal remediation deadline: 2026-08-27
• Vendor guidance: Apply mitigations per Oracle's instructions, follow BOD 22-01 guidance for cloud services, or discontinue use of the product if mitigations are unavailable

CISA does not add vulnerabilities to the KEV on speculation. An entry with a three-day remediation window means exploitation is observed, repeatable, and likely being automated or operationalized by threat actors against internet-facing Oracle web tiers.

Why This Is High-Risk

OHS/WebLogic Proxy Plug-in deployments are ubiquitous in government, healthcare, financial services, and higher education — exactly the verticals that run PeopleSoft, E-Business Suite, and custom Java EE applications behind these components. The web tier is, by design, internet-reachable. An improper access control flaw at this layer is one of the highest-leverage targets an attacker can find.

Detection & Response

Because exploitation occurs over HTTP(S) against the web tier, your highest-fidelity telemetry sources are OHS access logs, proxy plug-in logs (wlproxy), web server process behavior, and network-layer request patterns. The detections below focus on: (a) post-exploitation behavior — the web server process doing things it should never do — and (b) suspicious request patterns consistent with access-control probing.

Sigma Rules

The most reliable post-exploitation signal for any web-tier vulnerability is the web server worker process spawning unexpected child processes — a classic indicator that an attacker has achieved command execution or is staging tools after gaining unauthorized access.

---
title: Oracle HTTP Server Worker Process Spawning Suspicious Child Process
id: 3f8c1a92-7d4e-4b6a-9f21-5e0a8d3c7b12
status: experimental
description: Detects Oracle HTTP Server (httpd/ohs) worker processes spawning shells, scripting interpreters, or system utilities — a strong post-exploitation indicator for web-tier compromise such as CVE-2026-21962.
references:
  - https://www.cisa.gov/known-exploited-vulnerabilities-catalog?search_api_fulltext=CVE-2026-21962
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/08/24
tags:
  - attack.initial_access
  - attack.t1190
  - attack.execution
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentCommandLine|contains:
      - 'httpd'
      - '/ohs/'
      - 'ohs1'
  selection_child:
    CommandLine|contains:
      - '/bin/sh'
      - '/bin/bash'
      - 'curl '
      - 'wget '
      - 'python'
      - 'perl '
      - 'nc '
      - 'ncat'
      - 'base64'
  condition: selection_parent and selection_child
falsepositives:
  - Legitimate OHS admin scripts executed via cron with httpd in the process tree (rare)
  - Monitoring agents wrapping web server health checks
level: high
---
title: WebLogic Proxy Plug-in Suspicious Request Pattern
id: 9d2e6b41-3a7f-4c58-b84e-1f6d9a2c5e37
status: experimental
description: Detects HTTP request patterns against Oracle HTTP Server / WebLogic Proxy Plug-in consistent with access control bypass probing — path traversal, internal console paths, and unexpected methods on proxied WebLogic endpoints.
references:
  - https://www.cisa.gov/known-exploited-vulnerabilities-catalog?search_api_fulltext=CVE-2026-21962
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/08/24
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: webserver
detection:
  selection_uri:
    cs-uri|contains:
      - '../'
      - '..%2f'
      - '%2e%2e'
      - '/console/'
      - '/wls-wsat/'
      - '/_async/'
      - '/uddiexplorer/'
      - '/bea_wls_internal/'
  selection_method:
    cs-method:
      - 'PUT'
      - 'DELETE'
      - 'TRACE'
      - 'CONNECT'
  condition: selection_uri or selection_method
falsepositives:
  - Internal admin access to /console/ from trusted management networks (filter by source IP)
  - Vulnerability scanners — tune against known scanner IPs but treat unauthorized scanning as an alert
level: medium

KQL — Microsoft Sentinel / Defender

If you ingest OHS access logs into Sentinel via Syslog/CEF (or a custom log table), the following hunts for both probing patterns and post-exploitation process behavior:

// Hunt 1: Suspicious request patterns against Oracle HTTP Server / WebLogic Proxy Plug-in
// Assumes OHS access logs ingested via Syslog or CommonSecurityLog (CEF from a WAF/LB in front)
let SuspiciousPaths = dynamic(["../", "..%2f", "%2e%2e", "/console/", "/wls-wsat/", "/_async/", "/uddiexplorer/", "/bea_wls_internal/"]);
union isfuzzy=true
    (CommonSecurityLog
     | where DeviceVendor =~ "Oracle" or ApplicationProtocol =~ "http"
     | where RequestURL has_any (SuspiciousPaths)
     | where RequestMethod in~ ("PUT", "DELETE", "TRACE", "CONNECT", "POST", "GET")
     | project TimeGenerated, SourceIP, RequestURL, RequestMethod, RequestClientApplication, DeviceAction
    ),
    (Syslog
     | where SyslogMessage has_any (SuspiciousPaths)
     | where SyslogMessage has_any ("httpd", "ohs", "weblogic", "mod_wl")
     | project TimeGenerated, HostIP, Computer, SyslogMessage
    )
| summarize RequestCount = count(), DistinctPaths = dcount(tostring(RequestURL)) by SourceIP, bin(TimeGenerated, 1h)
| where RequestCount > 10 or DistinctPaths > 3
| sort by RequestCount desc;

// Hunt 2: Web server process spawning shells or download tooling (Linux hosts onboarded to MDE)
DeviceProcessEvents
| where InitiatingProcessFileName has_any ("httpd", "ohs")
   or InitiatingProcessCommandLine has_any ("/ohs/", "mod_wl")
| where FileName in~ ("sh", "bash", "curl", "wget", "nc", "ncat", "python", "python3", "perl", "base64")
| project TimeGenerated, DeviceName, InitiatingProcessCommandLine, FileName, ProcessCommandLine, AccountName
| sort by TimeGenerated desc;

Analyst note on Hunt 1: a single hit on /console/ from an external IP is worth investigating; a source IP cycling through multiple internal WebLogic paths within an hour is almost certainly reconnaissance or exploitation. Baseline your scanner IPs and exclude them — but alert on scanning from unauthorized sources.

Velociraptor VQL

Use this hunt across Linux hosts running OHS to surface post-exploitation process execution and unexpected network connections from the web server process:

-- Hunt for post-exploitation behavior from Oracle HTTP Server processes
-- Looks for shell/utility children of httpd/ohs workers and their network connections
SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE (Name =~ '(?i)httpd|ohs' OR CommandLine =~ '(?i)/ohs/|mod_wl')
   OR (
        Ppid IN (
          SELECT Pid FROM pslist() WHERE Name =~ '(?i)httpd|ohs'
        )
        AND Name =~ '(?i)^(sh|bash|dash|curl|wget|nc|ncat|python|python3|perl|base64)$'
      )
ORDER BY CreateTime DESC

-- Correlate: outbound connections from web server processes (potential C2 or data exfil)
SELECT Pid, Name, Status, Family, Address, Port, Raddress, Rport
FROM netstat()
WHERE Name =~ '(?i)httpd|ohs'
  AND Rport != 0
  AND NOT (Raddress =~ '^(10\\.|172\\.(1[6-9]|2[0-9]|3[01])\\.|192\\.168\\.|127\\.)' AND Rport IN (7001, 7002, 8001, 9001))
ORDER BY Pid

The second query assumes the only legitimate outbound connections from OHS are to backend WebLogic managed servers on typical admin/listen ports — tune the port list to your architecture. An OHS worker holding an outbound connection to a public IP on a non-standard port is a critical finding.

Remediation / Verification Script

The following Bash script inventories OHS and WebLogic Proxy Plug-in installations on a Linux host, checks for signs of probing in access logs, and captures current version information needed to validate patch level against Oracle's advisory:

#!/bin/bash
# CVE-2026-21962 — Oracle HTTP Server / WebLogic Proxy Plug-in triage script
# Run as root on each OHS / web-tier host. Read-only: collects evidence, changes nothing.

echo "===== CVE-2026-21962 Triage — $(hostname) — $(date -u) ====="

echo -e "\n[1] Running OHS / httpd processes"
ps aux | grep -Ei 'httpd|ohs|weblogic' | grep -v grep || echo "No matching processes found"

echo -e "\n[2] OHS / Proxy Plug-in binaries and version info"
find / -name "httpd" -path "*ohs*" 2>/dev/null | head -5 | while read -r bin; do
  echo "--- $bin ---"
  "$bin" -v 2>/dev/null
done
find / -name "mod_wl_ohs.so" 2>/dev/null | head -10
find / -name "mod_wl*.so" -o -name "iisproxy.dll" 2>/dev/null | head -10

echo -e "\n[3] Recent probing indicators in OHS access logs (last 10k lines)"
for log in $(find / -name "access_log*" -path "*ohs*" 2>/dev/null | head -5); do
  echo "--- $log ---"
  tail -n 10000 "$log" | grep -Ei '\.\./|\.\.%2f|%2e%2e|/console/|/wls-wsat/|/_async/|/uddiexplorer/|/bea_wls_internal/|PUT |DELETE |TRACE ' | tail -25
done

echo -e "\n[4] Suspicious child processes of web server workers (running now)"
for pid in $(pgrep -f 'httpd|ohs'); do
  ps --ppid "$pid" -o pid,ppid,user,comm,args 2>/dev/null | grep -Ei 'sh|bash|curl|wget|nc |python|perl' && echo "^ Suspicious child of PID $pid"
done

echo -e "\n[5] Non-standard outbound connections from web server processes"
ss -tnp 2>/dev/null | grep -Ei 'httpd|ohs' | grep -vE ':(7001|7002|8001|9001|443|80)\b' | head -20

echo -e "\n===== Triage complete. Review output; escalate any hits in sections 3-5 to IR. ====="

Remediation

Immediate Actions (Next 24 Hours)

1. Apply Oracle's mitigations immediately. Pull the current Critical Patch Update (CPU) advisory from Oracle covering CVE-2026-21962 and apply the vendor-supplied patch or mitigation to every OHS instance and every web server (Apache httpd, IIS) running the WebLogic Proxy Plug-in. Oracle advisories are published at: https://www.oracle.com/security-alerts/ — check the most recent CPU and any out-of-band Security Alert for this CVE.
2. Meet the CISA deadline: 2026-08-27. Under BOD 22-01, federal civilian agencies must remediate by this date. Private-sector organizations should treat it as their own deadline — the three-day window reflects observed exploitation tempo. For cloud-hosted instances, follow applicable BOD 22-01 cloud services guidance.
3. If you cannot patch, take the tier offline or restrict it. CISA's required action explicitly includes discontinuing use of the product if mitigations are unavailable. Short of that, place OHS behind a WAF with strict virtual patching rules, restrict access to known source IP ranges, and block all non-essential HTTP methods (PUT, DELETE, TRACE, CONNECT) at the edge.

Configuration Hardening (This Week)

• Block WebLogic internal paths at the edge. Requests to /console/, /wls-wsat/, /_async/, /uddiexplorer/, and /bea_wls_internal/ should never be reachable from the internet. Deny them at the load balancer/WAF and in OHS <Location> directives — defense in depth matters when the access control layer itself is the vulnerability.
• Audit proxy plug-in configuration. Review mod_wl_ohs.conf / proxy plug-in config for overly broad LocationMatch or PathTrim directives that expose backend application paths unintentionally. Proxy only the URL spaces the application actually requires.
• Restrict HTTP methods. Configure LimitExcept in OHS to permit only GET/POST (and HEAD/OPTIONS where needed) for public-facing locations.
• Segment the web tier. OHS hosts should sit in a DMZ with egress filtering permitting only connections to backend WebLogic listen ports. No direct internet egress from the web tier — this breaks most post-exploitation C2 and exfiltration paths.

Verification & Hunt-Back (This Week)

• Patch verification: After applying the CPU, confirm the OHS build/version string matches the patched level documented in Oracle's advisory, and validate the proxy plug-in module (mod_wl_ohs.so) file version/timestamp. Re-run the triage script above and diff against baseline.
• Retrospective hunt: Because exploitation predates the KEV listing, review at least 30 days of OHS access logs for the probing patterns in the KQL hunt above. If you find suspicious requests, pivot to process and connection telemetry on the affected host and treat it as a potential intrusion, not a patching exercise.
• Credential and session hygiene: If you find evidence of successful exploitation, assume session tokens and any credentials accessible to the web tier are compromised. Force session invalidation on backend applications and rotate service account credentials used by the proxy tier.

Longer Term

• Get OHS logs into your SIEM. Many organizations front critical applications with OHS and never centralize its access logs. That gap is why web-tier exploitation so often goes undetected for weeks. Ingest OHS access/error logs and wlproxy logs into Sentinel or your platform of choice with the detections above enabled.
• Track the Oracle CPU cadence. Oracle patches on a quarterly CPU cycle with occasional out-of-band alerts. KEV additions between CPU cycles are your signal to demand emergency change windows.

The Bottom Line

CVE-2026-21962 is a confirmed, actively exploited improper access control flaw sitting at the front door of Oracle enterprise application stacks. The 72-hour federal remediation window is not bureaucratic theater — it reflects real attack pressure. Patch per Oracle's advisory before August 27, 2026, harden the exposed URL space at the edge, and hunt back through your web-tier logs for signs you were already hit. If mitigations genuinely cannot be applied, CISA's guidance is unambiguous: take the product out of service.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub