On August 19th, 2026, during internal research, I discovered an Authentication Bypass vulnerability in WPMU DEV Dashboard, a WordPress plugin with an estimated 350,000 active installations. This vulnerability makes it possible for unauthenticated attackers to gain administrator access when Hub Single-Sign On is enabled. This can lead to complete site takeover and, when an administrator-accessible code-write mechanism such as the WordPress plugin or theme editor is available, remote code execution.
I discovered this vulnerability with the help of Wordfence Argus, which we covered in a separate post. Our mission is to secure WordPress through defense in depth, which is why we invest in quality vulnerability research and work closely with plugin vendors to ensure vulnerabilities are addressed before they can be widely exploited. We are committed to making the WordPress ecosystem more secure through the detection and prevention of vulnerabilities, which is a critical element of a multi-layered approach to security.
We provided full disclosure details to the WPMU DEV team through our Wordfence Vulnerability Management Portal on the same day of discovery, August 19, 2026. The developer acknowledged the report and submitted a pre-release patch for review on August 21, 2026. This patch was released to the public as version 5.0.2 on August 24, 2026. We would like to commend the WPMU DEV team for their prompt response.
Wordfence Premium, Wordfence Care, and Wordfence Response customers received a firewall rule to provide protection against known exploitation techniques on August 25, 2026. Free users will get the same rule 30 days later, on September 24, 2026. NOTE: The firewall rule was deployed one day after the patch was made public as it is a feature breaking rule.
We urge users of WPMU DEV Dashboard to verify that their sites are updated to the latest patched version, 5.0.2, at the time of this writing. Sites that cannot update immediately should disable Hub SSO until the patched version has been installed.
Vulnerability Summary from Wordfence Intelligence
Technical Analysis
WPMU DEV Dashboard connects WordPress sites to WPMU DEV services and provides a Hub SSO flow that allows an authorized Hub user to log in to a connected WordPress site. The flow is implemented as two AJAX actions, wdpsso_step1 and wdpsso_step2.
Examining the code reveals that both actions are included in the $nopriv_actions array in the WPMUDEV_Dashboard_Ajax class. This makes the actions reachable by unauthenticated visitors. That exposure is necessary for the SSO flow, since the visitor is not yet authenticated to WordPress when the exchange begins, but it also means that each step must cryptographically distinguish legitimate Hub messages from values an anonymous visitor can obtain or control.
private array $nopriv_actions
= array(
'wdpunauth',
'wdpsso_step1',
'wdpsso_step2',
);
The first action calls the authenticate_sso_access_step1() function. After confirming that SSO is enabled and the site is connected to WPMU DEV, the function generates a token and state value. It then creates an HMAC-SHA256 signature by concatenating the token, hashed state, redirect value, and site domain without delimiters or length prefixes.
$token = uniqid() . '-' . microtime( true ); WPMUDEV_Dashboard::$settings->set( 'active_token', $token, 'sso' ); // Create state session cookie. $api_key = $this->get_key(); $pre_sso_state = uniqid( '', true ); $secure_cookie = 'https' === wp_parse_url( get_option( 'home' ), PHP_URL_SCHEME ); setcookie( 'wdp-pre-sso-state', $pre_sso_state, time() + 3600, COOKIEPATH, COOKIE_DOMAIN, $secure_cookie, true ); $hashed_pre_sso_state = hash_hmac( 'sha256', $pre_sso_state, $api_key ); // Build hmac for OAuth. $domain = $this->network_site_url(); $profile = $this->get_profile(); $outgoing_hmac = hash_hmac( 'sha256', $token . $hashed_pre_sso_state . $redirect . $domain, $api_key );
The resulting signature is returned to the caller along with the token, hashed state, redirect, and domain as query parameters in a redirect to the WPMU DEV Hub SSO endpoint.
$auth_params = array(
'domain' => $domain,
'hmac' => $outgoing_hmac,
'token' => $token,
'pre_sso_state' => $hashed_pre_sso_state,
'redirect' => $redirect,
'_hubteam' => $hubteam,
);
The second action calls the authenticate_sso_access_step2() function. This function receives a signature from the Hub and independently constructs the message it expects the Hub to have signed. Unfortunately, this message is not constructed from the same set of fields used in step 1. Step 2 concatenates only the token, state, and redirect values, again without separators, and omits the domain field entirely.
$incoming_hmac = $sso_access_data['incoming_hmac'] ?? ''; $token = $sso_access_data['token'] ?? ''; $pre_sso_state = $sso_access_data['pre_sso_state'] ?? ''; $redirect = $sso_access_data['redirect'] ?? ''; $api_key = $this->get_key(); $verifying_hmac = hash_hmac( 'sha256', $token . $pre_sso_state . $redirect, $api_key ); $redirect = urldecode( $redirect ); $userid = WPMUDEV_Dashboard::$settings->get( 'userid', 'sso' ); $user = $this->refresh_profile(); $is_valid = hash_equals( $incoming_hmac, $verifying_hmac );
This creates an ambiguity between the two signed messages. In step 1, the signed message has the following conceptual structure:
token || state || redirect || domain
In step 2, the verified message has this structure:
token || state || redirect
Because the fields are concatenated without unambiguous boundaries, an unauthenticated attacker can request step 1 with an empty redirect value. Step 1 then signs token || state || domain and returns the resulting HMAC and all of the non-secret values needed to continue the exchange. The attacker can replay that same HMAC to step 2 while placing the returned domain in the step-2 redirect field. Step 2 also constructs token || state || domain, so the two byte strings are identical even though the domain occupies a different logical field.
The attacker does not need to know the WPMU DEV API key. Step 1 acts as a signing oracle and returns a valid HMAC that step 2 accepts for a different interpretation of the same concatenated bytes.
The remaining checks do not prevent the attack. Step 1 sets the wdp-pre-sso-state cookie and returns the corresponding hashed state, so the attacker can preserve the cookie and submit the returned state value. Step 1 also stores and returns the active token, allowing the attacker to satisfy the token and expiry checks with a fresh value.
// Check if the session cookie of the state value exists in the user's browser.
if ( isset( $_COOKIE['wdp-pre-sso-state'] ) ) {
// Check that the state value is the same with what was passed through the endpoint.
$hmac_state_value = hash_hmac( 'sha256', sanitize_text_field( wp_unslash( $_COOKIE['wdp-pre-sso-state'] ) ), $api_key );
if ( hash_equals( $hmac_state_value, $pre_sso_state ) ) {
// Check if the token has been used in the past, to prevent replay attacks.
$previous_sso_token = WPMUDEV_Dashboard::$settings->get( 'previous_token', 'sso', 0 );
if ( $token_timestamp_float > $previous_sso_token ) {
WPMUDEV_Dashboard::$settings->set( 'previous_token', $token_timestamp_float, 'sso' );
} else {
wp_die( 'The SSO token has been used in the past.' );
}
// Finally, check if the passed token is the same that was saved in the first place.
$active_sso_token = WPMUDEV_Dashboard::$settings->get( 'active_token', 'sso' );
if ( $token !== $active_sso_token ) {
wp_die( 'The SSO token could not be verified.' );
} else {
WPMUDEV_Dashboard::$settings->set( 'active_token', uniqid(), 'sso' );
}
}
}
Once these checks pass, the plugin creates an authentication cookie for the WordPress user configured for Hub SSO. On sites where SSO is mapped to an administrator, the unauthenticated attacker receives an administrator session. An administrator session generally provides complete control of a WordPress site.
// If everything checks out, log in the user. wp_clear_auth_cookie(); wp_set_auth_cookie( $userid, false ); wp_set_current_user( $userid );
It is important to note that this is distinct from the WPMU DEV Dashboard authentication bypass affecting versions up to and including 5.0.0 that involved empty-key WDP-AUTH validation. That earlier issue affected unconnected sites through the Hub remote-request path. This vulnerability affects connected sites with Hub SSO enabled, uses the two wdpsso_* actions, and remains exploitable in version 5.0.1 despite the protections added for the earlier issue.
The Patch
The vendor’s patch stores the HMAC created during step 1 in a server-side SSO setting. Step 2 validates that this stored value has the expected format and rejects the request when the incoming signature is the same signature produced by step 1. A successful legitimate SSO exchange clears the temporary value.
$outgoing_hmac = hash_hmac( 'sha256', $token . $hashed_pre_sso_state . $redirect . $domain, $api_key ); WPMUDEV_Dashboard::$settings->set( 'step1_hmac', $outgoing_hmac, 'sso' );
$verifying_hmac = hash_hmac( 'sha256', $token . $pre_sso_state . $redirect, $api_key );
$redirect = urldecode( $redirect );
$step1_hmac = WPMUDEV_Dashboard::$settings->get( 'step1_hmac', 'sso', '' );
if ( ! is_string( $step1_hmac ) || 1 !== preg_match( '/\A[0-9a-f]{64}\z/', $step1_hmac ) ) {
wp_die( 'Invalid SSO authentication response.' );
}
if ( hash_equals( $step1_hmac, $incoming_hmac ) ) {
wp_die( 'Invalid SSO authentication response.' );
}
We tested the reported attack against the patched build and confirmed that replaying the step-1 HMAC in step 2 was rejected without creating a wordpress_logged_in cookie. As a positive control, we generated the distinct HMAC expected from a legitimate Hub step-2 response and confirmed that the SSO flow still created the mapped WordPress session.
Wordfence Firewall
The following graphic demonstrates the steps to exploitation an attacker might take and at which point the Wordfence firewall would block an attacker from successfully exploiting the vulnerability.
Disclosure Timeline
Vendor / external action
Conclusion
In this blog post, we detailed an Unauthenticated Authentication Bypass vulnerability in WPMU DEV Dashboard affecting all versions up to, and including, 5.0.1. This vulnerability makes it possible for unauthenticated threat actors to reuse an HMAC returned by the first step of the Hub SSO flow in the second step by shifting the site domain into the redirect field. On connected sites where Hub SSO is enabled and mapped to an administrator, successful exploitation can lead to complete site compromise.
We encourage WordPress users to verify that their sites are updated to the latest patched version of WPMU DEV Dashboard, considering the critical nature of this vulnerability. Site owners who cannot update immediately should disable Hub SSO until the patch has been installed.
Wordfence Premium, Wordfence Care, and Wordfence Response users received a firewall rule to protect against known exploits targeting this vulnerability in WPMU DEV Dashboard on August 25, 2026. Sites using the free version of Wordfence will receive the same protection 30 days later on September 24, 2026.
If you know someone who uses this plugin on their site, we recommend sharing this advisory with them after the coordinated disclosure embargo has ended to ensure their site remains secure, as this vulnerability poses a significant risk on connected sites with Hub SSO enabled.
The post Wordfence Argus Finds Critical Authentication Bypass in WPMU DEV Dashboard Plugin appeared first on Wordfence.