How I Snagged a $$$ P1: PayU Key + Salt + Hash Revealed in a Hospital’s Payment Response

🔍 What Happened?

While testing a hospital’s online payment system as part of a private bug bounty program, I found something very serious.

Photo by HackerNoon on Unsplash

The website was exposing PayU secrets — the key, salt, and even the hash used to secure the payment request—in the response of a POST request. This kind of leak can allow attackers to manipulate payments or forge their own.

This is a P1 (critical) level bug because it directly affects how money is processed and can be misused to bypass the real payment system.

🧪 How I Found It (Step-by-Step)

I followed a simple test flow to check how payments work:

1. Go to the payment page:
   https://example.com/payment
   (This is a placeholder URL to keep the real one private)
2. Fill out the form with random but valid data — like name, amount, and email.
3. Click “Pay” while intercepting the request using Burp Suite (a proxy tool).
4. The request sent was:

POST /payment/deposit

HTTP/2 Host: example.com

5. In the response, I saw this:

{

"key": "W8xxxx",

"salt": "kYeZ2Z6VFTLxxxxx",

"hash": "keopdfc8453555f0fac5acxxxx"

}

🔐 Why This Is Dangerous

Let’s quickly explain what these values do:

• key: Identifies the PayU merchant account (in this case, the hospital).
• salt: A secret value used with the key to create a secure hash.
• hash: The final security signature created using key + salt + payment info.

Normally, this hash is created on the server, then sent to PayU only. But in this case, all of it was sent to the browser. That’s like giving out both the lock and the key to anyone who asks.

With these values, a hacker could:

• Create fake payment requests
• Change the payment amount
• Reuse the hash for other transactions

💥 Real-World Impact

If someone had found this before me, they could:

• Pay ₹1 instead of ₹10,000
• Mark payments as completed without paying
• Trick the hospital into thinking a payment was made

This kind of issue is serious and could lead to big financial losses if abused.

🛡️ Fixing the Issue

The fix was pretty straightforward:

1. The server should never send key, salt, or hash to the frontend.
2. The hash should only be generated server-side, just before sending the user to PayU.
3. After fixing, the team rotated the key and salt, so the leaked ones could not be reused.

🧠 Lessons Learned

• Never trust the frontend with secrets.
• Always generate hashes securely on the server.
• Leaking a key + salt is like giving someone access to your bank account.

📖 Reference

For those curious about how PayU works behind the scenes, check this out:
👉 https://docs.payu.in/docs/handling-the-redirect-urls#implementation-notes-1

🙌 Thanks for reading!

This was one of my favorite bugs because it shows how a small mistake (showing sensitive data in a response) can lead to a major security problem.