CVE-2026-15372

The CVE describes a 2FA bypass in a WordPress plugin where one authentication method completely skips the second-factor validation step. Read that carefully: the advisory says the plugin 'does not validate' the factor — not that validation is flawed, but that it's absent entirely for a specific code path. This is a missing security gate, not a broken one, which is why the vulnerability likely went undetected for so long. If you're running this plugin, your priority is identifying which authentication methods are enabled and ensuring users aren't relying on the vulnerable method as their sole 2FA channel. Check the plugin's method configuration — if email codes, SMS, push notifications, or backup codes are in use alongside the primary TOTP handler, you need to verify which path the vulnerable method takes in the code. The practical risk: an attacker with valid credentials can bypass 2FA entirely if they trigger the method that lacks the validation call, then escalate to admin-level access where they can edit plugins, modify wp-config, or access the database directly. The architectural lesson here is what matters most for the long term. This plugin almost certainly maintained parallel implementation branches for each 2FA method — a TOTP handler, an email-code handler, an SMS handler, and so on. When developers add a new authentication method, the common pattern is to clone an existing handler and modify it for the new method. That's efficient, but it creates exactly the condition this CVE exploits: a code path that looks identical to the others but lacks the security-critical verification call. The fix pattern that works is a unified validation gateway — a single choke point through which all methods must pass before authentication completes. This prevents any new method addition from accidentally bypassing verification, because the gateway enforces it regardless of which handler executes. For defenders elsewhere: audit any plugin or application that supports multiple authentication methods and ask whether all methods funnel through identical validation logic. If you see method-specific handlers with separate validation code in each, that's the architectural smell that preceded this bypass. The same pattern has appeared in OAuth libraries, SAML implementations, and framework auth systems — each time, a new method gets added by cloning an existing handler, and each time, the clone forgets the security check. The next vulnerability in your environment is probably being written right now by a developer cloning an auth handler to add support for push notifications or hardware keys.

Reviewed through automated stages and approved by a human before publication.