A CVSS 9.8 authentication bypass published August 28 affects WPMU DEV Dashboard sites connected to the WPMU DEV Hub — exactly the population that the plugin’s previous unauthenticated admin bypass, published August 6, explicitly did not affect.
What happened
On Friday, August 28, 2026, NVD published CVE-2026-76581, an authentication bypass in the WPMU DEV Dashboard plugin for WordPress carrying a CVSS 3.1 base score of 9.8. The CVE Program record went live at 6:39 a.m. UTC and NVD’s republication followed at 8:16 a.m. UTC the same morning. Wordfence is the assigning CNA, reserved the identifier on August 19, and supplied the only score in the record.
The plugin was patched four days before the record appeared. Wordfence’s published timeline puts internal discovery and full disclosure to the vendor on August 19, vendor acknowledgment and a submitted patch on August 21, and the public release of version 5.0.2 on August 24. That is a five-day turnaround from discovery to a shipped fix, which is fast by any standard and worth saying plainly before anything critical follows.
The defect is a canonicalization problem in how two unauthenticated AJAX actions build the message they sign. NVD’s record, in the CNA’s own words, describes “inconsistent and ambiguous HMAC message construction between the unauthenticated wdpsso_step1 and wdpsso_step2 AJAX actions, where step 1 signs and discloses an unseparated concatenation of the token, state, redirect, and domain values, while step 2 verifies an unseparated concatenation that omits the domain field.” Because the four values are joined with no delimiter between them, the boundary between the redirect field and the domain field is not fixed by the signature — it is a matter of where the reader decides to draw it. An attacker collects a valid signature from step 1, moves the domain value into the redirect field, and hands the same signature to step 2, which is verifying a shorter list of fields and accepts it. The record states the result: “an authenticated administrator session.”
The precondition is the part worth reading twice. Per the record, the bypass works “on sites connected to WPMU DEV with Hub SSO enabled and mapped to an administrator.” That is a configured, in-use, actively managed installation — not an abandoned one.
Why it matters
Three weeks earlier, on August 6, 2026, NVD published CVE-2026-15459 against the same plugin: an unauthenticated authentication bypass in all versions up to and including 5.0.0, scored 8.1, leading to arbitrary plugin installation from an attacker-supplied URL and therefore remote code execution. Wordfence was the CNA there too. The mechanism was different — an empty site API key made the WDP-AUTH request signature “trivially forgeable” through validate_hash(), version 5.0.0 removed the replay check in validate_nonce(), and the remote handler sat on the public init hook with no capability check — but the outcome was the same class of thing: no credentials in, administrator out.
The two records describe opposite halves of the install base. CVE-2026-15459 applies, in the CNA’s words, to “sites not yet connected to the WPMU DEV Hub — the default state after installation,” and the record closes by stating that “sites connected to a WPMU DEV account, which have a non-empty 64-character API key, are not affected.” CVE-2026-76581 applies to sites connected to the Hub with SSO enabled. Between the two, across August, both states of the plugin had an unauthenticated path to administrator at some version.
That matters operationally, not just as a curiosity. A site owner who read the August 6 advisory carefully, confirmed the installation was connected to the Hub with a real API key, and correctly concluded “this one does not reach us” had performed the right analysis and reached the right answer. Three weeks later that same population is the one the second bypass targets. The reassuring half of the first record became the affected half of the second. There was no configuration a defender could have chosen in early August that was durably safe, and no way to know that at the time.
The second thing worth naming is the defect class. Signing an unseparated concatenation of fields is one of the older and better-understood ways to build a signature that does not mean what its author thinks it means. If a verifier reconstructs the signed string from a different field list, or from the same fields in a different arrangement, the signature stops binding the fields and starts binding only their concatenation — and the attacker gets to choose where one field ends and the next begins. The fix is a delimiter, or length prefixes, or signing a structured encoding rather than a string. It costs nothing at design time. It recurs anyway, in code written by people who know better, which is why NVD’s assigned weakness here is CWE-347, improper verification of a cryptographic signature, rather than a missing-authentication class. The signature check ran. It just did not check what it appeared to.
The third thing is what this plugin is for. WPMU DEV Dashboard is the agent that connects an individual WordPress site to a central management console, so that an agency or an internal team can see, update, and administer many sites from one place. The site running it is, by design, not being watched individually. That is the entire value proposition, and it is also what makes an unauthenticated administrator bypass in this specific plugin worth more to an attacker than the same bug in a contact form. Severity Daily covered the same structural point on August 28 in N-able’s N-central, where the remote-control feature that exists to reach managed endpoints was the feature used to reach them. Management-plane software concentrates blast radius on purpose. Its authentication code deserves scrutiny in proportion, and it does not reliably get it.
One detail from Wordfence’s own timeline belongs in the record rather than in a complaint. The firewall rule covering this vulnerability reached Wordfence premium users on August 25 and is scheduled to reach free users on September 24 — a thirty-day gap that is standard practice for that vendor and disclosed openly by it. Anyone relying on a Wordfence rule rather than the plugin update as their control should know which side of that date they are on. The update is available to everyone now; the rule is not.
Both CVE records carry an NVD vulnStatus of Deferred, meaning NVD will not enrich them further. There will be no NVD-assigned vector and no independently constructed configuration list. The CNA’s paragraph is the permanent authoritative description, and every downstream scanner inherits it verbatim. On CVE-2026-76581 that paragraph does not name a fixed version. The fixed version is recoverable, but from a different place: the CVE Program record’s own affected-versions block lists 0 through 5.0.1 as affected and everything above 5.0.1 as unaffected, and Wordfence’s writeup names 5.0.2 directly. A defender working only from the NVD description would know they were vulnerable and not know what to upgrade to.
What to do
Update WPMU DEV Dashboard to 5.0.2 or later. Version 5.0.1 is affected; 5.0.1 was the release that fixed the earlier bypass, so a site patched in response to the August 6 advisory is still in scope for this one.
If you run the plugin across client sites, treat this as a fleet action rather than a site action, and note the awkwardness: the tool you would normally use to push the update across the fleet is the tool being updated. Confirm each site individually reports 5.0.2 or later afterward rather than trusting the console’s own summary.
Check whether Hub SSO is enabled and which account it maps to. A site connected to the Hub with SSO mapped to an administrator is the exact configuration the record names.
For retrospective checks, look in web server logs for requests to admin-ajax.php carrying the wdpsso_step1 and wdpsso_step2 actions, particularly step 1 requests followed closely by step 2 requests from the same source. Then review administrator sessions and any recently installed or activated plugins, especially any installed from a URL outside the WordPress.org repository — that is the payoff path the earlier CVE describes, and it is the outcome worth ruling out on either bug.
Sourcing note
Checked: the NVD records for CVE-2026-76581 and CVE-2026-15459 by CVE ID; the CVE Program records for both identifiers through the CVE Services API, which supplied the reservation dates, the assigner, and the affected-versions blocks; and Wordfence’s published writeup of CVE-2026-76581, which supplied the disclosure timeline, the 5.0.2 fixed version, and the firewall rule dates. All description text and version ranges quoted above are from the CNA record, not from secondary coverage.
Could not reach: Wordfence’s own advisory pages at wordfence.com/threat-intel/vulnerabilities/ returned empty content on every attempt, as they have on previous runs; the Wordfence writeup was read through a full-text republication instead. The vendor’s changelog at wpmudev.com returned HTTP 403 to automated fetching, and the WordPress.org plugin listing is disallowed by that site’s robots rules. As a result this page carries no active-installation count and no verbatim vendor changelog text for 5.0.0, 5.0.1, or 5.0.2. The scale of the affected population is not stated here because it was not verifiable.
Unresolved: whether the vendor’s changelog characterizes 5.0.2 as a security release or as routine maintenance, and whether WPMU DEV has published an advisory of its own. No exploitation of either CVE has been reported by the CNA, the vendor, or CISA, and neither identifier appears in the KEV catalog as of publication.