SURIQ
Run a WordPress site with the Branda plugin and your admin login is one unauthenticated web request away from a stranger. CVE-2026-11551 lets anyone, with no account and no password, reset another user's password and step into their account. Aim it at an administrator and the whole site is theirs. It carries a CVSS score of 9.8, and a working proof-of-concept is already public.
The detail that should stop you: Branda's developers closed almost exactly this hole in January. This is the second unauthenticated account-takeover bug in the plugin's login module in roughly six months. The version number changed. The failure did not.
Branda, by WPMU DEV, is a white-label and branding plugin that reskins the WordPress login and admin screens. It runs on more than 20,000 sites. Every one of them on version 3.4.29 or earlier is exposed.
What the flaw actually does
Branda's login module includes a password step for new sign-ups. The problem is simple to state: the plugin writes a new password without first confirming who is asking for it. There is no check that the request comes from the account's real owner. So an attacker submits a password change for any username, including admin, and the plugin accepts it.
Wordfence, which assigned the CVE, classifies it as a weak password-recovery flaw (CWE-640). The fix landed in the plugin's signup-password file, where an identity check now runs before any password is set. No authentication, no user interaction, reachable over the network: that is what earns the 9.8.
Once an attacker owns an administrator account on a WordPress site, the rest follows. They can install a plugin, drop a webshell, add a hidden admin, or quietly read everything the site touches. Account takeover is the foothold. Full site compromise is the next click.
The part that matters more than the patch
In January, Branda shipped 3.4.25 to fix CVE-2025-14998, an unauthenticated account takeover in the same login flow, rated the same 9.8. Five months later the same plugin, the same module, and the same outcome are back under a new CVE. The root causes are not identical. The first was a broken authorization check on a user-controlled value; this one is a missing identity check in password recovery. A defender does not care about the weakness-class number. What they see is a login component that has now failed open twice in one year.
That pattern is the real signal. One critical bug is bad luck. Two in the same code path in six months says the password logic in this plugin was never built to assume the request is hostile. Treat any plugin that reskins authentication as part of your attack surface, not a cosmetic add-on, and weight it accordingly when you decide what gets monitored and what gets retired.
We have watched this before with hosting-control plugins. LiteSpeed's cPanel plugin handed tenants root twice in 2026, and JetBrains Hub's account recovery turned out to protect nothing because the recovery codes were guessable. Authentication and recovery is exactly where a small mistake becomes total compromise.
What to do today
Update Branda to the current release, 3.4.31, now. The fix first shipped in 3.4.30, so anything at 3.4.29 or below is vulnerable, and a public exploit means un-updated sites are a ready target rather than a theoretical one. If you manage WordPress at scale, push this through your fleet today rather than on the next maintenance window.
Then assume the gap was already used, and go look. Because the attack changes a password rather than crashing something, the evidence is quiet:
- Review your user list for administrators you do not recognize, and for recent password or email-address changes on privileged accounts.
- Check WordPress logs and any audit trail for password-reset activity that no real person initiated, especially repeated resets against the same high-value accounts.
- After patching, rotate passwords on every administrator account and invalidate active sessions, so a password an attacker already set stops working.
If your site shows an admin account you cannot place, clean before you trust the patch. A seized account often leaves a second way back in, and updating the plugin does not remove a webshell or a planted user. The same lesson held with the Joomla editor flaw being exploited now: patch and hunt are two separate jobs, and skipping the hunt is how reinfection happens.