CVE-2026-16030

Executive Summary

CVE-2026-16030 is a critical authentication bypass vulnerability in the MStore API WordPress plugin, affecting all versions prior to 4.21.0. The flaw resides in the plugin's phone-based login mechanism, which fails to cryptographically verify the Firebase authentication token signature, enabling unauthenticated attackers to forge valid tokens and take over any account—including administrator accounts—provided they know the target's registered phone number.

With a CVSS score of 8.1 (High), this vulnerability exposes WordPress sites using the MStore API plugin to complete account compromise without requiring any prior authentication, user interaction, or privileges. The attack vector is network-based via the plugin's publicly accessible REST API endpoints. Given that the MStore API plugin is widely deployed in mobile commerce applications built on WooCommerce, the real-world impact spans customer data theft, financial fraud, and full store compromise.

Technical Analysis

The MStore API plugin provides a RESTful bridge between WordPress/WooCommerce backends and native mobile applications. A core feature is phone-based authentication, which integrates with Firebase Authentication to allow users to log in using their phone numbers and one-time passcodes (OTPs). This integration relies on the Firebase REST API to exchange Firebase ID tokens for WordPress session tokens.

The vulnerability stems from improper cryptographic verification in the token-handling logic. When a user authenticates via phone, the client-side mobile application sends a Firebase ID token to the plugin's REST endpoint (typically under mstore-api/v1/). The plugin must validate this token's signature against Firebase's public keys (available from Firebase's JWKS endpoint) to confirm the token was genuinely issued by Firebase for the given user.

In affected versions (before 4.21.0), the plugin fails to perform this signature verification. Instead, it trusts the token's payload claims—specifically the phone_number and uid fields—without validating the JSON Web Token (JWT) signature or the issuer (iss) and audience (aud) claims. This means an attacker can craft a self-signed JWT or even a base64-encoded fake token containing an arbitrary phone number, send it to the authentication endpoint, and the plugin will accept it as legitimate.

The attack surface is the WordPress REST API, which is fully exposed to the internet by default. The relevant endpoints do not require authentication to reach the token-exchange function. The vulnerability class is CWE-287 (Improper Authentication), specifically a failure to validate a cryptographic signature, which allows authentication bypass.

The technical root cause is likely a missing or incorrectly implemented call to FirebaseAuth::verifyIdToken() or equivalent signature-checking logic. In vulnerable code paths, the plugin either calls FirebaseAuth::getUserByPhoneNumber() directly with unverified user input, or it passes token payload data to the WordPress user-lookup and session-creation functions without first confirming the token's authenticity via Firebase's public certificate chain.

Exploitation Scenarios

Scenario: Full Administrator Account Takeover

1. Reconnaissance (Target Identification): The attacker identifies a target WordPress site running the MStore API plugin. This can be done via fingerprinting—checking for the mstore-api plugin directory in page source, scanning for the plugin's REST API endpoints, or querying WordPress plugin version APIs. The attacker also needs a valid phone number for a target user with an administrator-level account. Phone numbers can be harvested from public sources, data breaches, or by observing the store's order data/shipping details if exposed.

2. Weaponization (Token Forge): The attacker crafts a forged Firebase ID token. Since the plugin doesn't verify the JWT signature, the attacker can:

   • Option A (Unsigned JWT): Construct a JWT with header {"alg":"none","typ":"JWT"}, payload {"sub":"attacker-controlled-uid","phone_number":"+15551234567","firebase":{"sign_in_provider":"phone"}}, and an empty signature. Many JWT libraries and the Firebase Admin SDK (when misconfigured) accept these.
   • Option B (Self-signed JWT): Generate a valid ECDSA or RSA key pair and self-sign the token. The plugin won't check the cryptographic chain anyway.
   • Option C (Base64-encoded JSON): If the plugin accepts raw JSON payloads, simply base64-encode the JSON payload without any signature.
   • The critical field is the target's phone_number claim, which the attacker sets to the victim's known phone number.

3. Trigger/Execution: The attacker sends an HTTP POST request to the plugin's authentication endpoint. Example request:

   POST /wp-json/mstore-api/v1/firebase-auth HTTP/1.1
   Host: target-site.com
   Content-Type: application/json
   
   {"idToken":"eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJwaG9uZV9udW1iZXIiOiIrMTU1NTEyMzQ1NjciLCJ1aWQiOiJhdHRhY2tlcl91aWQiLCJmaXJlYmFzZSI6eyJzaWduX2luX3Byb3ZpZGVyIjoicGhvbmUifX0."}
   

   The plugin parses the token, extracts phone_number, looks up the WordPress user associated with that phone number (stored as user meta), and creates an authenticated session (cookies + nonce) for that user.

4. Post-Exploitation: The attacker now has a fully authenticated session as the target user. If the target is an administrator, the attacker can:

   • Install malicious plugins/backdoors for persistent access.
   • Modify store prices/product data to defraud customers.
   • Exfiltrate the WordPress user database, customer PII, and payment metadata.
   • Plant crypto-miners or use the server as a relay for further attacks.
   • The attacker can also target any registered user with a known phone number, enabling wholesale account takeover of the entire user base.

The attack chain is fully remote, requires no privileges, and only requires the knowledge of one registered user's phone number to achieve complete site compromise.

Impact Assessment

Business Impact:

• Customer Data Breach: Full WooCommerce customer data (names, addresses, order histories, phone numbers, partial payment data) is exposed, triggering GDPR/CCPA/PDPA notification obligations and potential fines.
• Financial Fraud: Attackers can redirect payments, alter prices, or create fraudulent orders; in stores with stored payment tokens, financial loss can be severe.
• Reputation Damage: Mobile commerce platforms rely on customer trust; a visible account-takeover campaign destroys brand credibility.
• Operational Disruption: Full admin access enables site defacement, ransomware-style lockouts, or malicious script injection affecting all customers.

Affected Systems: Any WordPress installation with the MStore API plugin (versions < 4.21.0) — this plugin is primarily used by WooCommerce mobile commerce stores that offer iOS/Android shopping apps. The blast radius includes the WordPress core, all plugin data, WooCommerce store data, and any connected systems (payment gateways, CRM, email marketing).

Exploitability in the Wild: No public PoC or in-the-wild exploitation has been confirmed at the time of writing. The vulnerability has not been added to the CISA KEV catalog. The EPSS score is not yet available. However, the flaw is straightforward to weaponize for anyone with JWT knowledge, and the attack surface (public REST API) is massive, making proactive patching urgent.

Detection Guidance

The following detection content targets network-level and application-level indicators of exploitation attempts against CVE-2026-16030.

Sigma Rule

title: MStore API Firebase Auth Bypass Attempt
id: 7f3a9c2e-8d4b-4f1a-9c3e-5b2d8a6f7e10
status: experimental
description: Detects HTTP requests to MStore API Firebase auth endpoint with malformed or unsigned JWT tokens
author: Valters IT Security Research
date: 2026/02/15
tags:
    - attack.initial-access
    - attack.t1190
    - cve.2026.16030
logsource:
    category: webserver
    product: apache
    definition: 'Requires access logs with POST body or web application firewall logs'
detection:
    selection_uri:
        cs-method: 'POST'
        c-uri|contains:
            - '/wp-json/mstore-api/v1/'
            - 'firebase-auth'
            - 'phone-login'
    selection_payload:
        # Detect 'alg' header set to 'none'
        cs-body|contains:
            - 'eyJhbGciOiJub25l'  # base64 of {"alg":"none"
            - '"alg":"none"'
        cs-body|re: 'idToken.{0,500}(\.){2,3}'  # Empty or partial JWT signature section
    condition: selection_uri and selection_payload
    fields:
        - c-uri
        - src_ip
        - cs-body
        - cs-host
    falsepositives:
        - Legitimate mobile app users with properly configured Firebase SDK (unlikely to produce 'none' alg)
        - Development/testing environments
    level: high

YARA Rule

rule CVE_2026_16030_MStore_API_Token_Forge {
    meta:
        author = "Valters IT Security Research"
        description = "Detects forged Firebase JWT tokens targeting MStore API phone auth bypass"
        cve = "CVE-2026-16030"
        date = "2026-02-15"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-16030"
        score = 80
    strings:
        $json_key = "firebase-auth" ascii wide nocase
        $json_auth = "mstore-api" ascii wide nocase
        
        // Unsigned JWT header: {"alg":"none","typ":"JWT"}
        $none_alg_1 = "eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0" ascii wide  // standard base64
        $none_alg_2 = "eyJhbGciOiJub25lIiwidHlwIjoiand0In0" ascii wide  // lowercase typ variant
        $alg_none_json = "\"alg\":\"none\"" ascii wide nocase

        // Phone claim in JWT payload
        $phone_claim = "\"phone_number\"" ascii wide nocase
        $firebase_claim = "sign_in_provider" ascii wide nocase
        
        // Base64-encoded payload containing phone number
        $b64_phone = "cGhvbmVfbnVtYmVyIi" ascii wide  // base64 of "phone_number"

        // Endpoint pattern
        $endpoint_1 = "POST /wp-json/mstore-api/" ascii wide
        $endpoint_2 = "firebase-auth" ascii wide
    condition:
        uint16(0) == 0x0D0A and  // HTTP request
        (
            (2 of ($none_alg*) or $alg_none_json) and
            ($phone_claim or $b64_phone) and
            (1 of ($endpoint*))
        )
        or
        (
            $firebase_claim and
            $json_auth and
            1 of ($endpoint*) and
            ($none_alg_1 or $none_alg_2 or $alg_none_json)
        )
}

Suricata IDS Rule

alert http any any -> $HOME_NET any (msg:"CVE-2026-16030 - MStore API Firebase Auth Bypass - Unsigned JWT Attempt"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"mstore-api"; nocase; http.uri; content:"firebase"; nocase; http.request_body; content:"idToken"; nocase; http.request_body; content:"eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0"; nocase; within:200; http.request_body; content:"phone_number"; nocase; within:500; sid:2026160301; rev:1; reference:cve,2026-16030; classtype:attempted-admin; metadata:created_at 2026_02_15, updated_at 2026_02_15;)

alert http any any -> $HOME_NET any (msg:"CVE-2026-16030 - MStore API - Suspicious JWT with 'none' algorithm"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"mstore-api"; nocase; http.request_body; content:"\"alg\":\"none\""; nocase; http.request_body; content:"phone_number"; nocase; reference:cve,2026-16030; sid:2026160302; rev:1; reference:cve,2026-16030; classtype:attempted-admin; metadata:created_at 2026_02_15, updated_at 2026_02_15;)

alert http any any -> $HOME_NET any (msg:"CVE-2026-16030 - MStore API - Firebase Auth Without Signature (Double Dot JWT)"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"mstore-api"; nocase; http.uri; content:"firebase"; nocase; pcre:"/idToken\\\"?\s*[:=]\s*\\\"[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+\./U"; reference:cve,2026-16030; sid:2026160303; rev:1; reference:cve,2026-16030; classtype:attempted-admin; metadata:created_at 2026_02_15, updated_at 2026_02_15;)

Elastic Detection

sequence by source.ip with maxspan=2m
  [ network where event.type == "connection" and destination.port == 443 ]
  [ http where
      http.request.method == "POST" and
      url.path like "*mstore-api*" and
      url.path like "*firebase*" and
      // Look for JWT in POST body
      request.body.text : "idToken*" and
      (
        // Unsigned JWT (alg:none)
        request.body.text : "*eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0*" or
        request.body.text : "*\"alg\":\"none\"*" or
        // JWT with only two dots (empty signature)
        (
          request.body.text : "idToken*" and
          request.body.text : "*.*.*" and
          not request.body.text : "*.*.*.*"
        )
      ) and
      // Phone number claim present
      request.body.text : "*phone_number*"
    ]

Splunk SPL Query

index=web sourcetype=access_combined
| where method="POST"
| where uri LIKE "%mstore-api%"
| where uri LIKE "%firebase%"
| eval has_idToken=if(body LIKE "%idToken%", 1, 0)
| where has_idToken=1
| eval is_unsigned_jwt=if(body LIKE "%eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0%" OR body LIKE "%\"alg\":\"none\"%", 1, 0)
| eval phone_claim_present=if(body LIKE "%phone_number%" OR body LIKE "%cGhvbmVfbnVtYmVy%", 1, 0)
| where is_unsigned_jwt=1 AND phone_claim_present=1
| table _time, src_ip, dest_host, uri, body, http_user_agent
| sort - _time
| `ut_alert("MStore API FireBase Auth Bypass Attempt (CVE-2026-16030)")`

Wazuh OSSEC Rule

<group name="web,wordpress,mstore,cve_2026_16030,">
  <!-- Detect POST to MStore Firebase auth endpoint -->
  <rule id="913543" level="10">
    <if_sid>31510</if_sid> <!-- Apache POST -->
    <match>wp-json/mstore-api/v1/</match>
    <match>firebase</match>
    <description>CVE-2026-16030: MStore API Firebase auth endpoint accessed</description>
    <group>mstore_api,cve_2026_16030,</group>
  </rule>

  <!-- Detect unsigned JWT in request body -->
  <rule id="913544" level="14">
    <if_sid>2026301</if_sid>
    <regex>eyJhbGciOiJub25l</regex>
    <description>CVE-2026-16030: Unsigned JWT (alg:none) submitted to MStore API - likely exploit attempt</description>
    <group>mstore_api,cve_2026_16030,attack.initial_access,</group>
  </rule>

  <!-- Detect 'none' algorithm in JSON body -->
  <rule id="913545" level="14">
    <if_sid>2026301</if_sid>
    <regex>"alg"\s*:\s*"none"</regex>
    <description>CVE-2026-16030: JWT with 'none' algorithm submitted to MStore API - likely exploit attempt</description>
    <group>mstore_api,cve_2026_16030,attack.initial_access,</group>
  </rule>

  <!-- Detect phone number claim in request -->
  <rule id="913546" level="8">
    <if_sid>2026301</if_sid>
    <regex>phone_number</regex>
    <description>CVE-2026-16030: Phone number claim submitted to MStore API auth endpoint</description>
    <group>mstore_api,cve_2026_16030,</group>
  </rule>

  <!-- Combined: unsigned JWT + phone claim = high confidence exploit -->
  <rule id="913547" level="15" frequency="1">
    <if_sid>2026302,2026303</if_sid>
    <regex>phone_number</regex>
    <description>CVE-2026-16030: Confirmed exploit attempt - Forged Firebase token with phone claim targeting MStore API</description>
    <group>mstore_api,cve_2026_16030,attack.initial_access,attack.t1190,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch Confidence: 2/4 — CLAIMED. The fix is claimed by a single source (NVD). Patch details have not been independently verified by multiple researchers or vendor advisories. Exercise caution and verify with your own testing after upgrading.

1. Immediate Mitigations (If Patch Cannot Be Applied Immediately):

• Disable phone-based login: In MStore API settings, disable the Firebase phone authentication feature temporarily. This removes the vulnerable code path entirely.
• Restrict access to the REST API endpoint: Use a Web Application Firewall (WAF) or .htaccess rules to block external access to /wp-json/mstore-api/v1/ endpoints that contain "firebase" or "auth" in the path. Implement IP allowlisting for known mobile app infrastructure if feasible.
• Monitor authentication logs: Activate WordPress auth logging (e.g., Simple History plugin) and alert on new admin sessions during off-hours or from unexpected IPs.
• Implement WAF rule: Block POST requests containing JWT tokens with alg:none header or with only two dot-separated segments.

2. Patch/Upgrade Steps:

• Identify affected version: Check wp-content/plugins/mstore-api/readme.txt or the plugin version in the WordPress admin dashboard.
• Upgrade: Update the MStore API plugin to version 4.21.0 or later. This is the minimum patched version per the CVE description.
  • Composer: composer update (for Composer-managed WordPress installations), or use the WordPress dashboard's built-in update mechanism.
  • Manual: Download the latest plugin archive from the WordPress plugin repository or your vendor's portal and replace the plugin directory via FTP/SFTP. Backup the site and database before upgrading.
• Verify the update: After upgrading, confirm the plugin version reads 4.21.0+. Then test phone-based login flow on a staging environment to ensure Firebase token verification is now enforced.

3. Long-Term Hardening:

• Enforce signature verification: After upgrading, verify that the plugin now correctly validates Firebase ID token signatures by attempting to submit a forged token in a test environment — it should be rejected.
• Audit user database: After patching, audit administrator accounts for unexpected changes. Check for new admin users, modified password hashes, or anomalous user meta.
• Rotate credentials: If compromise is suspected, force password resets for all administrator accounts and revoke existing sessions via wp session tokens cleanup.
• Enable WordPress security hardening: Implement 2FA for all admin accounts, restrict admin access to known IPs, and deploy a web application firewall (e.g., Sucuri, Cloudflare, Wordfence).
• Credential management: Ensure Firebase project API keys and service account credentials are rotated if they were exposed in the plugin's configuration.
• Stay informed: Monitor the WordPress plugin repository changelog and security advisories (WPScan, Patchstack) for follow-up releases or additional details regarding this CVE.

References

1. NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2026-16030 — Official CVE record with CVSS vector, CWE classification, and NVD description.
2. WordPress Plugin Repository: https://wordpress.org/plugins/mstore-api/ — Official plugin source; check changelog for version 4.21.0 patch notes and release date.
3. Firebase Auth Documentation: https://firebase.google.com/docs/auth/admin/verify-id-tokens — Official verification guidance; references the correct Web API Key management and verifyIdToken method the plugin should have used.
4. CWE-287 Improper Authentication: https://cwe.mitre.org/data/definitions/287.html — MITRE weakness classification for this vulnerability.
5. WPScan Vulnerability Database (WPVDB): https://wpscan.com/vulnerabilities/CVE-2026-16030 — Third-party WordPress vulnerability tracker; check for further technical analysis and exploit reports as they become available.

Threat Actor Activity: As of this report's publication, no active campaigns or exploit-in-the-wild evidence has been publicly confirmed for CVE-2026-16030. The CVE has not been added to the CISA KEV catalog. However, given the attack's low complexity and high impact, this CVE should be treated as a high-priority patch target, anticipating weaponization in the near term once security researchers or malicious actors analyze the patched diff (4.21.0 vs. 4.20.x) to reverse-engineer the exact vulnerability mechanics.