Skip to content

Oracle WebLogic Proxy Plug-in Improper Access Control KEV (CVE-2026-21962)

Why this is worth an operator page. CVE-2026-21962 is a CISA KEV entry (added 2026-08-24, catalog 2026.08.24) for improper access control (CWE-284) in Oracle HTTP Server / the Oracle WebLogic Server Proxy Plug-in (Apache HTTP Server and IIS variants). NVD rates it CVSS 3.1 10.0 with vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N — unauthenticated, network-reachable, no user interaction, changed scope. The affected plug-in is a reverse proxy that fronts WebLogic, so it sits on the perimeter and is a high-value recon target. This page gives a safe, replayable way to identify the component, fingerprint the version, and characterize the access-control boundary without touching production data.

Product boundary and affected versions

  • Component: Oracle WebLogic Server Proxy Plug-in — reverse-proxy module deployed on the front-end web server so it can forward requests to a WebLogic backend and handle plug-in session/cookie logic.
  • CWE-284 (Improper Access Control) on the HTTP interface; scope change means the flaw can cross a trust boundary (e.g., from a plug-in/session-management context into data the plug-in should not manage).
  • Affected versions (per Oracle CPU Jan 2026):
  • Apache HTTP Server plug-in: 12.2.1.4.0, 14.1.1.0.0, 14.1.2.0.0
  • IIS plug-in: 12.2.1.4.0 (per the NVD reference note)
  • Remote exploit without authentication: Yes. CVSS 10.0. C:H / I:H / A:N.

Note 1 (Oracle CPU Jan 2026): The Oracle patch note for this CVE is deliberately terse ("See Note 1") and Oracle withholds the precise exploit mechanics. Treat the vendor disclosure as authoritative for which versions are affected and for the fact that an unauthenticated, scope-changing access-control flaw exists — but do not infer specific vulnerable request shapes from secondary sources.

Why the public "exploit" is low-confidence

The widely-circulated public reference for this CVE is a GitHub repository/issues thread that the author frames as a dispute over "fake PoCs" — i.e., the ecosystem is littered with unverified, copy-paste "exploit" scripts and the original author is publicly disputing their validity. As of this scan the repository returned 404 on the live GitHub API and only a cached (Wayback) copy of a dispute thread is retrievable. Treat every public "exploit" for this CVE as untrusted until you independently validate the boundary in an authorized lab. Do not run third-party PoC code against a target; it is the most likely source of malware, exfiltration, and false confidence.

What you can safely confirm (authorized targets only)

This is a characterization workflow, not an exploitation workflow. The goal is to prove the component is present and to map the trust boundary, using inert probes.

1. Confirm the plug-in is present

The plug-in exposes distinctive behavior in how it forwards/terminates requests to a WebLogic backend. Look for it in your recon:

  • httpx/nuclei fingerprinting for WebLogic front-ends (headers, error pages, cookie names).
  • The IIS/Apache plugin commonly emits/reads plug-in-specific headers and cookies around session stickiness.
  • Web server banners (Server: / X-Powered-By:) and any plug-in build/version markers in responses or error output.
# Enumerate front-end web servers and their plug-in/cookie markers
httpx -l web-frontends.txt -title -tech-detect -content-length -server -cookie -silent -json > httpx_webfront.json
nuclei -l web-frontends.txt -t technologies/ -t misconfiguration/ -silent -json > nuclei_webfront.json

2. Fingerprint the version / build

Version identification matters because only the specific plug-in builds above are in scope. Capture:

  • Server, X-WebLogic-Plugin-*, Set-Cookie, and any custom plugin headers.
  • Distinctive 4xx/5xx error bodies that reveal the plug-in's internal error handling.
  • Any exposed version or build endpoints.
# Capture the full response surface for later boundary analysis (lab / authorized target only)
curl -sk -D - https://TARGET/ -o /dev/null -w "HTTP %{http_code} | TTFB %{time_starttransfer}\n"

Label inference. If you cannot get a definitive build number, record the fingerprint evidence (headers, cookies, error bodies) and note that version confirmation is inferred, not confirmed. This matters for scoping.

3. Characterize the access-control boundary (no data access)

The flaw is an improper access control with changed scope. A safe, replayable way to characterize the boundary without touching real data is to probe session/plug-in management surfaces for authorization behavior — not to read or modify real objects:

  • Identify which routes/parameters the plug-in uses for session stickiness or plug-in state (e.g., specific path prefixes, cookies, or headers it manages).
  • Test route-level authorization gating: does the plug-in enforce auth on its own management/cookie endpoints the same way the backend does?
  • Use synthetic/owned canary objects (a lab WebLogic with a test user, or a mock backend) to observe whether an unauthenticated request to a plug-in-managed path produces a scope-crossing response (i.e., the plug-in acts on a resource outside the requester's trust boundary).
# Lab canary: create a dummy user in a lab WebLogic, then check whether the
# plug-in's session-management path exposes/acts on it without authentication.
# (Replace with your owned lab backend; do NOT point at production data.)
curl -sk "https://LAB-WEBLOGIC/weblogic/..." -H "Cookie: <plumbing cookie>" -D - -o /dev/null

Validation boundary: A confirmed boundary mismatch is inert evidence — a header/cookie/response diff showing the plug-in crossed a trust boundary on a canary object. Stop there. Do not read, modify, or delete real data; do not attempt to reach the WebLogic backend's actual sessions, JNDI, or admin consoles through this; and do not deploy a public "exploit" payload.

Evidence bundle (what to capture for the report)

- Fingerprint: Server/X-Powered-By/X-WebLogic-Plugin-* headers, plug-in cookies, error bodies
- Version/build: confirmed build number, or "inferred" + supporting headers
- Boundary test: request → response diff on a canary/plug-in-management path showing scope-crossing
- Authorization matrix: which plug-in paths enforce auth vs. which do not
- Scope note: whether the mismatch reaches across a trust boundary (changed scope per CVSS)
- Negative controls: same probes against a patched/absent front-end to rule out false positives

Reporting heuristic

For a bug-bounty or red-team report, frame it as: "Reverse-proxy front-end (Oracle WebLogic Proxy Plug-in vX.Y.Z) fails to enforce access control on [plug-in management/session surface]; an unauthenticated request can [cross trust boundary / act on out-of-scope canary object], consistent with CVE-2026-21962 (CWE-284, CVSS 10.0, changed scope, KEV)." Include the canary evidence bundle. Do not attach or reference public "exploit" scripts as your proof — your own boundary diff is the proof.

Reviewed but not promoted here

  • Public "exploit" repository / GitHub dispute thread: low-confidence, publicly disputed as fake PoCs; 404 on live GitHub API. Reviewed, not used as evidence.
  • Vendor "Note 1" mechanics: Oracle withholds details; nothing beyond the version list and "unauthenticated, scope-changing" is confirmable from the primary disclosure. Not inferred further.

Safety

  • Authorized, in-scope targets only. This component fronts a production WebLogic; unauthenticated probing can be noisy and may trip egress/IDS. Coordinate with the asset owner.
  • No production data access. Use canaries. Never read, modify, or delete real sessions, users, or business data to "prove" the boundary.
  • Do not run untrusted public PoC code. The public exploit landscape for this CVE is explicitly disputed as fake/malicious.
  • No RCE assumption. The disclosure is an access-control flaw, not RCE. Do not extrapolate to code execution or JNDI/weblogic admin access without independent, lab-validated proof.

Sources: CISA KEV catalog · NVD CVE-2026-21962 · Oracle CPU January 2026