GHSA-w5v4-5p65-83xj: 
PHP vulnerability analysis and mitigation

Summary

The close REST endpoint of the BitPay Magento 2 plugin did not require authentication. With the default settings, anyone could delete any order in the store by sending its order number. Fixed in 10.2.3.

Details

GET /rest/V1/bitpay-bpcheckout/close is declared with the anonymous resource in etc/webapi.xml, so anyone can call it. Model/IpnManagement.php::postClose() loaded the order from the orderID parameter and deleted it when Invoice Close Handling was set to Delete Order, which is the default value in etc/config.xml. It did not check who sent the request, which payment method the order used, or whether the order was already paid.

Patches

Fixed in 10.2.3. The endpoint now requires the order's return hash, only works on BitPay orders, and only deletes orders that are still unpaid in Magento and in BitPay.

Workarounds

Until you can upgrade, go to Stores > Configuration > Sales > Payment Methods > BitPay and set Invoice Close Handling to Keep Order. With this setting the endpoint does not delete orders. If you cannot upgrade, set Invoice Close Handling to Keep Order. The close endpoint will then stop deleting orders.

Proof of concept

1. Install the plugin (10.2.2 or earlier) with the default configuration.
2. Place any order in the store and note its order number (increment ID).
3. Without logging in, send a GET request to /rest/V1/bitpay-bpcheckout/close?orderID=<order number>.
4. The order is deleted from the store, even if it was paid or used another payment method.

Impact

Missing authentication on a destructive action (CWE-306, CWE-639). Any Magento 2 store running the BitPay plugin up to 10.2.2 with the default Invoice Close Handling setting is affected. An unauthenticated attacker can delete orders, including paid orders and orders paid with other payment methods. Order numbers are sequential, so they are easy to guess. Stores lose order records and may not be able to fulfil paid orders.