miniOrange SAML SSO EUVD-2026-48429

Exploitation requires that the target WordPress site has the miniOrange SAML Single Sign On - SSO Login plugin (version ≤ 5.4.4) installed and active as a SAML service provider with SP-initiated or IdP-initiated login enabled, so that the plugin's mo_saml_validate_signature() code path processes attacker-submitted SAMLResponse data. The attacker must know or guess a valid NameID/username for an existing account (administrator usernames are frequently enumerable), and must craft a signature value malformed enough to make openssl_verify() return -1 rather than 0. Limiting factors: the plugin must be present and configured for SAML login (not a default WordPress feature), and the targeted account must already exist. Beyond that there are no authentication, privilege, or user-interaction requirements - it is remotely reachable against any affected, configured installation.

The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H = 9.8) is internally consistent with the description: fully remote, no privileges, no user interaction, and full compromise of the targeted account up to administrator. This is a genuine high-priority issue rather than a high-CVSS-but-low-real-risk case, because the exploit primitive is simple and deterministic - an attacker only needs to force openssl_verify() to error out with a malformed signature, which requires no secrets or brute force. No EPSS score, KEV listing, or SSVC decision data was provided, so probabilistic exploitation signals cannot be quantified here; the assessment rests on the code-level analysis from Wordfence rather than observed exploitation. No KEV means it is not confirmed as actively exploited, and no POC was supplied, but the trivial and well-documented nature of the bug means weaponization would be low-effort. The one prerequisite that tempers universal risk is that the plugin must actually be installed and configured as a SAML service provider.

An attacker locates a WordPress site using the miniOrange SAML SSO plugin and submits a crafted SAMLResponse to the plugin's ACS/login endpoint containing a NameID mapping to an administrator account and a deliberately malformed signature value. The malformed signature causes openssl_verify() to return -1 (an OpenSSL processing error), which the plugin misreads as valid, and wp_set_auth_cookie() is called for the admin account. Given AV:N/AC:L/PR:N/UI:N this requires no authentication, no user interaction, and only a single HTTP request; no public POC was identified at time of analysis but the technique is fully described.