MStore API

CVE-2026-13447 affects MStore API <= 4.20.0. The plugin accepted Firebase phone-authentication ID tokens without cryptographic signature verification, allowing unauthenticated account takeover or arbitrary account creation. Update to 4.21.0 or newer immediately.

CVE-2026-13447 is a critical authentication bypass vulnerability in MStore API, the WordPress plugin used by WooCommerce and marketplace sites to power mobile app integrations. The issue affects MStore API versions up to and including 4.20.0.

The vulnerability is especially sensitive because it targets authentication. A vulnerable site using Firebase phone authentication can accept a forged identity token as proof of identity, which can allow unauthenticated attackers to access existing WordPress accounts or create new accounts through the plugin flow.

Table of Contents

Vulnerability summary

Plugin: MStore API – Create Native Android & iOS Apps On The Cloud
Slug: mstore-api
CVE: CVE-2026-13447
Affected versions: MStore API <= 4.20.0
Fixed version: 4.21.0 or newer
Severity: CVSS 9.8 Critical
Weakness: CWE-287 Improper Authentication
Required privilege: none
User interaction: none
Attack class: Firebase phone-authentication JWT signature verification failure
CISA KEV: not listed at publication time

Technical cause

The vulnerable code path is in FirebasePhoneAuthHelper::verify_id_token(). The CVE metadata describes a validation routine that decoded and checked token claims such as alg, kid, aud, and iss, but did not verify the token’s cryptographic signature against Google’s Firebase public keys.

That is the critical boundary for any JWT-based login flow. Claims inside a token are not trustworthy until the signature, issuer, audience, expiry, and key material have all been verified. In affected MStore API versions, the missing signature verification could let an attacker present a token with caller-controlled phone identity data and have the plugin treat it as authenticated Firebase proof.

Depending on site configuration, the impact can include takeover of an existing user account tied to phone authentication or unauthorized creation of new accounts. If a privileged account is reachable through that flow, the issue becomes full site compromise.

Immediate remediation

Update MStore API to 4.21.0 or newer. The current WordPress.org release is newer than the patched baseline.
If you cannot update immediately, disable Firebase phone login and any MStore API mobile-login flow that accepts Firebase ID tokens.
Review recent user registrations and logins that used phone authentication.
Check for new administrator, shop manager, vendor, or customer accounts created after the vulnerable version was installed.
Rotate administrator passwords and invalidate sessions if unexpected logins or account creations are found.
Confirm that mobile app clients still authenticate successfully after updating, because the fix tightens token validation.

WP-CLI checks

Use the plugin slug when checking the installed version:

wp plugin get mstore-api --fields=name,version,status
wp plugin update mstore-api
wp plugin get mstore-api --field=version

Review recent account creation and privileged users:

wp user list --role=administrator --fields=ID,user_login,user_email,roles,user_registered
wp user list --role=shop_manager --fields=ID,user_login,user_email,roles,user_registered
wp user list --fields=ID,user_login,user_email,roles,user_registered --orderby=registered --order=DESC --number=50

Database review

If you need a quick read-only check for recently created accounts, adjust the date window and table prefix for your site:

wp db query "SELECT ID, user_login, user_email, user_registered FROM {prefix}users WHERE user_registered >= '2026-09-01' ORDER BY user_registered DESC LIMIT 100;"

Investigate accounts created through phone-authentication flows, unfamiliar email addresses, or accounts that received elevated roles shortly after registration.

Log review

Search access logs for MStore API authentication traffic and correlate suspicious requests with new account creation timestamps:

grep -Ei 'mstore|firebase|phone|id_token|wp-json' /var/log/nginx/access.log*
grep -Ei 'mstore|firebase|phone|id_token|wp-json' /var/log/apache2/access.log*

Temporary mitigation

The correct fix is to update MStore API. If patching is delayed, disable the Firebase phone-login integration from the plugin or mobile-app configuration and block unauthenticated requests to MStore API Firebase phone-authentication routes at the WAF layer. Keep the rule scoped to the affected authentication route so normal WooCommerce and WordPress REST traffic continues working.

As a defensive application rule, any JWT login handler should reject tokens unless signature verification succeeds against the expected issuer and audience. The intended validation boundary looks like this:

// Defensive validation outline only.
$verified_token = verify_firebase_id_token_with_google_keys( $id_token );
if ( ! $verified_token || $verified_token['aud'] !== $expected_project_id ) {
    return new WP_Error( 'invalid_token', 'Firebase token verification failed.', array( 'status' => 401 ) );
}