CVE-2026-97219 in MStore API Plugin
Summary
by MITRE • 10/02/2026
The MStore API WordPress plugin before 4.22.1 does not restrict which fields of an order a customer may update, allowing any authenticated user with a self-registerable account to change the status of their own unpaid order to a paid or fulfilled state and receive the goods without paying.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/02/2026
The vulnerability identified in MStore API versions prior to 4.22.1 represents a critical business logic flaw rooted in insufficient input validation and authorization checks within the RESTful application programming interface. This issue specifically affects authenticated users who possess self-registerable accounts, which is a common configuration for e-commerce platforms that allow guest checkout or easy account creation. The core technical failure lies in the API endpoint responsible for updating order details, where the server fails to enforce strict field-level access controls. Instead of restricting updates to only those fields explicitly intended for customer modification, such as shipping address changes or payment method selection, the system inadvertently exposes internal administrative states like order status and fulfillment flags to user input. This lack of granularity in permission enforcement allows a malicious actor to manipulate critical transactional data that should be exclusively managed by backend administrators or automated payment processing systems.
From an operational perspective, this vulnerability enables direct financial loss through fraud. An attacker can authenticate into the platform using a standard customer account and then send a crafted API request to modify their own order records. By changing the status of an unpaid order from pending or processing to paid, completed, or fulfilled, the system erroneously triggers downstream processes such as inventory deduction, shipping label generation, and dispatch workflows. Consequently, the attacker receives goods without ever initiating a legitimate payment transaction through the integrated gateway. This bypasses not only the immediate financial exchange but also circumvents fraud detection mechanisms that typically rely on verifying successful payment callbacks before fulfilling orders. The impact is severe for merchants relying on this plugin, as it directly compromises revenue integrity and operational efficiency by forcing manual intervention to reverse fraudulent shipments or cancel invalid orders.
This flaw aligns with CWE-269, which describes Improper Privilege Control, specifically where a user can perform actions beyond their authorized scope due to flawed access control logic. Furthermore, the exploitation technique maps closely to MITRE ATT&CK tactic T1078, Valid Accounts, as it leverages legitimate credentials to abuse system functionality rather than exploiting code execution vulnerabilities. The attack vector is classified under remote non-persistent impact because no shell or persistent backdoor is installed; instead, the attacker exploits a logical misconfiguration within the application layer. This distinction highlights that traditional web application firewalls may not detect this activity if it originates from valid IP addresses and uses standard authentication tokens, making behavioral analysis essential for detection.
Mitigation strategies must prioritize immediate patching to version 4.22.1 or later, where these field restrictions have been implemented by the developers. In environments where upgrading is temporarily unfeasible, administrators should implement strict server-side validation that whitelists only permissible fields for customer-facing API endpoints. It is crucial to ensure that state-changing operations like order status updates are restricted to internal services or administrative roles with elevated privileges. Additionally, implementing compensating controls such as requiring payment gateway confirmation before triggering fulfillment workflows can provide a secondary layer of defense. Monitoring logs for unusual patterns in order status changes, particularly those occurring immediately after account creation without corresponding payment transactions, will aid in early detection and response to potential exploitation attempts.