CVE-2026-60206: Unauthenticated SAML Authentication Bypass in Oracle WebLogic Server

Oracle WebLogic Server includes support for Single Sign-On (SSO) configurations utilizing the Security Assertion Markup Language (SAML) v2.0 standard. This functionality is handled by the WebLogic Core Security framework, specifically within the SAML Identity Asserter and SAML Authenticator modules. These components process inbound SAML assertions to authenticate users against the active security realm.

The vulnerability identified as CVE-2026-60206 exposes a critical flaw in how these authentication modules process XML-based SAML responses. An unauthenticated attacker with network access to the WebLogic Server can send a specially crafted HTTP POST request to vulnerable Assertion Consumer Service (ACS) endpoints. This action bypasses authentication checks and allows the attacker to hijack or forge user sessions.

Successful exploitation results in the creation of a valid administrative session, typically mapped to the default administrator account. This access bypasses local directories or external identity providers completely, giving the attacker administrative privileges over the WebLogic Console.

The core issue resides in logical discrepancies during the validation and parsing of SAML XML payloads. The WebLogic SAML implementation utilizes two separate systems to process incoming XML documents: a cryptographic signature verification engine and a business logic DOM parser. These systems do not share a synchronized view of the XML Document Object Model (DOM).

The cryptographic engine searches the XML document for the element referenced by the <ds:Reference> URI attribute. It validates the digital signature over that specific XML element using the configured Identity Provider (IdP) public key. Once validated, the engine marks the validation step as successful.

However, the business logic parser processes the validated DOM to extract user attributes and establish identity. Instead of strictly retrieving the validated XML element, the parser queries the DOM sequentially or uses loose XPath expressions. An attacker can exploit this discrepancy by structuring the XML to present a signed assertion for signature validation while placing an unsigned, modified assertion in the path read by the business logic parser.

To understand the technical breakdown, we examine the logic responsible for processing the SAML assertion. The vulnerable implementation reads the assertion from the XML document using a loose node retrieval pattern.

// Vulnerable parsing logic
Element responseElement = parseXMLDocument(samlResponseString);
NodeList assertionList = responseElement.getElementsByTagName("saml2:Assertion");
 
// SECURITY FLAW: Retrieves the first assertion node regardless of signature validation
Element identityAssertion = (Element) assertionList.item(0);
String username = extractNameID(identityAssertion);
 
// Cryptographic check occurs independently
boolean isSignatureVerified = verifySignature(responseElement);
if (isSignatureVerified) {
    // Authenticates the username extracted from the first assertion node
    establishSession(username);
}

The vulnerability is resolved by linking the cryptographic signature verification directly with the assertion element used for identity extraction. The updated logic validates that the exact node being read for user identity is the node that holds the validated signature.

// Secure parsing logic
Element responseElement = parseXMLDocument(samlResponseString);
Element verifiedAssertion = verifyAndGetSignedAssertion(responseElement);
 
if (verifiedAssertion != null) {
    // Extract identity only from the verified XML element
    String username = extractNameID(verifiedAssertion);
    establishSession(username);
} else {
    throw new SecurityException("No verified assertion found");
}

Exploitation of CVE-2026-60206 requires the attacker to submit a modified SAML response to the WebLogic ACS endpoint. This endpoint is typically located at /saml2/sp/acs/post or /saml2/acs. The attacker must capture a valid SAML response payload or craft one that structurally mimics a legitimate assertion.

The attack employs XML Signature Wrapping (XSW). The attacker duplicates the <saml2:Assertion> block. The first block is modified to contain the target username, such as weblogic, and its signature is removed. The second block contains the original, validly signed assertion, which remains untouched to satisfy the cryptographic validator.

When the application processes the multi-assertion XML, the signature validation routine verifies the signature on the second block. Concurrently, the login processing logic extracts the identity from the first block. This establishes an administrative session, returning a valid session cookie to the attacker.

An attacker who successfully exploits this vulnerability gains full administrative privileges on the Oracle WebLogic Server. This level of access compromises the entire middleware environment, including all deployed applications and connected resources.

With administrator access, the attacker can deploy malicious Web Application Archives (WAR) or Enterprise Archives (EAR). These archives can contain web shells, enabling remote command execution on the host operating system under the privileges of the WebLogic process user.

Furthermore, the attacker can access the Java Naming and Directory Interface (JNDI) tree, extract database credentials, intercept sensitive business data, and pivot to internal database networks. This high-impact chain is reflected in the CVSS v3.1 score of 9.9.

The primary remediation strategy is the application of the Oracle July 2026 Critical Patch Update (CPU). This patch updates the WebLogic XML parser and security frameworks to enforce strict XML schema validation and prevent signature wrapping techniques.

If immediate patching is not possible, organizations should implement network-level access controls. Restrict access to the WebLogic Administration Port (default 7001 or 7002) to trusted IP addresses only, preventing external exposure of administrative and SAML endpoints.

Additionally, Web Application Firewalls (WAF) can be configured to inspect SAML responses. Rules should detect the presence of multiple <saml2:Assertion> elements or XML comments nested within <saml2:NameID> blocks, blocking requests that exhibit these anomalous structures.