miniOrange WordPress Vulnerability: Three Auth Bypasses

Three miniOrange plugins fixed critical, unauthenticated authentication bypass vulnerabilities inside eight days in July 2026. Every one of them scored 9.8 on CVSS. Every one let an attacker reach a WordPress administrator account with no password, no valid OTP, and no real cryptographic proof behind it.

CVE-2026-14245 hit miniOrange OTP Login, Verification and SMS Notifications, disclosed July 8 and fixed in version 5.5.2. CVE-2026-12761 hit miniOrange Social Login and Register, disclosed July 10 and fixed in 7.8.0. CVE-2026-15013 hit SAML Single Sign On - SSO Login, disclosed July 15 and fixed in 5.4.4. Same vendor, same severity, eight days apart.

That cadence is the real story here, and it's the reason this miniOrange WordPress vulnerability cluster deserves its own writeup instead of three separate one-off notices. These aren't checkout plugins or page builders. They're identity plugins: the software a site owner installs specifically to add OTP verification, social login, or SAML SSO on top of WordPress's default authentication. A bypass here doesn't compromise a contact form. It compromises the login itself, and it compromises it for exactly the sites that went out of their way to strengthen it.

How the OTP Login bypass works

miniOrange OTP Login, Verification and SMS Notifications integrates with Ultimate Member's password reset form to add a phone or email OTP step before a user can set a new password. The integration point is a function called um_reset_password_process_hook().

That function never checks, server-side, whether the OTP step actually completed. It relies instead on a form_nonce value that the plugin itself hands to every visitor, logged in or not, through a JavaScript object called moumprvar on the Ultimate Member form. Grab that nonce off the page, submit the reset request with the username_b parameter set to any username you want, and the plugin treats you as someone who just passed OTP verification. You didn't. Nobody checked.

This is worth sitting with, because it's the exact failure mode we covered when writing about what WordPress nonces protect and what they don't. A nonce proves a request came from a page the plugin generated. It says nothing about whether the user completed a multi-step process correctly, and it was never designed to. Here, the OTP was a UI gate, not an enforced state transition on the server. The exploitability requires the Ultimate Member Password Reset Form integration to be active and the plugin not restricted to phone-only resets, but that's the plugin's advertised feature, not an edge case.

How the Social Login bypass works

miniOrange Social Login and Register (the plugin covering Discord, Google, Twitter, and LinkedIn login) has a Profile Completion flow that runs after a user authenticates through an OAuth provider. It's meant to let a new social-login user fill in an email address WordPress can use.

The flow accepts that email through an email_field POST parameter, and it never checks that the submitted address actually matches the identity the OAuth provider returned. An attacker doesn't need to compromise anyone's Google or Discord account. They complete their own legitimate OAuth login, then submit someone else's email address in the profile completion request and get treated as that person.

There's a second weakness stacked on top. The send_otp_token() function, meant to verify email ownership, returns the transaction hash SHA-512(customer_key || otp) directly to the client. The OTP itself is short. Combine a leaked hash with a small keyspace and a static, often-empty customer_key on unregistered installs, and the "verification" step stops verifying much of anything. The OAuth provider proved who the user was. The plugin's own profile step then let the request rename them.

How the SAML SSO bypass works

The SAML SSO flaw is the most technically interesting of the three, and it's a textbook case of signature algorithm confusion. SAML Single Sign On - SSO Login validates incoming SAML assertions inside a function called Mo_SAML_Utilities::mo_saml_cast_key(). That function reads the SignatureMethod Algorithm attribute out of the SAMLResponse parameter, a value the attacker fully controls, instead of enforcing whatever algorithm the site administrator actually configured for the identity provider.

Here's why that's fatal. Your identity provider signs assertions with an asymmetric key pair: a private key it keeps secret, and a public key it publishes for anyone to fetch. Asymmetric signature verification only works because the private key stays private. HMAC, by contrast, is symmetric: the same key both signs and verifies, so anyone who knows that key can forge a signature.

The plugin let the incoming message declare which of those two verification modes to use. Set SignatureMethod to HMAC-SHA1, and the plugin takes the IdP's already-public RSA key and treats it as an HMAC secret. Since that key was never secret to begin with, an attacker can compute a valid HMAC signature over a forged assertion for any user, including an administrator, and the plugin accepts it. A public key is public. The moment a verifier lets the message choose its own algorithm, an attacker can downgrade an asymmetric check into a symmetric one keyed by a value they already had.

Who is affected

All three vulnerabilities are unauthenticated and require no special site configuration beyond having the affected feature active, which for identity plugins is the normal, intended way to run them.

• miniOrange OTP Login, Verification and SMS Notifications: all versions through 5.5.1, fixed in 5.5.2. Requires the site to run the Ultimate Member Password Reset Form integration, and to allow email or username-based resets rather than phone-only.
• miniOrange Social Login and Register: all versions through 7.7.0, fixed in 7.8.0. Requires the Profile Completion flow, which most sites running social login turn on by default because it's how the plugin collects an email address for new social sign-ups.
• SAML Single Sign On - SSO Login: all versions through 5.4.3, fixed in 5.4.4. Any site with SAML authentication active is exploitable, because the IdP's public key is public by definition and the plugin never checked which algorithm it was allowed to verify with. No setting on the WordPress side turns this off short of updating; the fix has to ship in the plugin code itself.

The pattern behind all three: a client can't prove its own authentication

Look at the three root causes side by side and they collapse into one sentence: each plugin let a value the attacker controlled stand in for proof that an authentication step had actually happened on the server. The OTP plugin trusted a public nonce as if it were proof of OTP success. The social login plugin trusted an unverified POST field as if it were the OAuth provider's own claim. The SAML plugin trusted an attacker-supplied algorithm name as if it were the site's own security policy.

None of these are exotic bugs. They're the same category of mistake we flagged in an earlier membership-plugin authentication bypass, where a plugin similarly let client-side state substitute for a server-side check. What's different here is the concentration. Three critical, unauthenticated, administrator-takeover bugs from one vendor, across three separate plugins, inside a single month, is a supply-concentration signal, not just three unlucky coincidences. If your identity stack, OTP, social login, and SSO, all comes from the same vendor, a bad month for that vendor is a bad month for every layer of your login at once. That's worth factoring into how you choose identity plugins going forward, independent of any one CVE.

It's also worth naming what these bugs are not. None of the three involve a stolen credential, a phished admin, or a supply-chain compromise of the plugin itself. They're pure logic flaws in code that shipped and passed whatever testing it got. That's a sobering thing to say about plugins whose entire job is authentication.

There's a design lesson underneath the three specific mechanisms, too. Every one of these plugins had a legitimate, working proof of authentication available to it somewhere in the request: a server-side session flag the OTP step could have set, the OAuth provider's own verified claims the social login flow could have read directly, a fixed algorithm the SAML plugin's own settings page already stored.

In every case, the plugin reached past that trustworthy source and pulled the deciding value from the request instead. Fixing the bug class, not just the bug, means auditing every point in a plugin where a security decision reads from $_POST, $_GET, or an XML payload the client controls, and asking whether the server already knows the answer on its own.

What to do now

If you run any of these three plugins, check your installed version first and update immediately if you're below the fixed release:

• OTP Login, Verification and SMS Notifications: update to 5.5.2 or later. If you use the Ultimate Member Password Reset Form integration, review password reset activity in your logs for reset requests that don't correspond to a real user action, particularly any followed shortly by a login as an administrator account.
• Social Login and Register: update to 7.8.0 or later. If your site uses Profile Completion, check user accounts for email address changes you can't attribute to the account owner, and look for OTP-related requests firing in rapid succession, a sign of an offline cracking attempt against a leaked hash.
• SAML Single Sign On - SSO Login: update to 5.4.4 or later, which removes support for insecure signature algorithms rather than just patching the one bug. Pull your SAML/SSO login audit trail and look for sessions that used HMAC-SHA1 when your identity provider signs with RSA, and treat any administrator session that came in through SSO from an IP or location you don't recognize as a live incident, not a false positive.

Across all three, watch for the same indicator: an administrator account, or any privileged account, that someone created or logged into through a path the real user never took. Cross-reference login timestamps against the user's actual working hours and known IP ranges if you keep that kind of log. If you find a suspicious account and aren't sure what else changed on the site, our general checklist for signs a WordPress site has been hacked covers the broader cleanup steps, so we won't repeat that ground here.

WP Vanguard's scanner flags outdated plugin versions against known CVEs like these three, so a stale identity plugin doesn't sit unpatched past its disclosure date.

References

• NVD - CVE-2026-14245
• NVD - CVE-2026-12761
• NVD - CVE-2026-15013
• Wordfence Intelligence - SAML Single Sign On <= 5.4.4 - Unauthenticated Authentication Bypass via SAMLResponse Parameter
• miniOrange OTP Login, Verification and SMS Notifications - changelog
• miniOrange Social Login and Register - changelog
• SAML Single Sign On - SSO Login - changelog