CVE-2026-16578

If you're running a plugin that handles two-factor authentication, treat this vulnerability as a category failure, not just an information disclosure flaw. The CVE exposes 2FA enrollment status to unauthenticated attackers — usernames, email addresses, roles, and whether each account has 2FA enabled. That's not reconnaissance noise. That's a ranked target list with effort calculations built in. An attacker now knows precisely which accounts to hit first with credential stuffing: the ones without 2FA enrolled. The protection status that your users configured becomes the intelligence that arms your attackers. The CVSS 7.5 score fundamentally misrepresents this. It measures information disclosure generically. It has no vocabulary for reconnaissance intelligence — data that answers 'which accounts should I target first and how much effort will each require?' That's what your plugin just leaked. What should drive your prioritization is your user base's 2FA adoption rate. If adoption is high, the exposure is uncomfortable but the actionable attack surface is narrow. If adoption is low, the plugin has been providing security theater while leaking a targeting roadmap. You're worse off than if you'd never installed it. Two concrete actions: first, audit your user population now — pull the 2FA enrollment report and treat accounts without 2FA as active priority targets for强制 enrollment or temporary lockout until they enroll. Second, recognize that even after patching, the damage may already be permanent. Every attacker who queried this endpoint during the unpatched window has a target list that doesn't expire. The defender's exposure ends at patch time; the attacker's advantage does not. Treat this as an ongoing threat intelligence problem, not a one-time remediation.

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