Low-level logic flaw

 This vulnerability demonstrates a low-level logic flaw caused by integer overflow, where the application incorrectly handles numeric limits in its backend pricing calculations. Instead of safely validating or constraining arithmetic operations, the system uses a fixed-size integer type, which can overflow when pushed beyond its maximum allowed value, resulting in unexpected negative values and broken pricing logic.

The issue begins during the normal checkout flow, where the user attempts to purchase a high-value item (the leather jacket). The application correctly rejects the order initially due to insufficient store credit. However, by intercepting the request flow using Burp Suite, the user observes that the quantity parameter in the POST /cart request is restricted to a two-digit value. This suggests a superficial client-side or input-layer restriction, but not a true backend limitation.

By sending the request to Burp Intruder, the quantity parameter is aggressively manipulated. A high value such as 99 is repeatedly submitted in rapid succession using a “null payload” attack configuration. This causes the server to continuously update the cart total without proper safeguards on cumulative calculations. Since the backend stores the price in cents (for example, 133700 cents for the leather jacket), each request multiplies this value by the quantity and adds it to a running total.

As the attack continues, the total price grows rapidly and eventually exceeds the maximum value allowed by a 32-bit signed integer (2,147,483,647). At this point, the system experiences integer overflow, causing the value to wrap around into the negative range (starting from -2,147,483,648). Instead of handling this condition safely, the application continues processing the corrupted value as if it were valid.

This overflow behavior is critical because it breaks the integrity of the pricing system. A value that should represent a large positive cost suddenly becomes negative, effectively turning the cart total into a credit rather than a debt. The user can observe the price fluctuating and eventually stabilizing in a negative range as more requests are processed.

To exploit this further, the attack is refined by controlling the number of payloads and limiting request concurrency to ensure predictable overflow behavior. After generating a precise number of requests, the cart reaches a state where the total becomes significantly negative (e.g., around -$1221.96). At this stage, the attacker can adjust quantities of additional items to bring the total back into a valid range between $0 and $100, which matches the available store credit.

Finally, the manipulated cart is submitted successfully, allowing the purchase of high-value items without sufficient funds. This confirms that the system does not properly validate numeric boundaries or protect against arithmetic overflow conditions in critical business logic.

The root cause of this vulnerability is the use of fixed-size integer types without proper boundary checks or overflow protection. The backend likely performs arithmetic operations directly on integer values without using safe data types (such as arbitrary-precision integers) or validating intermediate results. A secure implementation would enforce strict limits on quantity multiplication, validate totals after each operation, and ensure that any overflow condition immediately triggers an error rather than silently wrapping around.

This flaw highlights a deeper issue in application security: low-level data representation can directly impact business logic integrity. Even if authentication and access control are correctly implemented, unsafe arithmetic operations can completely break financial systems. Proper safeguards such as input validation, range checks, and safe numeric handling are essential to prevent exploitation of integer overflow vulnerabilities.