Title: The $0.00

The $0.00 Subscription: Finding a Business Logic Flaw in Semrush (and the Reality of Duplicates)

Subtitle: How I discovered a Price Manipulation vulnerability in a major SaaS platform, validated it, and learned a valuable lesson about the bug bounty race.

Hello everyone! Today I want to share a recent finding I had on Semrush. Although it was closed as a "Duplicate," it was a great learning experience and a strong validation of my methodology. It highlights the importance of testing payment flows and understanding business logic.

The Recon: Following the Money

I was testing the Semrush application as a regular free user, focusing on the checkout and subscription flows. I set up Burp Suite to intercept the traffic and initiated a trial for the "SEO PRO" plan.

During the billing process, I intercepted a POST request to the following endpoint: POST /v2/payment/billing-info/update

The Flaw: Trusting the Client

While analyzing the request body, a specific parameter caught my eye: "amount":["0.00","139.95"]

This array represented the charge for today ($0.00 trial) and the future recurring charge ($139.95). The server was relying on the client to tell it how much the subscription costs!

I sent the request to Burp Repeater and modified the second value to 0.00, so the array became: "amount":["0.00","0.00"]

I forwarded the request and observed the response: HTTP/2 200 OK {"total_amount": "0.00", "base_amount": "0.00", "tax_amount": "0.00"}

The server accepted the manipulated price. Furthermore, the frontend UI instantly reflected this change, showing Next charge: £0.00 and Today's charge: £0.00.

The Impact

This was a classic Price Manipulation / Business Logic Flaw. An attacker could potentially downgrade the cost of any premium plan to $0.00, resulting in direct financial loss for the company.

(Note: While I couldn't complete the final transaction using a test credit card since Stripe rejected it for being fake, the backend logic fully accepted the manipulated amount).

The Outcome: The Bug Bounty Race

I wrote a detailed report on HackerOne with clear steps to reproduce and screenshots. The Semrush security team responded quickly:

"We reproduced the behavior you described: editing the amount value in the billing-info/update request does make the response and the checkout UI show 0.00."

However, the report was closed as a Duplicate. Another researcher had found and reported the exact same flaw before me.

Key Takeaways

1. Payment flows are a goldmine: Always intercept and modify parameters like amount, price, currency, and discount during checkout.
2. Business Logic matters: The server should never trust the client for calculating prices. It should always verify the price on the backend based on the offer_hash or product ID.
3. Duplicates are part of the game: Getting a duplicate on a high-impact bug means your methodology is correct. It's a race, and sometimes you win, sometimes you learn. The validation from the security team is a win in itself!

Keep hunting, and never stop intercepting! — red_eye_1_1

---