deniz.in

Markets

Weather

Loading weather

· via dev.to (home feed)

miniOrange SAML SSO flaws let attackers forge admin logins on WordPress sites

Two signature-verification flaws in the miniOrange SAML SSO plugin let attackers log in as any WordPress user without a password, and Patchstack says admin cookies have already been stolen in the wild.

miniOrange SAML SSO flaws let attackers forge admin logins on WordPress sites

What happened

According to a Patchstack disclosure summarized in a dev.to write-up, with related coverage from BleepingComputer and entries in NVD, the miniOrange SAML 2.0 Single Sign On plugin for WordPress contains two critical flaws that bypass signature verification on incoming SAML responses. Tracked as CVE-2026-61979 and CVE-2026-15981, the bugs let an unauthenticated attacker deliver a forged response to the plugin's public Assertion Consumer Service and receive a WordPress authentication cookie for any existing account, including administrators. No password, no IdP credentials, no private key theft, and no interaction from the victim are required.

Algorithm confusion with a public key

CVE-2026-61979 is a signature-algorithm confusion attack. The attacker fetches the RSA public key that the identity provider publishes in its SAML metadata — information that is public by design — then crafts a SAML response declaring HMAC-SHA1 as the SignatureMethod. The forged assertion is signed using the RSA public key's PEM string as the HMAC shared secret. Because the plugin honors whichever algorithm the response specifies and then treats the configured RSA key as if it were an HMAC key, the signature validates and WordPress issues a session for whatever user the attacker names.

An error code treated as success

CVE-2026-15981 lies in how the plugin handles PHP's openssl_verify(). The function returns 1 for a valid signature, 0 for an invalid one, and -1 for a processing error. The plugin evaluates the return value as a boolean rather than strictly comparing against 1, and -1 is truthy in PHP. A response carrying a malformed signature that triggers an internal OpenSSL error therefore passes verification — and again produces an authentication cookie.

Exploitation already observed

DigitalOcean reported detecting an external network attempting to use a WordPress administrator session; the attacker had already obtained the admin session cookie through the bypass. Post-exploitation actions were blocked because /wp-admin was restricted to trusted networks. Scans against miniOrange SSO endpoints from IP addresses in multiple regions suggest the attacks are opportunistic and indiscriminate rather than targeted at specific organizations.

One slug, seven editions, seven version streams

Patching is messier than usual. The free plugin and six paid editions share the same WordPress slug but carry different version numbers, so a quick rule of thumb like "version 5.4.5 or higher" can leave paid editions exposed. Paid tiers may not show update notifications in the WordPress dashboard and require manual uploads.

Patched versions per the disclosure: Free 5.4.5+, Premium single-site 13.0.4+, Standard 17.0.6+, multisite Premium/Enterprise/All-Inclusive 20.2.8+, single-site Enterprise/All-Inclusive 26.0.3+, VIP single-site 32.0.8+, and VIP multisite 35.0.7+.

What defenders should look for

The most telling signal is a mismatch between the two sides of the federation: WordPress-side SAML logins with no corresponding successful authentication in the IdP logs. Other indicators include POST requests to the miniOrange SSO endpoint from unexpected source IPs, /wp-admin access immediately following such a POST, SAML responses using HMAC-SHA1 where the organization only permits RSA, and OpenSSL signature-processing errors coinciding with successful logins. Follow-on compromise may surface as new administrator accounts, changes to plugins, themes or PHP files, or web shell deployment.

Where immediate patching is not possible, the disclosure lists interim measures: reject HMAC-SHA1 at the endpoint and compare openssl_verify() strictly against 1, apply WAF rules blocking known forgery patterns on the SAML endpoint, and restrict /wp-admin to a VPN or trusted networks — the control that stopped the attacker in DigitalOcean's case.

Why it matters

Signature verification is the entire trust model of SAML, and two independent implementation slips — honoring an attacker-chosen algorithm and mishandling a boolean cast of an error code — collapse it completely. With an administrator session, an attacker can alter posts, users, settings, plugins and themes, and in configurations where admins can install or edit code this plausibly escalates to remote code execution and persistence, a step the source explicitly marks as inference. Because scanning is indiscriminate, every unpatched install is a target regardless of the site's profile. It is also a reminder that PHP's loose typing around C-style return values can turn a hard failure into a silent success, and that plugin families sharing one slug while shipping divergent version streams make fleet-wide patch auditing genuinely difficult.

  • #wordpress
  • #security
  • #saml
  • #sso
  • #vulnerabilities

Related posts