Hello Hackers — hope you’re well.
Today I’m sharing a short write‑up about a recent finding on a private program — I’ll call the site EXAMPLE.COM.

While scrolling a popular car‑parts marketplace with a friend I joked, “I could change every product price on this site.” He laughed. That challenge stuck with me — three days later I found a tiny URL parameter that made a paid product free. Let’s dive in.

I wasn’t hunting general bugs — I only wanted to change product prices.

When I clicked the price on a product page it returned an ID and the price. My first thought was the usual: tweak that parameter and the price will change(699 EUR→0) — classic parameter tampering. I tried it — nothing happened.

Somehow, I started thinking about following the payment steps. I tried to change the price just before the request went to the Visa payment, attempting to tweak it right before the final call to the payment API. That’s when I noticed another request — it was fetching the product ID again.

And here’s where I found something spicy! Can you see it?

The spicy parameter: id_product_feature_set

While digging, I noticed this parameter in the request:

id_product_feature_set

I wondered what would happen if I tried -1. Turns out, a few things can go wrong:

1. Broken database lookup
The server likely runs something like:

SELECT price_modifier FROM product_feature_set WHERE id = -1;

→ No result → fallback = 0 → price = base_price + 0 = 0.

2. Error in price calculation
If the backend just adds the feature price from an array:

$total_price = base_price + feature_set_price[$id_product_feature_set];

and $feature_set_price[-1] doesn’t exist, the total becomes 0.

3. Application logic flaw
Some systems treat missing or invalid features as “no price,” defaulting the total to 0 so checkout isn’t blocked.

and here i make the product price to 0 EUR

In the end, the company recognized it as a critical vulnerability, and I received the bounty reward.

Thanks for following along!

Contact :

helmi riahi | LinkedIn