CVE-2026-16540

This vulnerability demonstrates a common failure mode in WordPress plugin security: an endpoint that was never designed for external exposure becomes accessible when the calling context changes. In this case, a bulk appointment retrieval function that worked safely when called only by the plugin's own admin interface was exposed to unauthenticated requests—likely through a frontend refactor, AJAX endpoint exposure, or REST API registration—without adding any authentication check. The critical issue isn't simply a missing authorization check. It's that the plugin implemented tiered feature access where deletion operations required license validation but read operations did not. This asymmetry created the conditions for the bug: someone reviewed the deletion endpoint because permanent data loss has obvious consequences, but the read endpoint was seen as merely data access—a free-tier limitation rather than a security boundary. That implicit assumption—that reading appointment data is acceptable to expose—never got challenged because nobody wrote a threat model for what was assumed to be an internal API. The practical impact is significant: any unauthenticated user can retrieve all appointment records including customer names, email addresses, phone numbers, and appointment details. This is personal data exfiltration at scale, not merely a technical access control failure. For defenders: audit your WordPress plugins for endpoints that handle bulk data operations, especially those added in earlier versions or that were originally intended only for admin-panel use. Look for any function performing bulk retrieval, export, or listing that lacks `current_user_can()` or similar capability checks. The pattern to watch is "internal functions that became AJAX handlers"—review your plugin's `admin-ajax.php` registrations and REST API routes for any that accept no authentication. If the plugin offers a premium tier, check whether the free version's bulk operations received the same authorization rigor as premium features that obviously modify or delete data. For developers: treat all data retrieval endpoints as if they were already public, because frontend refactors, third-party integrations, or simple URL discovery will eventually expose them. The assumption that "only our admin interface calls this" is an architectural time bomb.

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