CVE-2026-18233 in MStore API Plugin
Summary
by MITRE • 08/29/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/29/2026
The vulnerability identified in MStore API for WordPress prior to version 4.21.1 represents a critical failure in server-side access control mechanisms, specifically manifesting as an Insecure Direct Object Reference (IDOR) within the plugin's order management endpoints. This flaw arises from the application logic failing to validate that the authenticated user initiating the request is the legitimate owner of the specific order resource being targeted for modification. By relying solely on client-supplied identifiers or session context without cross-referencing against a secure authorization database, the system allows any logged-in individual to manipulate state-critical data associated with other users' transactions. This architectural deficiency effectively bypasses the intended isolation boundaries between different user roles and accounts within the e-commerce ecosystem.
From an operational perspective, this vulnerability enables authenticated attackers, including those with the lowest privilege level such as Subscribers, to arbitrarily mark any order in the system as completed and paid without executing a corresponding financial transaction. This action has severe implications for business integrity, as it artificially inflates sales metrics, disrupts inventory management systems that rely on accurate order status updates, and potentially triggers fulfillment workflows for items that have not been purchased or paid for. The ability to falsify payment status undermines the trustworthiness of the entire commerce platform, leading to potential financial losses through stock depletion without revenue generation and complicating accounting reconciliation processes due to discrepancies between recorded sales and actual bank deposits.
The technical classification of this flaw aligns with CWE-284, which describes Improper Access Control, specifically highlighting the failure to enforce proper restrictions on authorized users accessing specific data objects. Furthermore, in the context of offensive security frameworks such as MITRE ATT&CK, this behavior corresponds to techniques involving Account Manipulation and Data Injection, where an adversary alters system state to achieve persistence or disrupt operations without detection through standard authentication logs alone. The exploitation requires only valid credentials for any user account, making it accessible to a broad range of potential threat actors who may have obtained low-level access through credential stuffing, phishing, or public registration forms.
Mitigation strategies must prioritize the immediate implementation of robust server-side authorization checks that verify ownership relationships before processing state-changing requests. Developers should ensure that every API endpoint handling sensitive resources like orders explicitly validates that the user ID associated with the active session matches the owner field within the order database record. Additionally, implementing principle of least privilege by restricting high-impact actions to administrative roles can reduce the blast radius if such vulnerabilities persist in legacy code paths. Upgrading to version 4.21.1 or later is essential as it addresses these logic flaws through corrected access control policies that enforce strict validation of resource ownership during API interactions, thereby restoring the integrity of the order processing workflow and preventing unauthorized status modifications.