| عنوان | macrozheng mall 1.0.3 Race Condition |
|---|
| الوصف | 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. |
|---|
| المصدر | ⚠️ https://github.com/macrozheng/mall/issues/983 |
|---|
| المستخدم | Anonymous User |
|---|
| ارسال | 13/07/2026 06:26 AM (2 أشهر منذ) |
|---|
| الاعتدال | 28/08/2026 09:00 PM (2 months later) |
|---|
| الحالة | تمت الموافقة |
|---|
| إدخال VulDB | 396780 [macrozheng mall حتى 1.0.3 Order Submission /order/submit حالة سباق] |
|---|
| النقاط | 20 |
|---|