Description

The MStore API WordPress plugin before 4.21.1 does not verify that the order targeted by one of its delivery endpoints belongs to the requester, allowing any authenticated user, including Subscribers, to mark arbitrary orders as completed and paid without any payment being made.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-08-29T06:17:16.007Z",
  "pubdate": "2026-08-29T06:17:16.007Z",
  "executiveSummary": "The MStore API WordPress plugin contains a critical Improper Authorization vulnerability that allows authenticated users to manipulate order statuses.\nThis vulnerability stems from a failure to validate ownership during the execution of specific order delivery API endpoints.\nAny authenticated user, including those with minimal privileges such as Subscribers, can force arbitrary orders to a 'completed' or 'paid' status.\nThis flaw facilitates unauthorized financial bypass, as the system does not verify the receipt of valid payment before updating the order state.\nThe risk implication is significant, as it enables attackers to effectively steal digital or physical goods by manipulating the back-end order fulfillment process without legitimate transaction processing.\nExploitation requires only authenticated access to the target WordPress instance, necessitating no elevated privileges beyond standard subscriber-level access.\nThe vulnerability affects all versions of the MStore API plugin prior to 4.21.1.",
  "technicalDetails": "The vulnerability resides within the MStore API plugin's delivery processing logic, specifically affecting the API endpoints responsible for order status transitions.\nThe root cause is a Broken Access Control (BAC) vulnerability where the application performs server-side state changes based on user-supplied order identifiers without verifying the relationship between the authenticated user account and the target order object.\nDuring the request lifecycle, the API endpoint receives an order ID as an input parameter. The backend logic proceeds to update the database state of the order to 'completed' or 'paid' upon receipt of the request. Because the underlying function fails to implement an authorization check (e.g., checking if the 'user_id' associated with the order matches the 'ID' of the current session user), the system blindly trusts the input provided by the client.\nAttack flow: An authenticated attacker identifies the order ID of a target transaction (which may be predictable or discoverable via enumeration). The attacker crafts a request targeting the vulnerable delivery endpoint, injecting the target order ID into the request payload. Upon processing, the MStore API plugin updates the order record in the database. The system then triggers associated order completion workflows—such as granting access to digital downloads or notifying warehouse fulfillment systems—as if a legitimate payment event had been successfully validated by the payment gateway.\nThis behavior bypasses all payment gateway verification steps, rendering payment integration modules ineffective against an attacker who can directly manipulate the API status triggers. The attack is restricted to authenticated users but maintains a low barrier to entry, as subscriber-level accounts are often publicly available via self-registration.\nThe impact is a complete breakdown of order integrity and authorization logic. Post-exploitation, an attacker successfully illicitly acquires goods or services, causing financial loss to the merchant and potentially compromising inventory management data. The vulnerability is highly exploitable in any environment where the plugin is active, provided the attacker maintains an active session with the WordPress site."
}