← Back to Feed CACHED · 2026-10-07 00:29:02 · CACHE_KEY CVE-2026-60206
CVE-2026-60206 · CWE-306 · Disclosed 2026-07-21

Oracle WebLogic Server Core SAML Authentication Bypass

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

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.

"WebLogic trusts unsigned SAML assertions next to signed ones — one POST to /saml2/sp/acs forges admin."
02 · The Attack Path

5 steps from start to impact.

STEP 01

Discover WebLogic + SAML endpoints

The attacker fingerprints WebLogic via HTTP headers (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.
Conditions required:
  • Network access to WebLogic HTTP port (typically 7001/7002)
Where this breaks in practice:
  • Many WebLogic instances are internal-only behind firewalls
  • Shodan shows only ~1,600 internet-facing instances globally
Detection/coverage: Shodan/Censys dorks for WebLogic fingerprints; WAF logs for sequential probing of /saml2/ paths
STEP 02

Confirm SAML SSO is active

The attacker sends a test request to the ACS endpoint. If SAML 2.0 SSO is not configured in the WebLogic Security Realm, the endpoint returns a 404 or error — the chain stops dead. The PoC tools include a --detect safe-check mode that validates SAML availability without triggering exploitation signatures.
Conditions required:
  • SAML 2.0 SSO must be configured and active on the target WebLogic instance
Where this breaks in practice:
  • 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
Detection/coverage: SAML endpoint access logs; unusual HTTP POSTs to ACS URIs from non-IdP source IPs
STEP 03

Craft XSW SAML response

Using the PoC tooling (Debajyoti0-0 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.
Conditions required:
  • Knowledge of admin username (defaults to weblogic)
  • Access to one of the two public PoC frameworks
Where this breaks in practice:
  • Minimal — PoC automates all payload generation
  • Default admin username weblogic is well-known
Detection/coverage: SAML assertion structure analysis; alerts on responses containing multiple assertions or unsigned assertions
STEP 04

Submit forged assertion to ACS endpoint

A single HTTP POST to /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.
Conditions required:
  • Successful payload from step 3
Where this breaks in practice:
  • None — single HTTP request, no rate limiting on SAML endpoints by default
Detection/coverage: Session creation events for weblogic user without corresponding IdP-side authentication; SAML assertion structure anomalies in WebLogic audit logs
STEP 05

Full admin takeover + scope change pivot

With a valid admin session, the attacker deploys malicious WAR files via the WebLogic console, manipulates JNDI bindings, accesses all deployed application configurations and credentials, and pivots to connected backend systems — databases, message queues, Oracle SOA composites, and potentially Oracle Identity/Access Manager if co-deployed. The CVSS scope change reflects that compromise extends well beyond the WebLogic instance itself.
Conditions required:
  • Valid admin session from step 4
Where this breaks in practice:
  • None
Detection/coverage: WAR deployment audit logs; JNDI configuration change alerts; anomalous admin console activity from unexpected source IPs; file integrity monitoring on WebLogic domains
03 · Compensating Control

1
CRITICAL 9.3→HIGH 6.5
SEVERITY REDUCED
Restrict SAML ACS endpoints to IdP source IPs — Deploy WAF rules or network ACLs to restrict /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.
2
CRITICAL 9.3→IGNORE 0.0
SEVERITY REDUCED
Disable SAML SSO on non-production instances — If SAML federation is not actively required on dev, test, staging, or internal-only WebLogic domains, disable the SAML 2.0 Service Provider configuration in the WebLogic Security Realm → Providers → Authentication. Deploy within 3 days. Eliminates the vulnerability entirely on those instances — no SAML endpoint, no attack surface.
3
CRITICAL 9.3→HIGH 7.5
SEVERITY REDUCED
Deploy SAML assertion structure monitoring — Configure WebLogic audit logging (Security Audit Framework) and SIEM correlation rules to alert on: SAML responses containing multiple assertions, unsigned assertions alongside signed ones, NameID values not matching expected IdP-provisioned identities, and session creation for privileged users without corresponding IdP authentication events. Deploy within 3 days. Does not prevent exploitation but enables detection within minutes.
4
CRITICAL 9.3→IGNORE 0.0
SEVERITY REDUCED
Apply Oracle July 2026 CPU patches — Apply the version-specific PSU patches (39638312 / 39638182 / 39596645 / 39637038) per Oracle's Critical Patch Update. This is the definitive fix — corrected implementations bind identity extraction to the verified assertion and reject responses containing unverified assertions. Apply within 90 days per noisgate remediation SLA (CRITICAL). Test in staging first; WebLogic PSUs occasionally require WLS restart.
What doesn't work
  • 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.
04 · Intelligence Metadata

The supporting signals.

In-the-wild exploitationNot 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-conceptMultiple 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.
EPSS0.43% (0.00432), ~35th percentile — low absolute probability but expected to rise given PoC availability and middleware target value
KEV statusNot listed as of 2026-10-07
CVSS vectorCVSS: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 versionsOracle 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 versionsOracle 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.
Disclosed2026-07-21 (Oracle July 2026 Critical Patch Update, which addressed 1,449 patches across 334 products)
ResearcherNot publicly attributed. Reported through Oracle's security vulnerability reporting program.

Sources.

  1. Oracle July 2026 Critical Patch Update
  2. NVD — CVE-2026-60206
  3. Rapid7 — CVE-2026-60206
  4. SecurityOnline — CVE-2026-60206 Analysis
  5. CyCognito — WebLogic July 2026 CPU Emerging Threat
  6. Debajyoti0-0 PoC (GitHub)
  7. tc4dy Exploit Framework (GitHub)
  8. Qualys — Oracle July 2026 CPU Review
05 · The Call

Final Verdict
= UNCHANGED to CRITICAL (9.3/10)

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.

06 · Verification

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.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/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