CVE-2026-21962, Oracle WebLogic Proxy Plug-in at the Edge

CVE-2026-21962 is a maximum-severity vulnerability in Oracle HTTP Server and the Oracle WebLogic Server Proxy Plug-in. Oracle disclosed it in the January 2026 Critical Patch Update, and NVD records it with CVSS 3.1 vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N, which produces a base score of 10.0. The affected component is not just a backend application running on WebLogic. It is the proxy layer that often sits on Oracle HTTP Server, Apache HTTP Server, or Microsoft IIS and forwards HTTP traffic into WebLogic Server clusters. That placement is why defenders should treat the bug as an edge-exposure problem, not as an ordinary middleware housekeeping item. (أوراكل)

The most important correction is timing. The CISA deadline that drew attention in early June 2026 was tied to CVE-2024-21182, an older Oracle WebLogic Server Core vulnerability that CISA added to the Known Exploited Vulnerabilities catalog on June 1, 2026, with a federal remediation due date of June 4, 2026. CVE-2026-21962 is related by product family and risk profile, but it is not the same vulnerability. Public reporting has connected CVE-2026-21962 to automated exploitation attempts after exploit code appeared, while the June 4 CISA deadline was about CVE-2024-21182. Mixing the two produces the wrong remediation story. (CISA)

The official CVE text is severe enough without embellishment. NVD states that an unauthenticated attacker with HTTP network access can compromise Oracle HTTP Server and the WebLogic Server Proxy Plug-in. Successful attacks can lead to unauthorized creation, deletion, or modification of critical data, as well as unauthorized access to critical or complete data accessible to the vulnerable product. Oracle’s risk matrix also marks the issue as remotely exploitable without authentication, over HTTP, with changed scope, high confidentiality impact, high integrity impact, and no availability impact in the CVSS vector. (NVD)

That wording matters. Some third-party writeups describe CVE-2026-21962 as an authentication bypass, an access-control failure, path handling abuse, or even potential remote code execution. Those descriptions may reflect observed probing, lab assumptions, or vendor-specific detection logic, but Oracle and NVD do not publish a root-cause-level exploit explanation. A responsible technical treatment should separate confirmed facts from plausible attack patterns. The safe conclusion is that CVE-2026-21962 is an unauthenticated, low-complexity, HTTP-reachable proxy-layer vulnerability with severe confidentiality and integrity impact. Treat any more specific claim about exploit mechanics as conditional unless it is tied to a reliable primary source. (NVD)

The confirmed facts

The table below normalizes the official facts from Oracle, NVD, and Singapore’s Cyber Security Agency. The affected versions are the first thing defenders should validate because the vulnerable surface is not always named “WebLogic Server” in asset inventory systems. It may be listed under Oracle HTTP Server, OHS, Apache with WebLogic plug-in, mod_wl_ohs, mod_wl, or a Microsoft IIS WebLogic forwarding extension. (أوراكل)

الحقل	Confirmed detail
مكافحة التطرف العنيف	CVE-2026-21962
Vendor	أوراكل
Product family	Oracle Fusion Middleware
Affected product names	Oracle HTTP Server, Oracle WebLogic Server Proxy Plug-in
Affected component	WebLogic Server Proxy Plug-in for Apache HTTP Server and WebLogic Server Proxy Plug-in for IIS
الإصدارات المتأثرة	12.2.1.4.0, 14.1.1.0.0, 14.1.2.0.0
IIS-specific note	WebLogic Server Proxy Plug-in for IIS is affected only at version 12.2.1.4.0
Protocol	HTTP
Remotely exploitable without authentication	نعم
CVSS 3.1 score	10.0
CVSS vector	AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N
Primary impacts	Confidentiality and integrity
Availability impact in CVSS vector	لا يوجد
Patch source	Oracle January 2026 Critical Patch Update

The IIS note is easy to miss. NVD includes it explicitly: “Affected version for Weblogic Server Proxy Plug-in for IIS is 12.2.1.4.0 only.” That does not mean IIS deployments can ignore the issue; it means IIS owners must confirm the exact plug-in version rather than assuming the same affected range as Oracle HTTP Server and Apache plug-in deployments. (NVD)

Singapore’s Cyber Security Agency published a short alert on January 22, 2026, advising users and administrators to update affected Oracle HTTP Server and WebLogic Server Proxy Plug-in products immediately. CSA lists the same affected Oracle HTTP Server and WebLogic Server Proxy Plug-in versions and separately calls out WebLogic Server Proxy Plug-in for IIS version 12.2.1.4.0. (Cyber Security Agency of Singapore)

Oracle’s January 2026 Critical Patch Update contained 337 new security patches across Oracle product families. Oracle also repeats a standing warning that it periodically receives reports of malicious exploitation attempts against vulnerabilities for which patches are already available, and that successful compromises have occurred when customers failed to apply available patches. That warning is generic across Oracle CPUs, but it is directly relevant to WebLogic because old WebLogic bugs often remain reachable for years in production environments. (أوراكل)

Why the proxy layer changes the risk

Oracle WebLogic Server is frequently deployed behind a web-tier component. In a common layout, the public client talks to Oracle HTTP Server, Apache HTTP Server, or IIS. The WebLogic Server Proxy Plug-in then forwards selected requests to backend WebLogic Server instances or clusters. Oracle’s Apache plug-in documentation describes path-based proxying with a <Location> block, WLSRequest Onو PathTrim; Oracle’s parameter documentation defines WebLogicHost, WebLogicPort, WebLogicCluster, WLCookieName, WLProxySSL, WLProxySSLPassThrough, SecureProxy, and related parameters used to route and transform traffic between the front-end web tier and backend WebLogic. (Oracle Documentation)

That architecture creates a security boundary. The proxy sees the request before the backend application has applied most application-level authentication, authorization, routing, session handling, and input validation. The plug-in also has operational knowledge that a normal external client should not have: where backend nodes live, which paths should be forwarded, how SSL termination is represented to WebLogic, and how failover or dynamic cluster lists are maintained. A vulnerability in that layer can therefore affect more than one application route and more than one backend node.

The proxy tier is also where enterprise assumptions accumulate. Security teams may believe WebLogic is “not internet-facing” because the managed servers listen only on internal addresses. That may be true for the backend nodes, but the WebLogic Proxy Plug-in is designed to expose selected WebLogic functionality through a front-end web server. If the front-end server is reachable from the internet, the vulnerable component may still be internet-facing even when port 7001 or 7002 is blocked externally.

The official CVSS vector confirms that distinction through S:C, or changed scope. In CVSS terms, a scope change means exploitation can affect resources beyond the vulnerable component’s own security authority. For CVE-2026-21962, the vulnerable product is the Oracle HTTP Server or WebLogic Server Proxy Plug-in, but the practical business impact may include backend WebLogic-accessible data and systems routed through that proxy. (NVD)

A plain-English reading of the CVSS vector

The vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N is worth unpacking because it explains why this vulnerability deserves emergency handling even without public root-cause detail.

CVSS metric	القيمة	Meaning for defenders
ناقل الهجوم	Network	The attacker can reach the vulnerable component over a network path, specifically HTTP in Oracle’s matrix.
Attack Complexity	منخفضة	Exploitation does not require unusual environmental conditions according to the CVSS scoring.
الامتيازات المطلوبة	لا يوجد	The attacker does not need an account on the target system.
تفاعل المستخدم	لا يوجد	No victim click, file open, or authenticated user action is required.
النطاق	Changed	The impact can cross a security boundary beyond the vulnerable component.
السرية	عالية	Critical or complete accessible data may be exposed.
النزاهة	عالية	Critical or complete accessible data may be created, deleted, or modified.
Availability	لا يوجد	The CVSS vector does not score service outage as the primary impact.

A 10.0 score is not a synonym for “remote shell is confirmed.” In this case, the score comes from unauthenticated network reachability, low complexity, no user interaction, changed scope, and high confidentiality and integrity impact. The absence of availability impact in the official vector is also meaningful. It means defenders should prioritize data exposure and unauthorized data manipulation, not only crashes, denial-of-service events, or obvious process instability. (NVD)

That distinction affects detection. A successful attack may not produce a loud outage. The more important signs may be unusual write operations, unauthorized backend access, changes to application data, strange access patterns through proxied paths, or security controls being bypassed at the edge. If a SOC only searches for process crashes or Java child processes, it may miss the core risk described by Oracle and NVD.

What is confirmed and what should be handled cautiously

The public ecosystem around WebLogic vulnerabilities moves fast. Within days of disclosure, vendors, researchers, scanners, and opportunistic operators start publishing signatures, proof-of-concept claims, and exploit notes. That information is useful, but not all of it has equal reliability.

Claim type	Confidence	How to use it
Affected products and versions	عالية	Use Oracle, NVD, and CSA as the baseline for inventory and patching.
CVSS 10.0 and vector	عالية	Use the official vector to drive priority and executive risk communication.
Unauthenticated HTTP network exploitation	عالية	Prioritize internet-facing or partner-facing HTTP front ends.
Confidentiality and integrity impact	عالية	Investigate data access and data modification, not only process execution.
Automated exploitation attempts	Medium to high	CloudSEK reported automated attempts after public exploit code; use this as threat context, not as proof that every internet-facing instance is compromised.
Specific path traversal or header-manipulation mechanics	متوسط	Some third-party reporting mentions these patterns; use them for hunting with caution.
Exact root cause	Lower unless vendor-confirmed	Do not assert internal parsing mechanics unless supported by Oracle or a reliable technical advisory.
Reliable RCE against all affected deployments	Lower unless independently verified in your environment	Do not base risk acceptance on unverified public PoCs or social media payloads.

CloudSEK’s honeypot report is one of the more useful public sources because it focuses on observed traffic, not just advisory restatement. It reported a 12-day high-interaction WebLogic honeypot study from January 22 to February 3, 2026, and said automated exploitation attempts targeting CVE-2026-21962 surged after public exploit code was released. The same report observed continued attempts against older WebLogic flaws, including CVE-2020-14882, CVE-2020-14883, CVE-2020-2551, and CVE-2017-10271, and described much of the traffic as high-volume automated scanning from hosting providers and common scanning tools. (CloudSEK)

SANS ISC published a useful cautionary note in late January 2026 after seeing odd WebLogic requests that might have been related to CVE-2026-21962. The diary noted an uptick in requests involving a WebLogic proxy-related header, but also warned that some apparent exploit strings looked like “AI slop” rather than reliable exploitation. That warning should shape detection engineering: hunt for suspicious patterns, but do not assume every public payload is technically valid. (SANS Internet Storm Center)

The practical takeaway is simple. Patch based on the official severity, not based on whether a public PoC looks convincing. Hunt using third-party observations, but label them as detection hypotheses. Avoid publishing exploit mechanics internally as fact unless your team has validated them in a controlled lab or has a vendor-confirmed technical advisory.

Exposure patterns that deserve priority

The most urgent assets are not necessarily the most famous WebLogic servers. The assets to find first are the web-tier nodes that load the WebLogic proxy module or equivalent IIS plug-in and are reachable from untrusted networks.

High-priority exposure patterns include:

Exposure pattern	ما أهمية ذلك
Internet-facing Oracle HTTP Server with mod_wl_ohs	OHS is commonly used as the WebLogic front end, and the vulnerable component may live there.
Apache HTTP Server with WebLogic Proxy Plug-in	The plug-in can be installed as a shared object module and may not be obvious in application inventories.
Microsoft IIS with WebLogic Server Proxy Plug-in	IIS has a narrower affected version note, but misidentified Windows middleware often stays unpatched longer.
CDN or WAF in front of OHS/Apache/IIS	The origin may still be reachable directly, or the WAF may not normalize requests exactly as the plug-in does.
Partner-facing portals	“Not public” partner access is still untrusted if the component is reachable over HTTP.
Legacy ERP, identity, insurance, banking, and government portals	These environments commonly retain older Fusion Middleware stacks for long-lived business systems.
Shared web-tier nodes fronting multiple applications	A proxy-layer issue can affect several backend apps through one edge component.
WebLogic clusters with dynamic server lists	The plug-in may have routing knowledge across backend nodes, increasing blast radius.

Oracle’s documentation shows that the plug-in can be configured by path, host, port, cluster, SSL behavior, cookie handling, and other parameters. Those configuration details are exactly why asset discovery must include front-end web server configuration files, not only WebLogic domain directories. (Oracle Documentation)

Asset inventory, do not stop at the WebLogic console

A common mistake is to ask only, “What WebLogic version are we running?” That is incomplete for CVE-2026-21962. The affected product can be Oracle HTTP Server and the WebLogic Server Proxy Plug-in, including Apache and IIS plug-in variants. A backend WebLogic console may not tell you whether a front-end Apache or IIS module is vulnerable, separately packaged, or forgotten.

For Linux and Oracle HTTP Server or Apache deployments, start with module and configuration discovery. The following commands are safe inventory checks. They do not attempt exploitation.

#!/usr/bin/env bash
set -euo pipefail

echo "[1] Web server processes"
ps -ef | egrep 'httpd|apache2|ohs|opmn|node_manager|weblogic' | grep -v egrep || true

echo
echo "[2] Loaded Apache/OHS modules that look WebLogic-related"
for bin in /usr/sbin/httpd /usr/sbin/apache2 /usr/local/apache2/bin/httpd /u01/*/*/bin/httpd; do
  if [ -x "$bin" ]; then
    echo "### $bin"
    "$bin" -M 2>/dev/null | egrep -i 'weblogic|wl|proxy' || true
  fi
done

echo
echo "[3] Common WebLogic proxy configuration references"
sudo grep -RInE 'mod_wl|mod_wl_ohs|weblogic_module|WLSRequest|WebLogicHost|WebLogicPort|WebLogicCluster|WLProxySSL|WLProxySSLPassThrough|SecureProxy|PathTrim' \
  /etc/httpd /etc/apache2 /u01 /opt/oracle 2>/dev/null | head -300 || true

echo
echo "[4] Candidate plug-in binaries"
sudo find /u01 /opt /usr/lib /usr/lib64 /etc -iname '*mod_wl*' -o -iname '*weblogic*plugin*' 2>/dev/null | head -200 || true

For Windows and IIS, check for WebLogic ISAPI or proxy plug-in references. Keep the scope limited to systems your organization owns or is authorized to assess.

Write-Host "[1] IIS modules with WebLogic-like names"
Import-Module WebAdministration
Get-WebGlobalModule | Where-Object {
    $_.Name -match "weblogic|wl|proxy" -or $_.Image -match "weblogic|wl|iisforward|proxy"
} | Format-List *

Write-Host "[2] IIS handler mappings with WebLogic-like references"
Get-WebHandler | Where-Object {
    $_.Name -match "weblogic|wl|proxy" -or $_.ScriptProcessor -match "weblogic|wl|iisforward|proxy"
} | Format-List *

Write-Host "[3] Files that may indicate WebLogic IIS plug-in installation"
Get-ChildItem -Path "C:\","D:\" -Recurse -ErrorAction SilentlyContinue `
  -Include "*iisforward*","*weblogic*plugin*","*wlproxy*","*mod_wl*" |
  Select-Object FullName,Length,LastWriteTime |
  Format-Table -AutoSize

For containerized or image-based deployments, look for plug-in packages in Dockerfiles and image layers. Oracle’s own Docker sample repository includes a standalone Apache HTTP Server with the 12.2.1.3.0 and 12.2.1.4.0 Oracle WebLogic Server Proxy Plugin, which is a reminder that the plug-in can live in an image separate from the WebLogic domain itself. (جيثب)

echo "[1] Search Dockerfiles and compose files for WebLogic proxy indicators"
grep -RInE 'weblogic.*proxy|mod_wl|WLSRequest|WebLogicCluster|WebLogicHost|WLProxySSL|OracleWebLogic|weblogic-plugin' \
  ./Dockerfile* ./*.yml ./*.yaml ./charts ./k8s 2>/dev/null || true

echo "[2] Inspect running container images for names that suggest OHS/Apache/WebLogic front ends"
docker ps --format '{{.ID}} {{.Image}} {{.Names}}' | egrep -i 'ohs|oracle|apache|httpd|weblogic|wls' || true

The goal is to produce an asset list with four fields: front-end server, plug-in type, plug-in version or package lineage, and the backend WebLogic destinations reachable through that front end. Without those four fields, remediation status is not trustworthy.

Configuration review, the proxy rules are security boundaries

Configuration review is not a substitute for patching, but it is necessary for scoping the blast radius. Oracle’s documentation shows that proxying can be defined by <Location> blocks using WLSRequest On, and that PathTrim can alter the URL before the request reaches WebLogic. Oracle’s plug-in parameter documentation also defines host, port, cluster, SSL, failover, cookie, and pass-through settings that shape how traffic crosses the front-end to backend boundary. (Oracle Documentation)

A minimal review should answer these questions:

سؤال	ما أهمية ذلك
Which paths are proxied into WebLogic?	A vulnerability in proxy request handling may expose only certain routes, or it may affect every proxied route depending on configuration.
Are admin routes proxied?	Admin consoles should not be exposed through public web tiers.
Is the backend WebLogic host reachable directly from untrusted networks?	Direct access can bypass controls at the web tier and create a second exposure path.
Is SSL terminated before the plug-in?	Header trust settings such as WLProxySSL و WLProxySSLPassThrough affect how WebLogic interprets the original request.
Are dynamic cluster lists enabled?	A compromised or abused proxy can have knowledge of multiple backend nodes.
Are temporary upload or post-data directories protected?	Proxy temp directories can become useful evidence sources and should not be world-readable.
Is debug logging enabled in production?	Debug logs may leak sensitive routing or request details.
Which upstream IPs are allowed to reach the web tier?	Internet-wide access is much riskier than access restricted to trusted load balancers or internal ingress points.

A hardened Apache-style configuration should make the trust boundary explicit. The snippet below is illustrative, not a universal drop-in. Teams should adapt it to their Oracle-supported deployment model and test it in staging.

# Example hardening pattern, not a patch for CVE-2026-21962.
# Apply Oracle CPU patches first. Use this pattern to reduce accidental exposure.

# Only proxy the required application path.
<Location /app>
    WLSRequest On
    WebLogicCluster wls-managed-1.internal.example:7003,wls-managed-2.internal.example:7003
    PathTrim /app

    # Use secure backend communication where supported and configured.
    SecureProxy ON

    # Keep proxy SSL behavior explicit. Do not trust arbitrary client-supplied
    # proxy headers unless a trusted load balancer controls them.
    WLProxySSL ON
    WLProxySSLPassThrough OFF

    # Reduce unexpected retry behavior for non-idempotent requests.
    WLRetryAfterDroppedConnection IDEMPOTENT
</Location>

# Keep admin and internal routes off the public proxy.
<LocationMatch "^/(console|bea_wls_internal|wls-wsat|_async|uddiexplorer)">
    Require all denied
</LocationMatch>

The exact route names in deny rules depend on the application and WebLogic version. The point is not that this snippet blocks CVE-2026-21962. It does not. The point is that proxy scope should be small, explicit, and auditable. A broad proxy rule that forwards entire path trees into WebLogic increases the cost of investigation and the chance that a vulnerable edge component exposes sensitive backend functionality.

Safe validation workflow

Security teams need a validation path that proves exposure without turning production into an exploit lab. A safe workflow has five stages.

First, identify whether the vulnerable product exists. Use package records, module lists, file paths, and configuration references. Do not rely on an application owner saying “we use WebLogic” or “we do not use WebLogic.” The proxy plug-in may be owned by an infrastructure team, a vendor, or an old middleware group.

Second, confirm affected versions. Oracle’s affected range includes 12.2.1.4.0, 14.1.1.0.0, and 14.1.2.0.0 for Oracle HTTP Server and the WebLogic Server Proxy Plug-in, with the IIS plug-in note limited to 12.2.1.4.0. Version evidence should come from installed packages, Oracle inventory, image build records, or vendor patch records rather than a web banner. (NVD)

Third, map exposure. Determine whether the front-end web tier is reachable from the internet, from partners, from VPN users, from internal user networks, or only from trusted load balancers. Network reachability changes incident priority. CVSS says network access over HTTP is enough, but your operational response depends on who can reach that HTTP surface.

Fourth, inspect logs for suspicious request patterns and post-request effects. Because official sources emphasize confidentiality and integrity impact, log review should include reads and writes to sensitive backend routes, not only errors. Look for unusual methods, encoded path segments, abnormal proxy headers, repeated 400/404/500 responses around WebLogic paths, and unexpected changes in backend data or configuration.

Fifth, patch and retest. Apply the Oracle CPU or the patch set identified in the Oracle Patch Availability Document for the relevant product and version. Retest the asset inventory and module version after patching. Do not mark the risk closed merely because the backend WebLogic Server was restarted.

The following shell script creates an evidence bundle for Linux web-tier hosts. It does not exploit the vulnerability. It collects process, module, configuration, and recent log context for review.

#!/usr/bin/env bash
set -euo pipefail

OUT="weblogic-proxy-evidence-$(hostname)-$(date -u +%Y%m%dT%H%M%SZ)"
mkdir -p "$OUT"

echo "[*] Collecting host and process context"
{
  date -u
  hostname -f || hostname
  uname -a
  ps -ef | egrep 'httpd|apache2|ohs|weblogic|node_manager' | grep -v egrep || true
} > "$OUT/host-process.txt"

echo "[*] Collecting module lists"
for bin in /usr/sbin/httpd /usr/sbin/apache2 /usr/local/apache2/bin/httpd /u01/*/*/bin/httpd; do
  if [ -x "$bin" ]; then
    safe_name=$(echo "$bin" | tr '/ ' '__')
    "$bin" -M > "$OUT/module-list-${safe_name}.txt" 2>&1 || true
  fi
done

echo "[*] Collecting relevant config lines"
sudo grep -RInE 'mod_wl|mod_wl_ohs|weblogic_module|WLSRequest|WebLogicHost|WebLogicPort|WebLogicCluster|WLProxySSL|WLProxySSLPassThrough|SecureProxy|PathTrim|WLTempDir' \
  /etc/httpd /etc/apache2 /u01 /opt/oracle 2>/dev/null \
  > "$OUT/weblogic-proxy-config-hits.txt" || true

echo "[*] Collecting recent WebLogic-like access log entries"
sudo find /var/log /u01 /opt/oracle -type f \( -iname '*access*log*' -o -iname '*error*log*' \) 2>/dev/null |
while read -r f; do
  sudo grep -Eai 'weblogic|bea_wls|wls|wl-proxy|proxy-client-ip|x-forwarded|%2e|%2f|;|chunked' "$f" 2>/dev/null |
  tail -200 |
  sed "s#^#$f:#"
done > "$OUT/recent-suspicious-log-sample.txt" || true

tar -czf "$OUT.tar.gz" "$OUT"
echo "[*] Evidence bundle written to $OUT.tar.gz"

For production environments, that evidence bundle should be stored in a controlled incident repository. It may contain sensitive paths, hostnames, headers, and application identifiers.

Detection engineering for CVE-2026-21962

Detection should begin with a conservative model: the attacker can reach an HTTP-facing proxy component and may try to make the proxy treat a request differently than the front-end server, WAF, or backend application expects. Because Oracle has not published a payload-level explanation in the advisory text, detection should combine confirmed risk with behavioral indicators rather than depend on a single magic string.

Useful log sources include:

المصدر	What to look for
OHS or Apache access logs	Repeated requests to proxied paths, encoded traversal-like segments, unusual methods, high 4xx/5xx rates, suspicious headers.
OHS or Apache error logs	Module errors, proxy routing failures, malformed request handling, backend connection anomalies.
IIS logs	Requests hitting WebLogic forwarding rules, unusual URI normalization, abnormal status/substatus combinations.
WAF or CDN logs	Requests blocked or normalized before reaching origin, repeated probing from hosting providers, path and header anomalies.
WebLogic access logs	Backend routes reached without expected user session context.
WebLogic domain logs	Security errors, unexpected deployment/configuration changes, authentication anomalies.
EDR telemetry	Unexpected child processes from web server or Java processes, unusual file writes, outbound callbacks.
Database audit logs	Unusual writes following suspicious HTTP requests.

CloudSEK observed high-volume automated scanning in its honeypot and noted tools such as libredtail-http and the Nmap Scripting Engine in the malicious traffic it analyzed. It also observed attacks against older WebLogic vulnerabilities in the same dataset. That supports a detection strategy that treats CVE-2026-21962 as part of broader WebLogic scanning noise rather than a clean, isolated campaign. (CloudSEK)

A Splunk query can start broad and then narrow. The example below avoids hard-coding an exploit payload. It looks for proxy-related terms, suspicious normalization characters, and request patterns that commonly appear in middleware probing.

index=web sourcetype IN ("apache:access","apache:error","iis","ohs:access","ohs:error")
(
  uri_path="*weblogic*" OR uri_path="*bea_wls*" OR uri_path="*wls*" OR
  http_user_agent="*Nmap*" OR http_user_agent="*libredtail*" OR
  request_headers="*WL-Proxy*" OR request_headers="*wl-proxy*" OR
  request_headers="*proxy-client-ip*" OR request_headers="*Transfer-Encoding*chunked*"
  OR uri_query="*%2e*" OR uri_path="*%2e*" OR uri_path="*;*"
)
| stats count min(_time) as firstSeen max(_time) as lastSeen
        values(status) as statuses
        values(method) as methods
        values(uri_path) as paths
        values(http_user_agent) as userAgents
        by src_ip dest_host
| convert ctime(firstSeen) ctime(lastSeen)
| sort - count

Microsoft Sentinel or Azure Data Explorer users can express the same idea in KQL:

let suspicious_terms = dynamic([
  "weblogic", "bea_wls", "wls", "wl-proxy", "WL-Proxy",
  "proxy-client-ip", "Transfer-Encoding", "%2e", "%2f", ";"
]);
W3CIISLog
| where TimeGenerated > ago(30d)
| extend combined = strcat(csUriStem, " ", csUriQuery, " ", csUserAgent, " ", csReferer)
| where combined has_any (suspicious_terms)
| summarize
    count(),
    firstSeen=min(TimeGenerated),
    lastSeen=max(TimeGenerated),
    statuses=make_set(scStatus, 10),
    uriSamples=make_set(csUriStem, 20),
    agents=make_set(csUserAgent, 10)
  by cIP, sSiteName, Computer
| order by count_ desc

A Sigma-style rule can help standardize SIEM content across environments. This rule is intentionally heuristic and should be tuned. It is not proof of exploitation.

title: Suspicious WebLogic Proxy Layer Probing
id: 2d8d01c9-7d42-4a8b-a1f1-weblogic-proxy-probing
status: experimental
description: Detects suspicious HTTP requests that may indicate probing of Oracle WebLogic proxy-layer components, including CVE-2026-21962 hunting hypotheses.
references:
  - Oracle January 2026 Critical Patch Update
  - NVD CVE-2026-21962
logsource:
  category: webserver
detection:
  selection_terms:
    cs-uri-stem|contains:
      - 'weblogic'
      - 'bea_wls'
      - 'wls'
      - ';'
      - '%2e'
      - '%2f'
  selection_headers:
    cs-headers|contains:
      - 'WL-Proxy'
      - 'wl-proxy'
      - 'proxy-client-ip'
      - 'Transfer-Encoding'
  selection_agents:
    cs-user-agent|contains:
      - 'Nmap'
      - 'libredtail'
  condition: selection_terms or selection_headers or selection_agents
fields:
  - src_ip
  - dest
  - cs-method
  - cs-uri-stem
  - sc-status
  - cs-user-agent
falsepositives:
  - Internal vulnerability scanners
  - Middleware health checks
  - Legacy WebLogic integrations using proxy headers
level: medium

The best alert is not the one that fires on the most strings. The best alert links suspicious request patterns to backend effects: an unexpected authenticated route reached without a valid session, a write operation following a malformed request, a WebLogic configuration change, a new deployment, an unusual admin action, or suspicious process activity on the web-tier host.

Patch first, then reduce blast radius

The primary remediation is to apply Oracle’s security updates for the affected product and version. Oracle’s Critical Patch Update page is the authoritative patch path, and CSA’s alert gives the right operational instruction: update affected products to the latest version immediately. (أوراكل)

When patching cannot happen immediately, compensating controls should reduce exposure while the change window is prepared. They are not equivalent to a patch.

التحكم	القيمة	التقييد
Restrict inbound HTTP access to trusted load balancers or VPN ranges	Reduces who can reach the vulnerable component	Does not protect against compromised trusted networks or origin bypass
Block direct origin access when CDN/WAF is used	Prevents attackers from bypassing the inspection layer	Requires accurate origin IP inventory
Remove unnecessary WebLogic proxy routes	Shrinks reachable backend surface	Does not fix vulnerable parsing in required routes
Deny public access to admin and internal WebLogic paths	Reduces high-impact paths	Route names vary by environment
Disable or tighten legacy protocols exposed to untrusted networks	Reduces adjacent WebLogic risk	CVE-2026-21962 itself is HTTP-scored
Increase OHS/Apache/IIS and WebLogic log retention	Improves investigation window	Does not prevent exploitation
Monitor backend data writes and config changes	Detects integrity impact	Requires application-aware telemetry
Segment web tier from backend services	Limits pivot paths	May require architecture changes

One practical hardening step is to make sure backend WebLogic listen ports are not reachable from the internet or broad user networks. This does not remediate CVE-2026-21962 in the proxy component, but it prevents attackers from pairing proxy-layer probing with direct attacks against other WebLogic services.

Another step is to review SSL and proxy header handling. Oracle’s documentation defines WLProxySSL, WLProxySSLPassThroughو SecureProxy. Misconfigured proxy header trust can confuse backend applications about scheme, host, client identity, or security context. That class of misconfiguration is not the same as CVE-2026-21962, but it can magnify the impact of any edge-layer weakness. (Oracle Documentation)

For organizations that use agentic or automated pentesting workflows, this is a good place to use automation carefully. The useful workflow is not “spray public PoCs at production.” It is controlled asset mapping, authorized configuration checks, version evidence collection, safe request replay in a staging environment, log correlation, and retesting after the CPU is applied. Penligent’s public site describes agentic workflows for authorized security testing, evidence-first results, tool orchestration, and report generation; those capabilities are relevant when a team needs to turn a CVE advisory into a scoped, repeatable validation process rather than a one-off scanner result. (بنليجنت)

Penligent also has a CVE-2026-21962 Hacking Labs page, which is directly related to this issue. Treat any detailed exploit-mechanics claims there, or in any third-party page, as material to validate against official Oracle/NVD facts and your own authorized lab. The link is still useful as a thematic resource for teams building an AI-assisted validation workflow around WebLogic proxy exposure, but the remediation baseline should remain Oracle’s CPU and your own asset evidence. (بنليجنت)

Incident response priorities

When CVE-2026-21962 appears in an environment, the response should not stop at “patch scheduled.” The official impact includes unauthorized access to critical data and unauthorized creation, deletion, or modification of accessible data. That means the response should include integrity review, not just vulnerability closure. (NVD)

A practical first-day plan:

Timeframe	الإجراء	الأدلة التي يجب الحفاظ عليها
First 4 hours	Identify all OHS, Apache, and IIS nodes with WebLogic Proxy Plug-in	Host list, module list, package inventory, owner
First 4 hours	Determine network exposure	Firewall rules, load balancer config, CDN/WAF origin list
First 8 hours	Confirm affected versions	Oracle inventory, plug-in package version, image build metadata
First 8 hours	Apply emergency access restrictions where possible	Change tickets, firewall diffs, load balancer policy
أول 24 ساعة الأولى	Patch highest-exposure nodes	Patch IDs, before/after version evidence, restart logs
أول 24 ساعة الأولى	Review suspicious web-tier requests	Access logs, WAF logs, IIS/OHS/Apache error logs
First 72 hours	Review backend data and admin changes	WebLogic logs, application audit logs, database audit logs
First week	Expand review to historical WebLogic CVEs and exposed protocols	Scanner results, T3/IIOP exposure map, patch history

Credential review is also appropriate. If the vulnerable proxy could expose or manipulate backend data, assume secrets passing through that tier may be at risk until logs and application architecture prove otherwise. That may include application session secrets, service credentials stored on the web tier, wallet files, API keys in configuration files, or credentials used by deployment automation.

For web-tier hosts, EDR review should focus on unexpected process creation from httpd, apache2, OHS-managed processes, IIS worker processes, and Java processes. Even though the official CVSS vector does not score availability and does not itself prove RCE, unexpected child processes are high-signal if present. The absence of child processes does not prove safety, because the confirmed impact can involve data access and modification.

For application teams, integrity review should focus on high-value business objects. Look for account changes, role updates, workflow approvals, payment configuration changes, file uploads, application deployments, and unusual create/delete/update operations during the suspected exposure window. A middleware bug can become a business incident if it changes data that downstream systems trust.

Related CVEs that make the risk easier to understand

CVE-2026-21962 should not be treated as an isolated oddity. It sits in a long pattern of middleware and Java enterprise vulnerabilities that become attractive because they are remotely reachable, easy to automate, and often left exposed after patches exist.

مكافحة التطرف العنيف	Why it is relevant	Attack condition	Risk lesson
CVE-2024-21182	Current CISA KEV attention around Oracle WebLogic in June 2026	Unauthenticated network access via T3/IIOP to affected WebLogic Server versions	Do not confuse it with CVE-2026-21962; both deserve patch discipline, but the affected components and protocols differ.
CVE-2020-14882 and CVE-2020-14883	Frequently referenced historical WebLogic Console exploitation chain	WebLogic Console exposure and vulnerable versions	Internet-facing WebLogic management surfaces remain attractive years after disclosure.
CVE-2017-10271	Older WebLogic WLS-WSAT vulnerability still seen in scanning ecosystems	Exposed vulnerable WLS-WSAT component	Old middleware flaws can remain in automated exploit traffic for years.
CVE-2021-44228	Log4Shell showed how Java middleware and dependency exposure can turn into mass validation	JNDI lookup in vulnerable Log4j versions under attacker-controlled input	Asset inventory, egress monitoring, and rapid safe validation matter as much as the patch itself.

CVE-2024-21182 is the most important comparison because it explains the June 2026 confusion. NVD describes CVE-2024-21182 as an Oracle WebLogic Server Core vulnerability affecting versions 12.2.1.4.0 and 14.1.1.0.0, exploitable by unauthenticated attackers with network access via T3 or IIOP, with confidentiality impact. CISA added a WebLogic vulnerability to KEV on June 1, 2026, and public reporting identified that KEV item as CVE-2024-21182 with a June 4 federal deadline. (CISA)

CVE-2026-21962 is different. It is tied to Oracle HTTP Server and the WebLogic Server Proxy Plug-in and is scored over HTTP. That means defenders should check the web tier, not only backend T3/IIOP exposure. The two vulnerabilities can coexist in a large Fusion Middleware estate, but the detection and remediation tasks are not identical. (NVD)

CloudSEK’s honeypot data is useful for the older CVE comparison. Its report says the honeypot saw attacks not only against CVE-2026-21962 but also against CVE-2020-14882, CVE-2020-14883, CVE-2020-2551, and CVE-2017-10271. That tells defenders to expect blended scanning: when one WebLogic issue gets attention, attackers often test several old WebLogic paths in the same pass. (CloudSEK)

Why scanners miss parts of this problem

Version scanners help, but CVE-2026-21962 exposes several scanner blind spots.

First, the vulnerable component may not identify itself through a clean HTTP banner. A load balancer, CDN, WAF, or custom error page may hide OHS, Apache, IIS, and the WebLogic proxy module. A scanner that depends on banners may report “unknown web server” while the vulnerable plug-in is still loaded behind the route.

Second, the front-end component and backend WebLogic domain may have separate owners. A WebLogic admin may patch managed servers while the infrastructure team forgets a web-tier plug-in package. Conversely, a web server team may update Apache while leaving the Oracle plug-in package untouched. Scanner results need ownership mapping.

Third, false negatives can come from route coverage. If only /app is proxied to WebLogic, testing / may reveal nothing. If the scanner does not discover the proxied paths, it may not exercise the vulnerable component at all.

Fourth, false positives can come from third-party payload copying. SANS ISC’s “AI slop” warning is a real operational issue: defenders will see requests that include WebLogic-like strings and command-like fragments, but some may be generated by tools guessing at an exploit rather than by working exploit code. Alert triage must separate scanner noise from credible post-request impact. (SANS Internet Storm Center)

A better validation approach combines four checks:

تحقق	Good evidence	Weak evidence
Product presence	Loaded module, plug-in binary, Oracle inventory, config reference	Generic WebLogic page title
Version status	Installed package/version evidence, patch record, image digest	HTTP banner only
Exposure	Firewall/load balancer path, successful authorized reachability test	Assumption that backend is internal
Impact hunt	Logs showing suspicious request plus backend effect	Single scanner alert without context

Web server and WAF log triage

Log triage should start before patching if possible, because emergency changes can rotate or overwrite useful evidence. Preserve raw logs first, then hunt in copies.

For Apache or OHS combined logs, begin with a broad parse:

LOG_DIRS="/var/log/httpd /var/log/apache2 /u01 /opt/oracle"
sudo find $LOG_DIRS -type f \( -iname '*access*log*' -o -iname '*error*log*' \) 2>/dev/null |
while read -r log; do
  sudo zgrep -Eai 'weblogic|bea_wls|wl-proxy|proxy-client-ip|x-forwarded|chunked|%2e|%2f|;|Nmap|libredtail' "$log" 2>/dev/null |
  awk -v file="$log" '{print file ":" $0}'
done > weblogic-proxy-hunt-raw.txt

Then aggregate by source IP, status code, user agent, and route. High request volume alone is not proof, but repeated malformed requests against WebLogic-like paths from hosting providers or scanners deserve escalation, especially if followed by successful 2xx or 3xx responses to proxied routes.

awk '
{
  ip=$1
  status=$(NF-1)
  agent=""
  for (i=12; i<=NF; i++) agent=agent" "$i
  key=ip" "status
  count[key]++
}
END {
  for (k in count) print count[k], k
}' weblogic-proxy-hunt-raw.txt | sort -nr | head -50

For IIS, export relevant W3C logs and search across URI stem, URI query, status, substatus, and user agent. Pay attention to sequences: a burst of 404s followed by a 200 on a proxied route may indicate path discovery or normalization probing.

$LogRoot = "C:\inetpub\logs\LogFiles"
$Patterns = "weblogic|bea_wls|wl-proxy|proxy-client-ip|x-forwarded|chunked|%2e|%2f|;|Nmap|libredtail"

Get-ChildItem $LogRoot -Recurse -Filter *.log |
  Select-String -Pattern $Patterns |
  ForEach-Object {
    [PSCustomObject]@{
      File = $_.Path
      LineNumber = $_.LineNumber
      Line = $_.Line
    }
  } | Export-Csv .\weblogic-proxy-hunt-iis.csv -NoTypeInformation

WAF logs need a different lens. A WAF may block malformed traffic before it reaches origin, which is good, but blocked WAF events still indicate external interest. Compare WAF events with origin logs. If the WAF shows blocks from an IP but the origin later shows direct requests from the same IP or user agent, the origin may be reachable outside the WAF path.

Backend verification after suspicious traffic

After suspicious front-end traffic is identified, backend verification should answer whether the request reached WebLogic and whether it changed anything.

Start with WebLogic access logs and application logs around the same timestamp. Correlate by source IP, forwarded IP, request ID, session ID, path, and user agent. If the front-end injects or forwards request IDs, use them. If not, compare narrow time windows.

Then review administrative events. Look for changes to users, groups, roles, deployments, data sources, JMS resources, startup classes, certificates, wallets, or application configuration. WebLogic administration changes should have a known operator, a ticket, and a deployment record. Unknown changes after suspicious proxy-layer traffic should be treated as incident evidence.

Database and application audit logs are equally important. Because the official impact includes unauthorized creation, deletion, or modification of critical data, a clean operating-system review is not enough. A successful abuse path may produce no shell, no malware, and no obvious crash. The incident may be a fraudulent data change through a route the proxy exposed incorrectly.

For critical systems, consider targeted data integrity checks:

-- Example pattern only. Adapt table names and fields to the application.
-- Look for high-risk business changes during the suspected window.

SELECT actor_id,
       action_type,
       object_type,
       object_id,
       source_ip,
       user_agent,
       created_at
FROM audit_event
WHERE created_at BETWEEN TIMESTAMP '2026-01-20 00:00:00'
                    AND TIMESTAMP '2026-02-05 00:00:00'
  AND action_type IN ('CREATE', 'UPDATE', 'DELETE', 'ROLE_CHANGE', 'APPROVE', 'EXPORT')
ORDER BY created_at DESC;

If application audit tables do not store source IP, forwarded IP, or request IDs, treat that as a security debt item. Proxy-layer vulnerabilities are much harder to investigate when backend events cannot be tied to edge requests.

Patching and retesting checklist

A practical patch closure record for CVE-2026-21962 should include more than a screenshot of a vulnerability scanner.

Closure item	Required evidence
Affected asset list	Hostname, IP, environment, owner, front-end product, plug-in type
Version evidence before patch	Oracle inventory, package record, plug-in binary metadata, image digest
Exposure classification	Internet, partner, VPN, internal, restricted load balancer only
Patch applied	Oracle CPU or patch identifier, change ticket, timestamp
Version evidence after patch	Same evidence type as before patch
Service restart or reload	OHS/Apache/IIS restart logs, health check results
Regression test	Business route validation, proxied path validation, backend health
Compensating controls	Firewall/WAF/load balancer changes if patch delayed
Log review	Time window, sources reviewed, findings
Retest	Authorized scanner or manual inventory confirmation
Residual risk	Unpatched systems, unsupported versions, vendor-owned systems

Unsupported versions require special handling. Oracle notes in the CPU page that patches are provided only for product versions covered under Premier Support or Extended Support, and that earlier versions may also be affected even if not tested. For unsupported systems, the realistic options are upgrade, isolate, retire, or obtain vendor-specific support. “Not listed” is not the same as “safe” when a product release is out of support. (أوراكل)

The CISA KEV confusion, CVE-2024-21182 versus CVE-2026-21962

The June 2026 news cycle created a common mistake: a current CISA KEV deadline for Oracle WebLogic was described alongside the CVSS 10.0 WebLogic proxy bug, making it sound like CVE-2026-21962 had a June 4 federal patch deadline. The better reading is:

البند	CVE-2024-21182	CVE-2026-21962
Product area	Oracle WebLogic Server Core	Oracle HTTP Server and WebLogic Server Proxy Plug-in
Protocol in public record	T3, IIOP	HTTP
CVSS score	7.5 in NVD text	10.0
Main impact	السرية	Confidentiality and integrity
CISA KEV June 2026 attention	Yes, based on public reporting and CISA alert	Not the June 4 KEV item
Operational takeaway	Patch exposed WebLogic Server Core risk, especially T3/IIOP paths	Patch and inventory web-tier proxy plug-in exposure

NVD describes CVE-2024-21182 as affecting Oracle WebLogic Server 12.2.1.4.0 and 14.1.1.0.0, exploitable without authentication via T3 and IIOP, with unauthorized access to critical or complete WebLogic-accessible data. Public reports on June 2, 2026, said CISA added CVE-2024-21182 to KEV and instructed federal agencies to patch by June 4. (NVD)

For defenders, the right response is not to choose one. Mature teams should patch both where applicable. But reporting, ticketing, and executive communication should keep the CVEs separate because the assets, protocols, logs, and control owners differ.

Common mistakes

The first mistake is patching WebLogic Server while forgetting the front-end plug-in. CVE-2026-21962 is about Oracle HTTP Server and the WebLogic Server Proxy Plug-in. A backend WebLogic patch record may not prove the edge component is fixed.

The second mistake is trusting the WAF as proof of remediation. A WAF may reduce exploitability, and WAF logs may provide useful detection, but the vulnerable component remains vulnerable until patched. Origin bypass is common in real environments because old DNS records, direct IP exposure, partner allowlists, or misconfigured load balancers can leave the web tier reachable outside the intended path.

The third mistake is treating public exploit code as the source of truth. CloudSEK’s report supports the existence of automated attempts, while SANS ISC cautions that some observed payloads may be AI-generated nonsense. Both facts can be true. Use public payloads for hunting hypotheses, not for official risk definitions. (CloudSEK)

The fourth mistake is focusing only on RCE. The official impact for CVE-2026-21962 is confidentiality and integrity. If the incident team only looks for shells, reverse connections, or crashed processes, it may miss unauthorized data access or modification.

The fifth mistake is closing the ticket without backend review. Because scope is changed and backend data may be affected, closure should include a review of proxied applications, administrative changes, sensitive writes, and high-value data access.

الأسئلة الشائعة

Is CVE-2026-21962 a WebLogic Server vulnerability or a proxy plug-in vulnerability?

• CVE-2026-21962 affects Oracle HTTP Server and the Oracle WebLogic Server Proxy Plug-in, including the plug-in for Apache HTTP Server and the plug-in for IIS.
• It is related to WebLogic deployments because the proxy plug-in forwards HTTP traffic to backend WebLogic Server instances or clusters.
• Do not limit inventory to backend WebLogic managed servers. Check OHS, Apache, IIS, plug-in binaries, and proxy configuration files.
• Oracle and NVD list affected versions as 12.2.1.4.0, 14.1.1.0.0, and 14.1.2.0.0, with the IIS plug-in note limited to 12.2.1.4.0. (NVD)

Is CVE-2026-21962 in CISA KEV with a June 4, 2026 deadline?

• The June 4, 2026 federal remediation deadline reported in the WebLogic news cycle corresponds to CVE-2024-21182, not CVE-2026-21962.
• CVE-2024-21182 is a WebLogic Server Core vulnerability involving T3 and IIOP access.
• CVE-2026-21962 is the CVSS 10.0 Oracle HTTP Server and WebLogic Server Proxy Plug-in vulnerability scored over HTTP.
• The two issues are related by Oracle WebLogic ecosystem risk, but they should not be merged in tickets, dashboards, or executive summaries. (CISA)

Does CVE-2026-21962 mean attackers automatically get remote code execution?

• Oracle and NVD confirm unauthenticated HTTP network exploitation with high confidentiality and integrity impact.
• The official CVSS vector lists availability impact as none and does not provide public root-cause exploit mechanics.
• Some third-party reports describe possible RCE, path traversal, header manipulation, or access-control bypass patterns.
• Defenders should patch urgently regardless of the RCE label, but should avoid writing “confirmed RCE” unless their source or internal validation supports that claim. (NVD)

What should I check first in my environment?

• Find every Oracle HTTP Server, Apache HTTP Server, and IIS node that may load a WebLogic proxy module or forwarding plug-in.
• Search for configuration references such as WLSRequest, WebLogicHost, WebLogicPort, WebLogicCluster, PathTrim, WLProxySSLو SecureProxy.
• Confirm the plug-in version or patch level using package records, Oracle inventory, image metadata, or vendor documentation.
• Prioritize internet-facing and partner-facing web-tier nodes before internal-only systems.

Can WAF rules or firewall restrictions replace the Oracle patch?

• No. WAF and firewall controls can reduce exposure, but they do not fix the vulnerable component.
• Use network restrictions when patching requires a change window, especially to limit access to trusted load balancers or VPN ranges.
• Preserve WAF and origin logs because blocked requests may indicate active targeting.
• Apply the Oracle CPU or vendor-supported patch path as the primary remediation. (أوراكل)

What logs matter most for investigation?

• Review OHS, Apache, IIS, WAF, CDN, and load balancer logs for suspicious request patterns around proxied WebLogic routes.
• Review WebLogic access logs and application audit logs for backend routes reached without expected session context.
• Review database and business audit logs for unauthorized create, update, delete, approval, export, or role-change events.
• Review EDR telemetry for unexpected child processes from web server, IIS worker, OHS, or Java processes, but do not rely only on process execution indicators.

Why are old WebLogic CVEs still relevant when investigating CVE-2026-21962?

• Attackers often scan for multiple WebLogic vulnerabilities in one pass.
• CloudSEK’s WebLogic honeypot observed activity against CVE-2026-21962 as well as older WebLogic flaws such as CVE-2020-14882, CVE-2020-14883, CVE-2020-2551, and CVE-2017-10271.
• When one WebLogic CVE becomes popular, defenders should check the broader middleware exposure surface, including console exposure, T3/IIOP, WLS-WSAT, old plug-ins, and unsupported Fusion Middleware versions. (CloudSEK)

Closing assessment

CVE-2026-21962 deserves urgent treatment because it sits at the HTTP edge of WebLogic deployments and has the worst possible official severity score. The right response is not panic, and it is not blind trust in public PoCs. The right response is disciplined: identify every OHS, Apache, and IIS WebLogic proxy surface; confirm affected versions; patch through Oracle’s January 2026 CPU path; restrict exposure while patching; preserve logs; and investigate confidentiality and integrity impact behind the proxy.

The most useful question for defenders is not “Can we find a working exploit online?” It is “Which HTTP-facing proxy components can reach critical WebLogic-backed data, and can we prove they are patched?” That question leads to the work that actually reduces risk.