Inspireui MStore API – Create Native Android & iOS Apps On The Cloud vulnerabilities
🔔 Create alert RSS Version checker
Published CVEs affecting Inspireui MStore API – Create Native Android & iOS Apps On The Cloud: 2 record(s), with affected versions and fixes.
CVE-2026-13447
Critical · 9.8
CWE-287 Sep 5, 2026
MStore API <= 4.20.0 - Unauthenticated Authentication Bypass via 'id_token' Parameter JWT Forgery
The Mstore Api plugin for WordPress is vulnerable to Authentication Bypass via JWT Forgery in versions up to, and including, 4.20.0 This is due to missing cryptographic signature verification in the FirebasePhoneAuthHelper::verify_id_token() function, which decodes and validates Firebase ID token claims (alg, kid, aud, iss) but never calls openssl_verify() or any equivalent to validate the JWT signature against Google's actual public key certificates. This makes it possible for unauthenticated attackers to forge a Firebase Phone Auth JWT signed with a self-generated RSA key pair and impersonate any phone number, resulting in unauthorized access to existing WordPress accounts or creation of new arbitrary accounts.
CVE-2026-3568
Medium · 4.3
CWE-639 Apr 9, 2026
MStore API <= 4.18.3 - Authenticated (Subscriber+) Insecure Direct Object Reference to Arbitrary User Meta Update
The MStore API plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 4.18.3. This is due to the update_user_profile() function in controllers/flutter-user.php processing the 'meta_data' JSON parameter without any allowlist, blocklist, or validation of meta keys. The function reads raw JSON from php://input (line 1012), decodes it (line 1013), authenticates the user via cookie validation (line 1015), and then directly iterates over the user-supplied meta_data array passing arbitrary keys and values to update_user_meta() (line 1080) with no sanitization or restrictions. This makes it possible for authenticated attackers, with Subscriber-level access and above, to modify arbitrary user meta fields on their own accounts, including sensitive fields like wp_user_level (to escalate to administrator-level legacy checks), plugin-specific authorization flags (e.g., _wpuf_user_active, aiowps_account_status), and billing/profile fields with unsanitized values (potentially enabling Stored XSS in admin contexts). Note that wp_capabilities cannot be directly exploited this way because it requires a serialized array value, but wp_user_level (a simple integer) and numerous plugin-specific meta keys are exploitable.