CVE-2026-16038

Executive Summary

CVE-2026-16038 is an unauthenticated payment bypass vulnerability in the MStore API WordPress plugin, affecting all versions prior to 4.21.0. The plugin fails to verify payment completion with the payment gateway on multiple payment-completion endpoints, allowing any unauthenticated attacker to mark arbitrary orders as fully paid without rendering payment. This results in an order-level authorization bypass that enables the acquisition of goods or services for free, constituting a direct financial loss vector for WooCommerce-based stores using the MStore API plugin. The vulnerability is trivially exploitable over HTTP and does not require authentication, special privileges, or user interaction.

Technical Analysis

The MStore API plugin is a widely deployed WordPress extension that bridges native mobile applications (iOS/Android) to WooCommerce stores, exposing REST API endpoints that mirror WooCommerce functionality. Within the plugin's payment-handling architecture, specifically its multi-gateway payment completion flow, the plugin registers several endpoints that accept order completion callbacks from mobile clients. The vulnerability stems from a missing server-side verification step: when a request arrives at these payment-completion endpoints, the plugin marks the order status as "paid" based solely on the client-supplied order ID and a confirmation parameter, without contacting the actual payment gateway (Stripe, PayPal, Razorpay, etc.) to validate that a transaction was successfully processed.

From a code-level perspective, the flaw manifests in the controller methods handling the order-status transition. The endpoints, typically registered under the /wp-json/api/flutter_user/ and /wp-json/api/ namespaces with actions such as submit_order, pay_via_wallet, or gateway-specific handlers, execute a WooCommerce order status update via $order->update_status('processing' or 'completed') immediately upon receipt. The critical omission is the absence of a call to gateway-agnostic verification functions like WC()->payment_gateways()->get_available_payment_gateways() combined with $gateway->process_payment() or signature/Webhook validation checks. Consequently, an attacker constructs a valid JSON payload with the target order ID and a forged or arbitrary status flag; the server processes this and flips the order lifecycle without any financial reconciliation.

The attack surface is the unauthenticated WordPress REST API, which is publicly accessible by default. The affected endpoints accept standard REST requests with JSON content types, meaning the vulnerability is exploitable directly via HTTP(S) POST requests with no API keys or nonce tokens required. The plugin's version history shows the flaw existed in all releases before 4.21.0, with the patch introducing mandatory gateway transaction verification and order state validation.

Exploitation Scenarios

Stage 1 — Reconnaissance and Target Identification: An attacker enumerates WooCommerce sites running the MStore API plugin. Techniques include querying the WordPress REST API for the plugin's routes (/wp-json/ and probing known MStore endpoints), scanning for mobile app-associated subdomains (api., mapi., etc.), or using search engines to discover stores with the plugin's distinctive mobile app manifest files. Shodan or Censys can identify exposed WordPress installations; the plugin's endpoints are then fingerprinted by sending a benign GET request to /wp-json/api/flutter_user/ and observing the response schema.

Stage 2 — Order Targeting and Payment Bypass Trigger: The attacker initiates a normal checkout on the victim store using a guest account, placing a high-value item (e.g., a laptop, digital download, or subscription) in the cart and proceeding to the order confirmation step. They note the generated WooCommerce Order ID (e.g., Order #10429), which may be surfaced in the client-side response or via a subsequent order-lookup API call. Alternatively, the attacker can use a different low-value account to first create an order and then discover valid order IDs via sequential enumeration — order IDs in WooCommerce are auto-incremented integers, making them highly predictable.

Stage 3 — Weaponization and Payload Execution: The attacker crafts a POST request to the vulnerable payment-completion endpoint. The specific endpoint is one of the affected handlers, such as /wp-json/api/flutter_user/submit_order (or the gateway-specific variant like pay_stripe / verify_payment), with a JSON body resembling:

{
  "order_id": 10429,
  "status": "processing",
  "payment_method": "cod",
  "payment_result": "success"
}

No payment gateway callback is involved; the plugin processes the order_id parameter and marks the order paid. Using curl:

curl -X POST https://victim-store.com/wp-json/api/flutter_user/submit_order \
  -H "Content-Type: application/json" \
  -d '{"order_id":10429,"status":"processing","payment_method":"cod","payment_result":"success"}'

The server responds with an HTTP 200 and a JSON success flag. The order transitions to processing (or completed), triggering WooCommerce's stock decrement, order-notification emails to the store owner, and fulfillment pipeline activation.

Stage 4 — Post-Exploitation Impact: The attacker receives the shipped goods, digital delivery links (for downloadable products), or service activation. To maximize yield, the attacker repeats the process across a range of order IDs or creates multiple fresh orders, each bypassing payment. In high-traffic stores, they may target orders placed by other customers, hijacking the fulfillment of legitimate purchases. The attacker remains undetected because no payment failures are logged and the order appears normally paid in the WooCommerce admin dashboard.

Impact Assessment

The CVSS score is N/A per the CNA, but the qualitative severity is rated Critical (9.8 on the CVSS v3.1 scale when extrapolated: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). The business impact is direct revenue loss: every exploited order represents an unrecovered transaction cost (goods, shipping, payment processing fees, and operational overhead). Beyond immediate financial loss, the vulnerability enables systematic inventory shrinkage, digital content theft, fraudulent service provisioning, and abuse of promotional/one-time-use codes. For stores with high-volume order processing, the blast radius extends to operational disruption, as a coordinated attack can flood the fulfillment queue with fake orders, overwhelming staff and logistics partners.

The affected systems are any WooCommerce deployments with the MStore API plugin below 4.21.0, particularly those with mobile apps, multi-vendor marketplaces, or digital product shops, as these accept the exposed REST endpoints. The confidentiality impact is low (order metadata exposure is implicit), but integrity and availability are severely compromised — order integrity is invalidated, and availability can be degraded through resource exhaustion. There is no lateral movement potential or server compromise; the vulnerability is confined to the WordPress/WooCommerce order-processing domain.

Detection Guidance

Sigma Rule

title: MStore API Unauthenticated Payment Bypass Attempt
id: 9be3f9c2-1d56-4f7e-8f42-1a6fbe79b3f5
status: experimental
description: Detects POST requests to MStore API payment completion endpoints that attempt to mark orders as paid without gateway verification.
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2026-16038
author: Valtersit Threat Intel Team
date: 2026/05/10
logsource:
    category: webserver
    product: apache
    definition: 'WordPress access logs or WAF logs with URL and POST body decoding.'
detection:
    selection:
        cs-method: POST
        cs-uri-query|contains:
            - '/wp-json/api/flutter_user/submit_order'
            - '/wp-json/api/flutter_user/pay_via_wallet'
            - '/wp-json/api/flutter_user/pay_stripe'
            - '/wp-json/api/flutter_user/verify_payment'
            - '/wp-json/api/flutter_user/razorpay'
    filter:
        cs-uri-query|contains:
            - '/wp-json/api/flutter_user/submit_order?'
        cs-referer|contains:
            - 'wp-admin'
            - 'mobile-app'
    condition: selection and not filter
falsepositives:
    - Legitimate mobile app checkout requests from genuine users using the official app.
    - Admin-initiated order completion via the plugin's admin panel (if the admin uses the same REST route).
level: high

YARA Rule

rule MStore_API_Payment_Bypass_Payload {
    meta:
        author = "Valtersit Threat Intel"
        description = "Detects HTTP POST payloads targeting MStore API payment endpoints for order status manipulation"
        cve = "CVE-2026-16038"
        date = "2026-05-10"
    strings:
        $endpoint1 = "/api/flutter_user/submit_order" ascii wide nocase
        $endpoint2 = "/api/flutter_user/pay_via_wallet" ascii wide nocase
        $endpoint3 = "/api/flutter_user/pay_stripe" ascii wide nocase
        $order_param = "order_id" ascii wide nocase
        $status_param = "\"status\"" ascii wide
        $payment_result = "payment_result" ascii wide nocase
        $success_value = "\"success\"" ascii wide
        $processing_value = "\"processing\"" ascii wide
        $json = "Content-Type: application/json" ascii wide nocase
    condition:
        uint16(0) == 0x0a0d and
        1 of ($endpoint*) and
        $order_param and
        ($status_param and ($processing_value or $success_value)) and
        $json
}

Suricata IDS Rule

alert http any any -> $HOME_NET any (msg:"CVE-2026-16038 MStore API Payment Bypass Attempt"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/wp-json/api/flutter_user/"; distance:0; pcre:"/(submit_order|pay_via_wallet|pay_stripe|verify_payment|razorpay)/i"; content:"order_id"; nocase; http.client_body; content:"status"; nocase; http.client_body; content:"processing"; nocase; http.client_body; reference:cve,2026-16038; classtype:attempted-admin; sid:10026038; rev:1;)

Elastic Detection

sequence by source.ip with maxspan=1m
  [network where event.category == "network" and network.protocol == "http" and
   http.request.method == "POST" and
   url.path like~ "*/wp-json/api/flutter_user/*" and
   (url.path like~ "*submit_order*" or url.path like~ "*pay_via_wallet*" or
    url.path like~ "*pay_stripe*" or url.path like~ "*verify_payment*")]
  [http where http.request.body.content like~ "*order_id*" and
   http.request.body.content like~ "*status*" and
   (http.request.body.content like~ "*processing*" or http.request.body.content like~ "*success*")]

Splunk SPL Query

index=web sourcetype=access_combined
| where method="POST" AND (uri_path LIKE "%/wp-json/api/flutter_user/%")
| rex field=uri_path "(?<mstore_endpoint>submit_order|pay_via_wallet|pay_stripe|verify_payment|razorpay)"
| search mstore_endpoint=*
| rex field=_raw "(?<body_bytes>\{[^}]*\})"
| where match(body_bytes, "order_id") AND match(body_bytes, "(processing|success)")
| stats count by src_ip, uri_path, status, _time
| sort - _time
| rename src_ip AS "Source IP", uri_path AS "MStore Endpoint", status AS "HTTP Response"

Wazuh OSSEC Rule

<group name="wordpress,web_attack,">
  <rule id="538638" level="15">
    <decoded_as>json</decoded_as>
    <field name="method">POST</field>
    <match>/wp-json/api/flutter_user/</match>
    <regex>/(submit_order|pay_via_wallet|pay_stripe|verify_payment|razorpay)</regex>
    <field name="url">.*</field>
    <description>MStore API payment bypass attempt (CVE-2026-16038)</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>cve-2026-16038,payment_bypass,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 2/4 (CLAIMED — single source claims patch, not independently confirmed). NVD asserts the fix exists in version 4.21.0.

1. Immediate mitigations (until patched):

   • Disable all mobile app checkout functionality by deactivating the MStore API plugin if alternative checkout channels exist. This is the only guaranteed remediation without the patch.
   • If deactivation is not viable, block external network access to the REST endpoints using a WAF rule that denies POST requests to paths matching /wp-json/api/flutter_user/*. Apply this rule only to non-authenticated traffic, allowing internal or admin access if necessary.
   • Enable WooCommerce "Hold Stock" for a prolonged period (e.g., 7 days) to prevent unauthorized orders from being fulfilled before manual payment verification. Audit all orders in processing status for the last 30 days; any order without a corresponding gateway transaction record should be refunded/cancelled.
   • Restrict the REST API using a plugin like "Disable REST API" or IP allowlisting for the mobile app's backend IP ranges, if the app is server-issued.

2. Patch/upgrade steps:

   • Upgrade the MStore API plugin to version 4.21.0 or later. This is available via the WordPress admin dashboard (Plugins → Installed Plugins → MStore API → Update) or via Composer if managed that way: composer require inspry/plugin-mstore-api:^4.21.0 (fictional package name — verify vendor package name from your lock file).
   • After upgrading, verify the patch by re-testing the payment bypass: place a test order with a sandbox payment gateway and confirm the plugin now requires a valid gateway transaction reference before updating the order status.
   • Check the plugin's change log to confirm the patch introduces gateway verification calls (process_payment / webhook signature checks) and order-state transition validation.

3. Long-term hardening:

   • Implement server-side REST API request validation: ensure all WooCommerce order-state changes are initiated only from trusted gateway webhook endpoints, not client-supplied REST calls.
   • Add a Snort/Suricata signature (see above) to your IDS and alert on any POST to the MStore endpoints that does not originate from your legitimate mobile app's backend proxy.
   • Conduct a quarterly audit of all WooCommerce REST API routes, disabling any that are not strictly required by the active theme or plugins.
   • Establish a patch management SLA for WordPress plugins: critical-severity CVEs (CVSS ≥ 9.0) must be patched within 24 hours of public disclosure.
   • Monitor FIRST.org EPSS scores for this CVE once published to prioritize remediation in an environment with multiple competing vulnerabilities.

References

1. NVD Entry for CVE-2026-16038: https://nvd.nist.gov/vuln/detail/CVE-2026-16038
2. WordPress Plugin Repository (MStore API): https://wordpress.org/plugins/mstore-api/ (changelog for 4.21.0)
3. Vendor Advisory / Patch Notes: https://inspireui.com/ (plugin vendor changelog — inspect 4.21.0 release notes)
4. CWE-425: Direct Request Forced Browsing (related weakness class): https://cwe.mitre.org/data/definitions/425.html
5. MITRE ATT&CK Technique T1190 (Exploit Public-Facing Application): https://attack.mitre.org/techniques/T1190/

Threat actor intelligence: As of this writing, there are no confirmed exploit-in-the-wild campaigns attributed to this CVE, and it is not listed on the CISA KEV. However, the trivial exploitation mechanism (a simple authenticated-adjacent POST request with known order ID enumeration) makes it highly likely that opportunistic credit-card fraud groups will weaponize it within days of public disclosure. The plugin's popularity in Southeast Asia and Latin America e-commerce markets suggests targeted campaigns against high-volume mobile-first stores are probable.