Price Manipulation

What is Price Manipulation#

Price manipulation is a business logic vulnerability in which an application accepts a monetary value — price, unit_price, amount, total, or subtotal — directly from a client request and uses that value as the authoritative cost of a transaction. Because the value is supplied by the client, an attacker can intercept the request in a proxy, change price=49900 to price=1, and complete the purchase at one cent. The server never re-validates the value against its own product catalog. This is catalogued as CWE-840 (Business Logic Errors) with a contributing CWE-20 (Improper Input Validation) weakness, and falls under OWASP A04:2021 — Insecure Design.

The vulnerability is invisible to traditional injection scanners. No payload causes a 500 error. No regex matches a malicious string. The request is syntactically and semantically valid — it just happens to contain a number the developer never intended to be writable. Detection requires reasoning about the intent of each field, which is why DAST tools and WAFs both miss it. Manual penetration testers and business-logic-aware scanners catch it by intercepting the checkout flow and modifying numeric fields one at a time.

The financial exposure scales with order volume. A single undetected flaw on a high-traffic e-commerce platform can produce six-figure losses before reconciliation surfaces the discrepancy. This is why the HackerOne Business Logic top-payout list consistently places price manipulation in the top five most rewarded subtypes, and why Shopify-context disclosures have historically earned $25,000 to $150,000 depending on whether the flaw affects a single store or platform-wide checkout.

Mechanism#

The exploit relies on a single broken trust boundary: the server delegates pricing authority to the client. The flow is identical across hidden-form, REST, and GraphQL stacks.

The attack collapses to four deterministic steps:

1. The user adds an item via the normal UI; the browser issues a POST that includes the price the page rendered.
2. An intercepting proxy (Burp, Caido, mitmproxy) holds the request and the attacker rewrites the price field to an arbitrary value.
3. The server inserts the cart line item using the supplied price as unit_price, never querying its own product catalog.
4. Checkout sums line items and charges the resulting total — already poisoned with the attacker-supplied number.

The canonical vulnerable request, captured against a real e-commerce stack:

POST /api/cart/add HTTP/2
Host: shop.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGc...
Cookie: session=abc123
 
{
  "product_id": "jacket-heavyweight-001",
  "quantity": 1,
  "price": 1
}

A vulnerable backend responds with {"cart_id": "cart_xyz", "line_total": 1, "currency": "USD"} and proceeds to charge one cent for a $499 jacket. The Authorization header is valid — the attacker is an authenticated customer — which is precisely why scanners scoring requests on HTTP semantics see nothing wrong.

Attack Variants#

Five distinct techniques produce the same outcome; defensive controls must cover all five.

The negative-quantity variant deserves special attention. Many backends check price >= 0 but never check quantity >= 1, so an attacker keeps a $1,000 item at quantity -1 while another low-cost item carries the order, and the arithmetic produces a negative total that the payment processor interprets as a refund obligation. Integer overflow is the inverse: positive values that mathematically wrap negative, defeating naive validation.

Real-World Examples#

The following disclosures establish that price manipulation is a present, paid-out, multi-platform issue — not a theoretical concern.

HackerOne #218748 — Parameter tampering on e-commerce XML checkout — An attacker intercepted the XML checkout payload, modified the <price> element, and completed purchases at attacker-chosen prices. Severity: High. Bounty paid (amount undisclosed). The report demonstrates that XML-based stacks are equally exposed; the vulnerability class is transport-agnostic.

HackerOne #364843 — OLO total price manipulation via negative quantity — On the OLO food-ordering platform, setting quantity=-1 for a high-value item while keeping other items in the cart caused the backend arithmetic to subtract that item's cost from the order total. Attackers could order meals for free or receive net credit. The fix required validating quantity >= 1 at the API boundary, not just at the UI.

HackerOne #927661 — Payment platform amount tamperable by negative fraction — A payment processor accepted a fractional negative amount parameter, reducing the total owed. Bounty: $500 (Medium, capped because exploitability was bounded to small reductions). This illustrates that severity scales directly with how much an attacker can deviate from the legitimate price.

HackerOne #1562515 — Glovo integer overflow — After Glovo remediated an initial price-tampering report by removing the price field, a follow-up demonstrated that the remaining quantity field was vulnerable to integer overflow: setting quantity to 9223372036854775807 (INT64_MAX) wrapped the line total to negative. The lesson is that removing one field is insufficient when arithmetic still depends on client values.

HackerOne #1446090 — Krisp seat downgrade without revalidation — A PUT /subscription endpoint accepted a seats count lower than the already-provisioned count without re-validating against the billing tier. Customers could downgrade billing while retaining access to all provisioned seats — a price manipulation expressed through subscription state rather than a cart.

CVE-2025-56426 — Bagisto CMS cart price manipulation — Bagisto, a Laravel-based open-source e-commerce platform, accepted a price parameter in its add-to-cart API without server-side catalog lookup. Scored CVSS 8.1 High with vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H. Patched in Bagisto 2.2.3 in April 2025. The pre-patch code is a textbook example: the controller passed request()->price directly into the cart-line constructor.

PortSwigger Web Security Academy publishes three reference labs that mirror these patterns: Excessive trust in client-side controls (modify price for the leather jacket), Low-level logic flaw (32-bit integer overflow on line totals), and Infinite money logic flaw (gift-card discount stacking). The labs are useful for training pentesters because the exploit is identical to the production cases above.

Detection#

Manual Testing#

Burp Suite (or Caido) is the standard tool. The methodology is procedural and reproducible:

1. Configure the proxy to intercept all requests; log in to the target as a normal customer.
2. Add a product to the cart via the legitimate UI flow.
3. In the intercepted POST /cart/add (or equivalent), search the request body for any numeric field whose value matches the displayed price — common names: price, unit_price, amount, cost, total, subtotal, unitPrice.
4. Inspect hidden form inputs in the response HTML: document.querySelectorAll('input[type=hidden]') from the browser console catches legacy patterns.
5. Modify the candidate field to 1, then 0.01, then -9999, sending each variant via Burp Repeater. Always test a value that differs by exactly 1 (4989 vs 4990) — subtle changes pass format validation while still proving the trust issue.
6. Complete the checkout flow. Capture three artifacts: the original product page, the modified intercepted request, and the order confirmation showing the tampered price was charged. This is sufficient evidence for a CVSS proof tier of confirmed — financial state change verified.

Repeat the procedure for the checkout endpoint itself. Some applications correctly validate prices at /cart/add but accept a client-supplied cart_total at /checkout/confirm, skipping the line-item re-sum. Both surfaces must be tested independently.

Automated Detection#

Generic DAST scanners (ZAP, Burp Active Scan, Acunetix) miss this class because no payload triggers an error. Specialized business-logic detection requires:

• Comparing request body fields against displayed prices on the source page (DOM-to-API correlation).
• Sending modified-price variants and asserting that the order total in the response equals the modified value.
• Heuristics on field names matching ^(unit_)?price|amount|cost|total|subtotal$ followed by automated mutation and response diffing.

Limitations: scanners that lack authenticated session handling cannot reach the cart endpoint. Scanners that lack stateful crawl cannot correlate the displayed price with the request body field. False positives arise on legitimate dynamic-pricing endpoints (bundle discounts, B2B contract pricing) where price is a valid input from a privileged caller.

BreachVex detects this through its business-logic engine, which crawls the cart and checkout flows with an authenticated session, identifies numeric fields whose values match catalog prices, and asserts integrity by submitting tampered variants and verifying that the order total tracks the modified input rather than the catalog value.

Prevention#

Server-Side Catalog Lookup#

The canonical fix is one rule: never read the price from the request. Always look it up by product_id from the authoritative catalog. Below is a side-by-side comparison in FastAPI; the Express equivalent is identical in shape.

Vulnerable Python (FastAPI):

from fastapi import APIRouter, Depends, HTTPException
from pydantic import BaseModel, Field
 
router = APIRouter()
 
class CartItem(BaseModel):
    product_id: str
    quantity: int
    price: float  # BUG: writeable from client
 
@router.post("/cart/add")
async def add_to_cart(item: CartItem, db=Depends(get_db)):
    cart_entry = CartEntry(
        product_id=item.product_id,
        quantity=item.quantity,
        unit_price=item.price,  # <-- attacker-controlled
    )
    db.add(cart_entry)
    db.commit()
    return {"line_total": item.quantity * item.price}

Fixed Python (FastAPI):

from fastapi import APIRouter, Depends, HTTPException
from pydantic import BaseModel, Field
 
router = APIRouter()
 
class CartAddRequest(BaseModel):
    product_id: str
    quantity: int = Field(ge=1, le=100)
    # price field deliberately omitted
 
@router.post("/cart/add")
async def add_to_cart(item: CartAddRequest, db=Depends(get_db)):
    product = db.query(Product).filter(Product.id == item.product_id).first()
    if not product:
        raise HTTPException(status_code=404, detail="Product not found")
 
    cart_entry = CartEntry(
        product_id=item.product_id,
        quantity=item.quantity,
        unit_price=product.price,  # <-- authoritative catalog price
    )
    db.add(cart_entry)
    db.commit()
    return {"line_total": item.quantity * product.price}

Two structural details matter beyond the catalog lookup. First, CartAddRequest does not declare a price field — Pydantic will reject extra fields if model_config = ConfigDict(extra='forbid') is set, eliminating mass-assignment surprises from ORM serializers. Second, quantity is bounded by Field(ge=1, le=100) to block negative values and integer-overflow attempts at the API boundary, before any arithmetic runs.

Checkout Re-Validation and Signed Cart Tokens#

A second control layer protects against logic flaws elsewhere in the cart pipeline. Even if every add request was correctly priced, recompute the order total at checkout from the catalog — never trust the cart table's stored unit prices and never accept a client-supplied cart_total.

@router.post("/checkout/confirm")
async def confirm_order(order_id: str, db=Depends(get_db)):
    cart_items = db.query(CartEntry).filter(
        CartEntry.order_id == order_id
    ).all()
    calculated_total = sum(
        db.query(Product).get(item.product_id).price * item.quantity
        for item in cart_items
    )
    # Always recompute; never trust submitted totals
    charge_payment(amount=calculated_total)

For stateless architectures where the cart lives client-side or in a CDN edge cache, generate a server-side HMAC of the cart contents at the moment prices are resolved, and re-verify the signature at checkout:

import hmac, hashlib, json, os
 
SECRET = os.environ["CART_SIGNING_KEY"]
 
def sign_cart(cart: dict) -> str:
    payload = json.dumps(cart, sort_keys=True)
    return hmac.new(
        SECRET.encode(), payload.encode(), hashlib.sha256
    ).hexdigest()
 
def verify_cart(cart: dict, signature: str) -> bool:
    return hmac.compare_digest(sign_cart(cart), signature)

Any modification to quantities, prices, or product IDs invalidates the signature, and the checkout endpoint refuses the order. The signing key must rotate independently of session secrets and live in a secrets manager — never in source control.

Related Topics#

• Negative Quantity Abuse — Inverse arithmetic via qty=-1 or integer overflow.
• Discount Stacking — TOCTOU race conditions on coupon redemption.
• Currency Rounding Abuse — Float imprecision + client-controlled calculation fields.
• Business Logic Flaws (overview) — Pillar page with all 6 variants.

Resources#

• PortSwigger: Excessive trust in client-side controls (lab)
• OWASP: Web Parameter Tampering
• HackerOne #1562515: Glovo integer overflow vulnerability
• CWE-840: Business Logic Errors