macrozheng mall CVE-2026-108784

Requires a deployment of macrozheng mall (≤1.0.3) with the Alipay payment integration configured and enabled, and an attacker able to initiate a payment for a valid order - i.e. a customer account with an existing order number (outTradeNo). The attacker must manipulate the total_amount field in the pay/webPay request so the amount sent to Alipay differs from the server-side order amount; vulnerable code trusts aliPayParam.getTotalAmount() instead of the database payAmount. Limiting factors: Alipay must be live (not a demo/sandbox-only install), the attacker needs a legitimate order context to supply a matching outTradeNo, and impact is confined to monetary/order-integrity abuse (no code execution, no data exposure).

This is a payment-amount tampering / business-logic flaw (CWE-840) confirmed by the vendor patch diff: AlipayServiceImpl.pay and webPay previously passed the client-supplied aliPayParam.getTotalAmount() straight into the Alipay bizContent as total_amount, and the fix replaces it with the authoritative payAmount read from the order record in the database. The provided CVSS 4.0 vector (AV:N/AC:L/PR:N/UI:N, VC:N/VI:L/VA:L, score 6.9, E:P) indicates a network-reachable, low-complexity issue with integrity-only impact and a proof-of-concept exploit - not a code-execution or data-breach bug. Signals are consistent but modest: POC availability is confirmed (GitHub issue #998), yet there is NO CISA KEV listing and NO EPSS score in the input, so there is no evidence of widespread automated exploitation - treat this as a targeted financial-abuse risk rather than a mass-exploitation priority. One signal to verify: the input vector asserts PR:N, but initiating an Alipay payment realistically requires an authenticated customer with an existing order (outTradeNo), so the true privilege requirement is likely PR:L - this lowers real-world exposure versus a pure unauthenticated flaw. EPSS data is missing and should be checked before final prioritization.

A registered customer of a mall-based storefront creates a legitimate order, then intercepts or crafts the Alipay payment initiation request and sets total_amount to an arbitrary low value (e.g. 0.01) while keeping the real order number; because the server trusts the client-supplied amount, the payment gateway charges the reduced amount and the order is processed as paid. A public proof-of-concept is available via the project's GitHub issue tracker, factoring in the network attack vector and low complexity of simply altering one request parameter.