CVE-2026-16541 in Simply Schedule Appointments (versions prior to 1.6.12.17) allows any authenticated user with the staff role to enumerate the complete user roster—names and email addresses—across the entire WordPress installation. The CVSS 6.5 treats this as medium-severity information disclosure, but this fundamentally mischaracterizes the threat. This is a scope-escalation vulnerability: a role that should access only its own appointments can instead pull PII for every registered user in the system.
The enumeration dataset has compounding value that static CVSS scoring cannot model. A complete name-and-email roster enables credential stuffing across any system where users reuse passwords, and it creates high-confidence spear-phishing lures—attackers can reference real usernames and appointment contexts ('Your session with Dr. Smith needs confirmation') to induce action. The horizontal blast radius extends beyond the vulnerable site: harvested credentials detonate on third-party services.
The 0.00219 EPSS score likely reflects the plugin's narrow deployment footprint rather than low exploitability. Niche plugins in WordPress don't attract automated scanning, but they are precisely the targets for human-directed reconnaissance by attackers who specialize in appointment workflows. Treat the EPSS as uninformative rather than reassuring.
The fix almost certainly involved adding role or capability checks to existing REST endpoint queries—a surgical patch that historically precedes bypass emergence. When authorization is patched with conditional checks rather than architectural data model changes, adjacent endpoints often retain the same implicit trust assumptions. Audit the patch for scope, not just presence: confirm it scopes queries to the current user rather than merely adding a capability gate.
One overlooked dimension: the staff role may be an orphan from deprecated workflows. Many WordPress installations running this plugin created staff roles for appointment-specific purposes that have since migrated or been abandoned. The role persists with its original permissions, and no one audits what it can still access. Check whether any staff-level accounts belong to former employees, contractors, or dormant users—this vulnerability is most dangerous when weaponized against abandoned accounts with stale passwords on other systems.