Description

The WPMU DEV Dashboard plugin for WordPress is vulnerable to Authentication Bypass in all versions up to, and including, 5.0.1. This is due to 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. This makes it possible for unauthenticated attackers, on sites connected to WPMU DEV with Hub SSO enabled and mapped to an administrator, to obtain a valid HMAC from step 1 and replay it to step 2 by moving the domain value into the redirect field, resulting in an authenticated administrator session.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-08-28T08:16:41.463Z",
  "pubdate": "2026-08-28T08:16:41.463Z",
  "executiveSummary": "The WPMU DEV Dashboard plugin for WordPress, in versions up to and including 5.0.1, contains an authentication bypass vulnerability that permits unauthorized actors to gain administrative access.\nThis security flaw stems from an improper implementation of HMAC message construction within the plugin's Hub SSO authentication workflow.\nThe vulnerability allows an unauthenticated attacker to manipulate the input parameters of the `wdpsso_step1` and `wdpsso_step2` AJAX actions to forge a valid signature.\nSuccessful exploitation requires the target site to be connected to WPMU DEV with Hub SSO enabled. If triggered against a mapped administrator account, the attacker can effectively hijack the session, leading to a complete compromise of the WordPress installation.\nThis issue represents a critical risk, as it bypasses standard authentication mechanisms without requiring credentials, facilitating full administrative takeover.",
  "technicalDetails": "The vulnerability resides in the WPMU DEV Dashboard plugin's Hub SSO implementation, specifically within the handling of AJAX actions `wdpsso_step1` and `wdpsso_step2`. The root cause is an inconsistent and ambiguous HMAC message construction mechanism used to verify the integrity of authentication steps.\nIn the `wdpsso_step1` function, the plugin generates an HMAC signature based on the concatenation of the token, state, redirect, and domain parameters. Importantly, this concatenation is unseparated, and the resulting signature is disclosed to the client. The `wdpsso_step2` verification logic, however, validates the signature against a concatenation that excludes the domain field entirely.\nAn unauthenticated attacker can exploit this discrepancy by constructing a malicious payload. Because `wdpsso_step1` exposes the signature for a known set of parameters, the attacker can leverage the domain value by prepending or appending it into the redirect field. By effectively shifting the domain component into the redirect parameter, the input string for `wdpsso_step2` matches the expected format for a successful HMAC verification, despite the domain being missing from the actual verification check.\nThe attack flow proceeds as follows: First, the attacker triggers `wdpsso_step1` to obtain a valid HMAC signature. Second, the attacker prepares a request for `wdpsso_step2` where the data structure is manipulated to ensure the signature generated by step 1 passes the validation logic despite the omission of the domain field in the latter step. Finally, the attacker submits the crafted request to the `wdpsso_step2` AJAX endpoint. If the signature validates, the system authenticates the user associated with the SSO mapping—frequently an administrator—thereby bypassing the authentication process.\nThis vulnerability is effective because the server-side verification logic fails to enforce a strict, consistent format for the HMAC message across the multi-step handshake. By exploiting this flaw in the message construction logic, an attacker can bypass the intended SSO security controls, leading to total administrative control over the affected WordPress environment. This bypass is possible remotely without any prior authentication or privileges."
}