Description

The MStore API WordPress plugin before 4.21.0 does not correctly verify the cryptographic signature of the token used to authenticate its phone-based login, allowing unauthenticated attackers who know a registered user's phone number to forge a token and take over that user's account, including administrator accounts.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.1",
  "pubDate": "2026-08-07T06:16:55.833Z",
  "pubdate": "2026-08-07T06:16:55.833Z",
  "executiveSummary": "The MStore API WordPress plugin before 4.21.0 suffers from an improper cryptographic signature verification vulnerability within its phone-based authentication mechanism. This security defect allows unauthenticated remote threat actors to completely compromise targeted user accounts, including high-privilege administrative accounts, without requiring prior access or credentials beyond the victim's known telephone number.\nThe flaw impacts the authentication module of the MStore API plugin across versions prior to 4.21.0. The business risk is critical, as successful exploitation enables full account takeover, leading to potential unauthorized data access, privilege escalation, and complete administrative control over the underlying WordPress installation. The attack requires no authentication or interaction from the victim, relying solely on the attacker's knowledge of a valid registered user's phone number.\nRemediation requires updating the MStore API plugin to version 4.21.0 or later, where proper cryptographic validation routines are enforced for authentication tokens.",
  "technicalDetails": "The vulnerability resides within the phone-based authentication subsystem of the MStore API plugin, specifically in how authentication tokens are processed and validated prior to granting user sessions. The root cause of the vulnerability is the absence of, or a flaw in, cryptographic signature verification for the tokens utilized in the login workflow.\nDuring the phone-based authentication process, the application generates or processes a token intended to prove the legitimacy of the user's session. Due to the failure to properly validate the cryptographic signature associated with this token, the system blindly trusts the incoming token data. Consequently, an unauthenticated attacker who possesses knowledge of a registered user's phone number can manually construct or forge a valid authentication token.\nThe attack flow proceeds as follows: First, the attacker identifies or obtains the registered phone number of a target user, which may include accounts with administrative privileges. Second, the attacker crafts a forged authentication token referencing the target's phone number, bypassing any secret key validation due to the missing signature check. Third, the attacker submits this forged token to the MStore API endpoint handling phone-based login.\nUpon receiving the payload, the vulnerable component fails to cryptographically verify the integrity and authenticity of the token. As a result, the backend application accepts the manipulated token as legitimate, maps the request to the corresponding user account associated with the phone number, and establishes an active authenticated session for the attacker.\nThis grants the attacker complete post-exploitation control over the victim's account. Because the vulnerability affects any registered user, attackers can target administrators to achieve full site compromise. The attack surface is exposed over the network via standard HTTP/HTTPS API endpoints exposed by the WordPress plugin, requiring no privileges or prior authentication."
}