Branda Plugin CVE-2026-11551

Exploitation requires that the Branda (branda-white-labeling) plugin be installed and active at version 3.4.29 or earlier, and that the plugin's login-screen / signup-password module be enabled so its password-update handler in inc/modules/login-screen/signup-password.php is reachable over HTTP(S). Beyond that, no special conditions apply - the CVSS vector AV:N/AC:L/PR:N/UI:N confirms remote, unauthenticated exploitation with no user interaction against default-reachable Branda deployments, and the attacker only needs to know or guess the target username/user_id (administrator IDs are typically 1 and usernames are often disclosed via the REST API or author archives). Limiting factors are narrow: sites that have not enabled the signup/login-password customization module, or that restrict wp-login/signup endpoints behind IP allowlists or HTTP auth, are not exploitable through this path.

All available signals point to a true critical: the CVSS 3.1 vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H describes a network-reachable, low-complexity, unauthenticated, no-user-interaction flaw with full CIA impact on the target site, which aligns with the description of unauthenticated password reset against any account. EPSS and CISA KEV data were not provided in the input, so probabilistic and confirmed-exploitation signals cannot be cross-referenced; absence of KEV does not imply safety given how trivial this class of bug is to exploit against a WordPress plugin with a known patch diff. The Wordfence reporter tag plus a public trac changeset means defenders should assume reliable n-day exploitation soon, even though no public exploit identified at time of analysis. Practical risk is highest for sites that expose the Branda-customized signup/login screens to the public internet, which is the plugin's intended deployment.

An unauthenticated attacker enumerates a WordPress site running Branda (visible via login-screen branding or plugin asset paths), then issues a crafted POST to the Branda signup-password endpoint specifying the administrator's user_id (or username) and a new password of their choice. Because the handler never validates that the requester owns the targeted account, the password is overwritten, and the attacker logs in to /wp-admin as that administrator and installs a malicious plugin or PHP backdoor for persistence. No public exploit identified at time of analysis, but the trac diff makes a working PoC straightforward to derive.