CVE-2026-14941

This CVE exposes a common failure mode in WordPress AJAX development where authentication is confused with authorization. The plugin's AJAX handlers verified that users were logged in but did not verify they had permission to perform the specific operation. In WordPress, these are separate concerns: `is_user_logged_in()` confirms identity, while `current_user_can()` confirms capability. Many developers implement the former and skip the latter, treating the nonce verification as sufficient security — but nonces protect against cross-site request forgery, not against a user performing actions outside their privilege tier. Check your own AJAX handlers now. If you have any `add_action('wp_ajax_...')` or `add_action('wp_ajax_nopriv_...')` handlers, verify each one explicitly calls `current_user_can()` for the specific capability required — not just for 'edit_posts' or 'manage_options' generically, but for the exact operation being performed. The capability check must come after the nonce verification but before any data processing or database writes. Handlers accessible to unauthenticated users (`nopriv`) warrant extra scrutiny: ask whether that endpoint should exist at all, or whether it can be refactored to require authentication. The fix in version 5.116.0 adds these capability checks. If you're maintaining a plugin with AJAX handlers, treat this CVE as a signal to audit all of them — not just the ones that happened to be reported. The pattern recurs across the WordPress ecosystem because the framework makes authorization opt-in rather than opt-out, but that architectural choice doesn't excuse skipping checks that have been available since 2006. Add static analysis tools that flag AJAX handlers lacking `current_user_can()` to your development workflow; the cost is minimal, and the prevention is immediate.

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