Mstore API CVE-2026-13447

Requires that the target WordPress site runs Mstore API <= 4.20.0 with the Firebase Phone Authentication login path reachable (the flutter-user.php phone-auth endpoints that call FirebasePhoneAuthHelper::verify_id_token()). Given that, there are no further limits: exploitation is remote and unauthenticated with no user interaction (AV:N/AC:L/PR:N/UI:N), and the attacker only needs to submit a self-signed JWT with chosen claims. The primary limiting factor is whether the Firebase phone-login feature is enabled/exposed on a given deployment; impersonating a specific privileged account additionally requires knowing (or guessing) the phone identifier associated with that account, though arbitrary new accounts can be created regardless.

The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H = 9.8) is well supported by the description: exploitation is remote, requires no authentication, no user interaction, and yields full account takeover including potential administrator impersonation, which justifies high confidentiality, integrity, and availability impact. This is a genuine high-priority issue rather than an inflated score - the root cause (missing signature verification) is trivially and deterministically exploitable by anyone who can craft a JWT, and the auth-bypass class is highly automatable. No EPSS score, KEV listing, or POC was provided; absence of EPSS/KEV does not lower the intrinsic risk, but it means widespread active exploitation is not yet evidenced. The main mitigating factor is that the vulnerable Firebase Phone Auth flow must be reachable/enabled on the target store; where it is, the barrier to exploitation is essentially zero.

An attacker generates their own RSA key pair, builds a Firebase ID token whose claims (aud, iss, phone_number) name a target store and a victim's phone number, and signs it with their private key. They send it to the plugin's phone-auth login endpoint; because the server never checks the signature against Google's certificates, it accepts the token and authenticates the attacker as the victim - or provisions a new account. No public POC was provided, but the forgery is straightforward given the known missing openssl_verify() call.