Clean Login CVE-2026-116610

Requires an authenticated WordPress account with Contributor-level capabilities or above on a site where the Clean Login plugin (≤1.20.1) is installed and active. The attacker triggers the flaw by embedding the plugin's shortcodes in content of a post they themselves authored and saving it, which invokes the save_post-hooked get_pages_with_shortcodes() without a capability check. Limiting factors: exploitation is impossible without a valid low-privilege account (so sites that do not grant untrusted users Contributor+ are not realistically exposed), impact is confined to overwriting the plugin's own page-reference options with the ID/permalink of a post the attacker authored, and there is no confidentiality or availability impact and no code execution.

This is a genuinely medium-to-low priority issue rather than an urgent one, and the signals are internally consistent. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N, base 4.3) correctly reflects a network-reachable but privilege-gated flaw: the attacker must already hold an authenticated Contributor-level (or higher) account, and the only impact is integrity-limited (I:L) - overwriting the plugin's page-mapping options (cl_login_url/id, cl_register_url/id, cl_restore_url/id, cl_edit_url/id, cl_change_password_url/id). There is no confidentiality or availability impact. No EPSS score was supplied, the CVE is not in CISA KEV, and no working exploit code is referenced - the only references are the Wordfence advisory, the vulnerable source lines, and the fixing changeset. The vuln.today decision label is 'this_month', not act_now/emergency, which aligns with the modest CVSS and absence of exploitation evidence. The main caveat: because exploitation only lets an attacker point the plugin's core login/register/password-reset pages at a post they themselves authored, the practical danger is redirection/phishing or denial of the legitimate auth flow on sites that both run this plugin and grant untrusted users Contributor accounts - a real but conditional scenario. Authentication requirement is confirmed from the vector (PR:L = authenticated).

On a WordPress site running Clean Login (≤1.20.1) that allows untrusted Contributor-level accounts, an authenticated attacker creates or edits a post they author and embeds one of the plugin's shortcodes in its content. Saving the post fires the save_post hook, and because get_pages_with_shortcodes() performs no capability check, the plugin silently overwrites its login/register/restore/edit/change-password page options to point at the attacker's post. No public exploit code is identified at time of analysis.