A bouncer who checks the VIP's ID but lets the stranger standing next to them walk right in
CVE-2026-60206 is a classic XML Signature Wrapping (XSW) flaw in Oracle WebLogic Server's SAML 2.0 Service Provider implementation. The server validates the *cryptographic signature* on one assertion but extracts the *identity* from a separate, unsigned assertion the attacker plants before it in the same SAML response. A single crafted HTTP POST to the assertion consumer service endpoint (/saml2/sp/acs) creates a valid weblogic administrator session — full console access, WAR deployment, JNDI manipulation, and arbitrary code execution. All supported versions are affected: 12.2.1.4.0, 14.1.1.0.0, 14.1.2.0.0, and 15.1.1.0.0.
Oracle's 9.9 CRITICAL with scope change is *largely justified*. The PR:L rating is generous to the defender — the actual exploit is effectively pre-auth since no valid credentials or IdP trust relationship is needed, only network access to the SAML endpoint. The one place the vendor score overshoots: SAML SSO is not configured by default. It requires deliberate federation setup with an identity provider. But the deployments that *do* run SAML tend to be the highest-value ones — production apps with enterprise SSO, Oracle Identity Manager, Oracle Access Manager — so this prerequisite concentrates risk on the targets that matter most. We adjust to 9.3 to reflect the configuration prerequisite while keeping the CRITICAL bucket intact.
5 steps from start to impact.
Discover WebLogic + SAML endpoints
X-Powered-By: Servlet, Server: WebLogic) and probes for SAML ACS endpoints at /saml2/sp/acs and /saml2/acs. Both public PoC frameworks automate this with Shodan API integration and concurrent mass scanning across target lists. The tc4dy framework supports 50+ threads and JSON/CSV output.- Network access to WebLogic HTTP port (typically 7001/7002)
- Many WebLogic instances are internal-only behind firewalls
- Shodan shows only ~1,600 internet-facing instances globally
/saml2/ pathsConfirm SAML SSO is active
--detect safe-check mode that validates SAML availability without triggering exploitation signatures.- SAML 2.0 SSO must be configured and active on the target WebLogic instance
- SAML SSO is NOT default-on — requires deliberate IdP federation setup
- Estimated <20% of WebLogic deployments use SAML; most use LDAP or built-in auth
Craft XSW SAML response
exploit.py or tc4dy framework), the attacker constructs a SAML 2.0 Response containing an unsigned assertion with NameID=weblogic placed before a validly signed assertion. Multiple attack variants are available: unsigned injection, XSW v1-v4 (namespace manipulation, enveloped signature manipulation, multiple assertion injection), NameID comment injection, and audience/conditions bypass. The combo mode chains all variants for maximum success probability.- Knowledge of admin username (defaults to
weblogic) - Access to one of the two public PoC frameworks
- Minimal — PoC automates all payload generation
- Default admin username
weblogicis well-known
Submit forged assertion to ACS endpoint
/saml2/sp/acs with the crafted SAML response. WebLogic's Core component validates the cryptographic signature on the legitimate assertion but maps the session identity from the unsigned attacker-controlled assertion due to a DOM parsing discrepancy between the signature verification engine and the business logic parser. A valid admin session cookie is returned.- Successful payload from step 3
- None — single HTTP request, no rate limiting on SAML endpoints by default
weblogic user without corresponding IdP-side authentication; SAML assertion structure anomalies in WebLogic audit logsFull admin takeover + scope change pivot
- Valid admin session from step 4
- None
/saml2/sp/acs and /saml2/acs to only your legitimate identity provider's IP ranges. This breaks step 1 of the attack path for all external attackers and most internal ones. Deploy within 3 days per noisgate mitigation SLA (CRITICAL). If your IdP is cloud-hosted (Okta, Azure AD), pin to the IdP's published egress IP ranges.- Generic WAF rules (OWASP CRS) — Standard ModSecurity/CRS rulesets do not inspect SAML assertion XML structure or detect XSW signature wrapping attacks. You need purpose-built rules targeting the ACS endpoint and SAML payload structure.
- Disabling T3/IIOP protocols — This mitigates the deserialization CVEs in the same July 2026 CPU (CVE-2026-60198, -60202, -60204) but has zero effect on CVE-2026-60206, which operates over standard HTTPS to the SAML endpoint.
- Network segmentation alone — If the SAML ACS endpoint must be browser-reachable for SSO to function (SP-initiated flow), segmenting WebLogic from untrusted networks will break SSO. You must combine segmentation with IdP IP pinning.
The supporting signals.
| In-the-wild exploitation | Not confirmed by CISA or major threat intel vendors as of 2026-10-07. One source (Mallory.ai) reports no wild exploitation observed. Not on CISA KEV. |
|---|---|
| Proof-of-concept | Multiple weaponized PoCs public. Debajyoti0-0/CVE-2026-60206 — Python, 7 attack modes (unsigned, xsw, nameid, audience, conditions, combo, replay). tc4dy/CVE-2026-60206-PoC-Exploit — Python + Bash, mass scanning (50+ threads), Shodan integration, Tor/proxy support, WAF evasion via User-Agent rotation. Both appeared within 3-4 days of disclosure. |
| EPSS | 0.43% (0.00432), ~35th percentile — low absolute probability but expected to rise given PoC availability and middleware target value |
| KEV status | Not listed as of 2026-10-07 |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H — Network attack vector, low complexity, low privilege (effectively pre-auth for SAML path), no user interaction, scope change, full confidentiality/integrity/availability impact |
| Affected versions | Oracle WebLogic Server 12.2.1.4.0, 14.1.1.0.0, 14.1.2.0.0, 15.1.1.0.0 (all currently supported branches) |
| Fixed versions | Oracle July 2026 CPU — PSU 39638312 (12.2.1.4.0), PSU 39638182 (14.1.1.0.0), PSU 39596645 (14.1.2.0.0), PSU 39637038 (15.1.1.0.0) |
| Exposure (Shodan) | ~1,600 internet-facing WebLogic instances globally (June 2026 data). Industry breakdown of vulnerable assets: Industrials 32%, Information Technology 29%, Consumer Discretionary 17%. SAML-configured subset is smaller. |
| Disclosed | 2026-07-21 (Oracle July 2026 Critical Patch Update, which addressed 1,449 patches across 334 products) |
| Researcher | Not publicly attributed. Reported through Oracle's security vulnerability reporting program. |
Sources.
Why this verdict
- SAML prerequisite narrows population but selects for value. SAML SSO is not default-on, reducing the vulnerable surface to an estimated ~15-20% of WebLogic installs. However, SAML-configured instances are disproportionately production-critical: enterprise SSO, Oracle Identity/Access Manager deployments, Oracle Fusion Applications middleware tiers. This is a -0.3 adjustment, not a tier change.
- Weaponized PoCs lower the exploitation bar to zero skill. Two full exploit frameworks with mass scanning (50+ threads), multiple attack modes (7 variants), Shodan integration, Tor support, and WAF evasion features are public on GitHub. Exploitation requires a single HTTP POST. No custom tooling needed. This is a -0.0 adjustment (already captured by AC:L in CVSS).
- Scope change delivers fleet-scale blast radius. WebLogic admin access → WAR deployment → RCE → pivot to all connected databases, message queues, identity stores, SOA composites. On Oracle Access Manager deployments, this is identity-tier compromise affecting every application federated through it.
- Role multiplier: WebLogic is canonically high-value middleware. (a) *Low-value role:* Dev/test WebLogic — chain succeeds if SAML configured, blast radius = single dev instance (LOW). (b) *Typical role:* Line-of-business app server — chain succeeds if SAML configured, blast radius = application data + connected backends (HIGH). (c) *High-value role:* Oracle Identity Manager, Oracle Access Manager, Oracle SOA Suite in production, PeopleSoft/Siebel middleware, banking transaction middleware — chain succeeds, blast radius = domain/fleet/identity-tier compromise. >10% of WebLogic installs serve identity infrastructure or production-critical middleware by definition. Verdict floor is CRITICAL.
- PR:L is effectively pre-auth on the SAML path. The CVSS PR:L reflects network access requirements, but the actual exploit sends a single unsigned SAML assertion — no valid credentials, tokens, or IdP trust relationship needed. The real-world attack complexity is lower than the CVSS vector suggests. This is a +0.3 upward adjustment, offset by the SAML prerequisite.
Why not higher?
The vendor's 9.9 already accounts for scope change and full CIA impact. The SAML SSO configuration prerequisite is a genuine narrowing not captured by CVSS — it excludes the majority of WebLogic instances from the vulnerable population. Not all internet-facing WebLogic servers are exploitable; only the SAML-configured subset is. A 10.0 would require true zero-prerequisite, default-on exposure.
Why not lower?
The deployment-role floor prevents a downgrade below CRITICAL. WebLogic with SAML configured is definitionally an identity-adjacent, production-critical tier — these are not sandbox instances. The weaponized PoCs with mass-scanning capability, the effectively pre-auth exploitation (single POST), and the scope-change blast radius (admin → RCE → pivot to identity stores and databases) make this exploitable at scale the moment an attacker finds an exposed SAML endpoint. No friction point in the chain after step 2 is sufficient to downgrade.
Crowdsourced verification payload.
Run this script on each WebLogic host as the Oracle middleware owner (e.g., oracle user). Invoke: bash check_cve_2026_60206.sh /path/to/oracle/middleware (e.g., bash check_cve_2026_60206.sh /u01/app/oracle/middleware). No root required. Checks WebLogic version, PSU level, and SAML SSO configuration status.
#!/usr/bin/env bash
# check_cve_2026_60206.sh — Detect CVE-2026-60206 exposure
# Usage: bash check_cve_2026_60206.sh <MW_HOME>
# Exit codes: 1=VULNERABLE, 0=PATCHED, 2=UNKNOWN
set -euo pipefail
MW_HOME="${1:-}"
if [[ -z "$MW_HOME" ]]; then
echo "Usage: $0 <MW_HOME>"
echo "Example: $0 /u01/app/oracle/middleware"
exit 2
fi
REGISTRY="$MW_HOME/inventory/registry.xml"
WLS_JAR="$MW_HOME/wlserver/server/lib/weblogic.jar"
PATCH_DIR="$MW_HOME/.patch_storage"
# --- Step 1: Detect WebLogic version ---
VERSION="unknown"
if [[ -f "$WLS_JAR" ]]; then
VERSION=$(java -cp "$WLS_JAR" weblogic.version 2>/dev/null | grep -oP '\d+\.\d+\.\d+\.\d+\.\d+' | head -1 || echo "unknown")
fi
if [[ "$VERSION" == "unknown" ]]; then
# Fallback: check registry.xml
if [[ -f "$REGISTRY" ]]; then
VERSION=$(grep -oP 'version="\K[0-9.]+' "$REGISTRY" | head -1 || echo "unknown")
fi
fi
echo "[*] WebLogic version detected: $VERSION"
# --- Step 2: Check if version is in affected range ---
AFFECTED_VERSIONS="12.2.1.4.0 14.1.1.0.0 14.1.2.0.0 15.1.1.0.0"
IS_AFFECTED=false
for v in $AFFECTED_VERSIONS; do
if [[ "$VERSION" == *"$v"* ]]; then
IS_AFFECTED=true
break
fi
done
if [[ "$IS_AFFECTED" == false ]]; then
echo "[+] PATCHED — WebLogic version $VERSION is not in the affected range."
exit 0
fi
echo "[!] Version $VERSION is in the affected range."
# --- Step 3: Check for July 2026 CPU PSU patches ---
FIXED_PSUS="39638312 39638182 39596645 39637038"
PATCHED=false
# Check via opatch
OPATCH="$MW_HOME/OPatch/opatch"
if [[ -x "$OPATCH" ]]; then
INSTALLED=$($OPATCH lspatches 2>/dev/null || echo "")
for psu in $FIXED_PSUS; do
if echo "$INSTALLED" | grep -q "$psu"; then
PATCHED=true
echo "[+] Found PSU patch $psu applied."
break
fi
done
else
echo "[?] OPatch not found at $OPATCH — checking patch_storage."
if [[ -d "$PATCH_DIR" ]]; then
for psu in $FIXED_PSUS; do
if ls "$PATCH_DIR" 2>/dev/null | grep -q "$psu"; then
PATCHED=true
echo "[+] Found PSU patch $psu in patch storage."
break
fi
done
fi
fi
if [[ "$PATCHED" == true ]]; then
echo "[+] PATCHED — July 2026 CPU PSU is applied."
exit 0
fi
# --- Step 4: Check SAML SSO configuration ---
echo "[!] No July 2026 CPU PSU detected. Checking SAML SSO configuration..."
SAML_CONFIGURED=false
DOMAIN_DIRS=$(find "$MW_HOME" -name "config.xml" -path "*/config/config.xml" 2>/dev/null || true)
for cfg in $DOMAIN_DIRS; do
if grep -qiE 'saml|SAMLAuthenticator|SAMLIdentityAsserter|saml2' "$cfg" 2>/dev/null; then
SAML_CONFIGURED=true
echo "[!] SAML configuration found in: $cfg"
fi
done
# Also check security realm config
for cfg in $DOMAIN_DIRS; do
REALM_DIR=$(dirname "$cfg")/security
if [[ -d "$REALM_DIR" ]]; then
if grep -rqiE 'saml|SAMLAuthenticator|SAMLIdentityAsserter' "$REALM_DIR" 2>/dev/null; then
SAML_CONFIGURED=true
echo "[!] SAML security provider found in: $REALM_DIR"
fi
fi
done
if [[ "$SAML_CONFIGURED" == true ]]; then
echo ""
echo "============================================"
echo " VULNERABLE — CVE-2026-60206"
echo " Version: $VERSION (affected)"
echo " July 2026 CPU: NOT applied"
echo " SAML SSO: CONFIGURED (exploitable)"
echo "============================================"
exit 1
else
echo ""
echo "============================================"
echo " VULNERABLE (reduced risk) — CVE-2026-60206"
echo " Version: $VERSION (affected)"
echo " July 2026 CPU: NOT applied"
echo " SAML SSO: NOT detected (not currently exploitable)"
echo " ACTION: Patch anyway — SAML may be enabled later"
echo "============================================"
exit 1
fi