CVE-2026-16595

WordPress plugins that expose AJAX endpoints without capability checks continue to be a reliable source of authorization bypasses. CVE-2026-16595 is one more instance: a plugin registered an AJAX handler (`wp_ajax_*`) that returned both user account data and unpublished content to any authenticated user — including Subscribers, WordPress's lowest privilege level. The endpoint required a logged-in session, which created an implicit sense of trust, but no capability check was ever added to verify the user should actually access that data. The fix is straightforward: add `current_user_can()` verification at the top of the handler, matching the capability required for the operation (typically `edit_posts` or `manage_options` depending on what's being exposed). In practice, every AJAX callback should begin with an explicit authorization check, not rely on the fact that the hook only fires for logged-in users. What's worth noting is the pattern's persistence. The `wp_ajax_*` hook system enforces authentication automatically but provides no cognitive nudge toward authorization — developers see the logged-in requirement as a security gate and stop there. This creates a structural gap between what the framework does implicitly and what secure code requires explicitly. The gap isn't about developer ignorance; it's about the API design making the wrong behavior feel complete. For defenders: audit your plugin inventory for AJAX endpoints, verify each one has capability checks tied to the specific data being returned, and treat any `wp_ajax_*` handler without `current_user_can()` as a finding — even if it was coded as 'internal use only.' The absence of a check isn't a feature; it's a vulnerability waiting for the right attacker to find it.

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