September 7, 2026

CVE-2026–19842: Deconstructing the SAML Trust Anchor Overwrite in WordPress

Introduction

By Suhayb Ahmed

2 min read

Introduction

Authentication protocols like SAML 2.0 form the backbone of Enterprise Single Sign-On (SSO) integrations. However, implementing XML signature validation and trust management correctly requires extreme precision.

During a recent code audit of the popular miniOrange SAML 2.0 Single Sign-On plugin for WordPress (10,000+ active installations), I identified a high-severity authentication bypass vulnerability tracked as CVE-2026–19842 (CVSS 8.8 / 9.1 depending on the vector).

This vulnerability allows an unauthenticated, remote attacker to overwrite the site's SAML certificate store and eventually achieve full Administrator Account Takeover.

In this technical breakdown, we will analyze the underlying root cause in the source code and discuss how state mutation prior to validation leads to severe security risks.

Vulnerability Summary

  • CVE ID: CVE-2026–19842
  • Component: miniorange-saml-20-single-sign-on (WordPress Plugin)
  • Vulnerability Type: Authentication Bypass via Untrusted Key Import / Option Overwrite (CWE-287 / CWE-347)
  • Affected Versions: < 5.4.7 (Tested on 5.4.6)
  • Fixed Version: 5.4.7
  • Prerequisites: Unauthenticated / Remote

Root Cause Analysis: State Mutation Before Validation

The core vulnerability resides within the SAML login validation handler in class-mo-saml-login-validate.php.

When an HTTP POST payload containing a SAMLResponse hits the endpoint, the application extracts the X.509 certificate supplied inside the assertion.

1. The Pre-Validation Write

Notice the sequential execution flow in version 5.4.6 (lines 236–238):

// Extracting certificate from untrusted input
} elseif ( $assertion_signature_data ) {
    $saml_required_certificate = $assertion_signature_data['Certificates'][0];
}

// VULNERABLE: Database write occurs HERE
update_option( Mo_Saml_Sso_Constants::MO_SAML_REQUIRED_CERTIFICATE, $saml_required_certificate );

// Validation check happens AFTER the database has already been mutated
$saml_is_encoding_enabled = get_option( ... );
if ( ! $valid_signature ) {
    // Execution halts, but the DB modification persists!
}

What happens here?

  • The function retrieves the certificate directly from the unauthenticated payload.
  • It commits the certificate to the WordPress database via update_option().
  • Two lines later, it checks $valid_signature. While a signature mismatch correctly halts the user's login session, it fails to roll back the database option write.

2. The Promotion Vector

To assist administrators during initial IdP setup or certificate rotation, the plugin offered a built-in "Fix Issue" control (mo_saml_fix_certificate):

if ( 'mo_saml_fix_certificate' === $_REQUEST['option'] && check_admin_referer( 'mo_saml_fix_certificate' ) ) {
    // Reads the previously unauthenticated stored option
    $saml_required_certificate = get_option( Mo_Saml_Sso_Constants::MO_SAML_REQUIRED_CERTIFICATE );

    // Promotes it to the primary, trusted SAML signing certificate
    $saml_certificate    = maybe_unserialize( get_option( Mo_Saml_Options_Enum_Service_Provider::X509_CERTIFICATE ) );
    $saml_certificate[0] = Mo_SAML_Utilities::mo_saml_sanitize_certificate( $saml_required_certificate );

    update_option( Mo_Saml_Options_Enum_Service_Provider::X509_CERTIFICATE, $saml_certificate );
}

Although the administrative handler uses a CSRF nonce (check_admin_referer), the underlying data being promoted was planted in the database by an anonymous user during the initial unauthenticated request.

Exploit Architecture (High-Level Concept)

  • Unauthenticated Planting: An attacker submits a custom SAML response containing their own X.509 certificate. The server rejects the signature, but writes the certificate to mo_saml_required_certificate.
  • Administrator Interaction: The administrator encounters a certificate mismatch error state within the plugin interface (WPSAMLERR004). Clicking "Fix Issue" unknowingly promotes the attacker's certificate to saml_x509_certificate (the live trust anchor).
  • Full Takeover: With the attacker's certificate established as the trusted anchor, any subsequent SAML assertion signed by the attacker's corresponding private key is accepted as valid, granting immediate administrative access.

The Vendor Fix in 5.4.7

In version 5.4.7, the vendor completely removed the premature update_option() database call prior to signature validation and eliminated the mo_saml_fix_certificate auto-fix handler.

As noted by the vendor:

"The certificate received from the IDP did not match the one configured for the SP — it is untrusted, so it is only ever shown to the admin and never persisted to the DB."

Key Takeaways for Developers

  • Atomic Validation: Never modify state, write to databases, or update session flags until all cryptographic signatures and input assertions are fully validated.
  • Separation of Untrusted Data: Temporary diagnostic data extracted from unverified requests should remain transient (e.g., in-memory for the current request execution) rather than persisted into persistent options or database stores.

Responsible Disclosure Timeline

  • 2026–08–07: Patch released in version 5.4.7.
  • 2026–08–17: CVE-2026–19842 assigned and verified.
  • 2026–09–17: Functional Proof-of-Concept code release window.

Authored by Suhayb Ahmed