| Titre | macrozheng mall 1.0.3 Race Condition |
|---|
| Description | A race condition vulnerability exists in the order submission process of mall version 1.0.3 (and likely later versions). When two users concurrently place orders for the same product, the system fails to synchronize updates to the `lock_stock` field in the `pms_sku_stock` table. The code reads the current `lock_stock` value, increments it in memory, and writes it back without using row-level locks or atomic updates. This allows two concurrent requests to read the same initial value (e.g., 0), both increment to 1, and both write 1, resulting in a lost update. Consequently, two orders can be created for a product with only one available unit, leading to overselling. This can cause financial loss and customer dissatisfaction. Proof of concept: set stock=1, lock_stock=0, then send concurrent POST requests to `/order/submit` from two different authenticated users. Both orders succeed, but lock_stock becomes 1 instead of 2, and two orders exist for the same product. The issue is due to improper synchronization (CWE-362). A fix would be to use an atomic SQL update (`UPDATE pms_sku_stock SET lock_stock = lock_stock + 1 WHERE id = ?`) or to apply row-level locking within a transaction. |
|---|
| La source | ⚠️ https://github.com/macrozheng/mall/issues/983 |
|---|
| Utilisateur | Anonymous User |
|---|
| Soumission | 13/07/2026 06:26 (il y a 2 mois) |
|---|
| Modérer | 28/08/2026 21:00 (2 months later) |
|---|
| Statut | Accepté |
|---|
| Entrée VulDB | 396780 [macrozheng mall jusqu’à 1.0.3 Order Submission /order/submit race condition] |
|---|
| Points | 20 |
|---|