CVE-2026-13440

The CVE describes a nonce (ajd_nonce) exposed via wp_localize_script to unauthenticated visitors, enabling mass exploitation of a stored XSS in the create_popup handler. The framing calls this a 'nonce bypass,' but that's the wrong lens. The real issue is that this endpoint was never protected by proper capability checks in the first place — the nonce was never doing access control work it was designed to do. WordPress nonces are replay-attack mitigators scoped to a user session, not authorization tokens. When you expose them to every frontend visitor indiscriminately, you haven't weakened a security control — you've revealed that the control was never functioning for this code path. Either the create_popup handler was never meant to be reachable by unauthenticated users (making this an exposure of an admin-only endpoint), or the developers genuinely believed a shared nonce provided protection. Neither is a simple bug; they're different categories of architectural failure. The practical consequence: patching the nonce exposure alone doesn't fix the underlying problem. Without capability checks in the create_popup handler, any future 'protection' mechanism will fail the same way, because the endpoint itself shouldn't be reachable by unauthenticated users at all. Check whether this plugin is actively maintained. If version 2.1.0 represents the current release with no patch available, you're dealing with an abandoned plugin containing permanently exploitable stored XSS — the nonce exposure just widens the blast radius from targeted admin attack to mass visitor compromise. In either case, the fix requires adding proper capability checks (current_user_can or equivalent) to the AJAX handler, not merely removing the nonce from wp_localize_script output.

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