MStore API EUVD-2026-91216

Requires a store running the MStore API plugin (versions before 4.22.1) with customer self-registration enabled - the default for most WooCommerce storefronts - and the attacker must first create an order so there is an unpaid order to manipulate. The vulnerability is that the order-update endpoint does not restrict which order fields a customer may modify, so no admin rights or victim interaction are needed; exploitation is limited only by needing a valid (self-registerable) authenticated account (PR:L) and an existing unpaid order belonging to the attacker. Impact is confined to the attacker's own orders, bounding the blast radius to payment fraud rather than account takeover or data exposure.

This is a moderate-risk broken access control (business logic / improper authorization) flaw, not a classic memory-corruption bug. The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N = 4.3 Medium) is internally consistent with the description: network-reachable, low complexity, and requiring only a low-privilege account that the description confirms is self-registerable, with limited integrity impact and no confidentiality or availability loss. Publicly available exploit code exists (WPScan), which raises practical exploitability, but there is NO CISA KEV listing and NO EPSS score provided, so there is no evidence of active, widespread exploitation at time of analysis - treat this as 'POC available, exploitation not confirmed.' The real-world impact is financial fraud (obtaining goods without payment) rather than system compromise, which is why the CVSS stays Medium despite trivial exploitability; prioritize for e-commerce sites running the plugin, but it is not a drop-everything RCE. Note a minor signal conflict: the input Tags label this 'Information Disclosure,' which contradicts the description - this is an authorization/order-tampering (integrity) issue, so defenders should not triage it as a data-leak bug.

An attacker self-registers a customer account on a WooCommerce store exposed through the MStore API plugin, places an order, and leaves it unpaid. Using the publicly available WPScan proof-of-concept, they send a crafted order-update API request that modifies the status field of their own order to 'paid' or 'completed,' causing the store to fulfill and ship the goods without any payment being received.