A critical authentication bypass was disclosed in the miniOrange OTP Login, Verification and SMS Notifications plugin for WordPress, affecting all versions up to and including 5.5.5. An unauthenticated attacker who knows an administrator's username can log in with no password and no OTP by simply posting mo_wp_login_intent=otp in the request. No credential material is verified. The NVD entry for CVE-2026-85984 has the full technical breakdown.

Here's what actually went wrong from an IAM standpoint: the plugin's mo_by_pass_login() function takes a shortcut when skip_pass_fallback is enabled. It resolves a WordPress user object purely from a username lookup, then checks if that user is an administrator, and if so, skips wp_authenticate_username_password() entirely. The mo_wp_login_intent parameter that triggers this branch is accepted from a POST request with no signature, no session binding, and no verification. Whoever wrote this thought "admin role check" was equivalent to "authentication". It isn't. Role is an attribute of an already-authenticated session. Checking it before authentication is circular and, in this case, catastrophically wrong.

The conditions for exploitation are specific: a site admin must have enabled WP Login OTP, Login with Only OTP, Allow Users to Login with Username and Password, and Admin OTP Bypass simultaneously. That's a configuration that sounds like it was assembled incrementally, option by option, without anyone stepping back to reason about the combined effect. I see this constantly in enterprise IAM too. Each toggle makes sense in isolation. Together they create a gap that voids every control downstream.

Username enumeration is the only prerequisite for exploitation. On most WordPress sites, usernames are not hard to obtain. If your organization runs WordPress with this plugin, you need to treat any admin account as potentially compromised until you've confirmed the plugin is updated and you've reviewed your authentication logs for anomalous admin sessions.

Update to a patched version immediately; if one isn't published yet, disable the plugin outright rather than trying to work around it via config. Pull your WordPress admin account list, compare it against recent login events, and look for sessions that lack a corresponding MFA event or that originated from unusual IP ranges. If you use a WAF in front of your WordPress instances, add a rule to block POST requests containing mo_wp_login_intent=otp as a short-term mitigation while you coordinate the update.