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.