Password Protect Pages CVE-2026-116520

Exploitation targets the plugin's restricted-content shortcode form attribute 'desc_below_form' (with 'placeholder' used as a marker-smuggling helper), reached by injecting a bare, tagless shortcode string through a WordPress comment. Two concrete conditions enable unauthenticated abuse as described: (1) WordPress's comment_content filter passes tagless shortcode text through unmodified, and (2) the site's 'comment_whitelist' setting must be enabled so that, after one approved comment from a given name/email, subsequent comments from that identity auto-approve without administrator action. Limiting factors: the attacker's first comment from a new identity generally still requires one manual admin approval before the whitelist bypass applies; the script only executes when a user actually views the injected page; and only versions up to and including 1.9.26 are affected.

Signals are moderate and internally consistent rather than alarming. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N, 7.2 High) describes a network-reachable, unauthenticated stored XSS with a scope change (script executing in visitors' browser contexts) and limited confidentiality/integrity impact. The vuln.today decision label is 'this_week' - a prioritize-but-not-emergency signal - and there is no CISA KEV listing and no EPSS score in the provided data, so there is no evidence of active exploitation or high predicted exploitation probability. No working PoC is supplied; the references are the Wordfence advisory plus WordPress plugin trac source-code lines and the fix changeset, which document the flaw and patch location, not a weaponized exploit. The practical risk is tempered by a real precondition the description itself states: reliable unauthenticated exploitation depends on the 'comment_whitelist' auto-approval behavior and a previously approved name/email, which means the first comment from a new identity still typically needs administrator approval. One caveat to verify: NVD/Wordfence assigned UI:N, yet a stored XSS only fires when a user later views the injected page - arguably passive UI but worth confirming the methodology. Overall this is a legitimate but mid-tier priority: patch on a normal cycle, not a drop-everything emergency.

An unauthenticated attacker submits a comment containing a bare shortcode payload (no HTML tags) targeting the plugin's restricted-content form attributes; WordPress's comment_content filter leaves the tagless shortcode text intact. Once that commenter's identity has been approved once and comment_whitelist auto-approval is enabled, subsequent payload comments post without admin review, and the plugin renders the unsanitized shortcode so the injected script executes in the browser of any user who views the page. No public working exploit code is identified in the provided data; the Wordfence advisory and plugin source references describe the flaw and patch rather than a published exploit.