You find vulnerabilities, report them, help secure companies, and sometimes get rewarded for it. But one thing people rarely talk about is this:

Sometimes bug bounty hunting goes wrong against the hacker too.

This story is about how losing almost $500 from my bank account pushed me back into hunting… and eventually led me to discovering a real Web Cache Poisoning vulnerability.

Unfortunately, I reported it too late.

Another hacker got there first.

But the journey itself taught me something important:

As long as software exists, there will always be bugs.

What Web Cache Poisoning Is. Web Cache Poisoning is a vulnerability where an attacker tricks a caching system (such as a CDN, reverse proxy, or browser cache) into storing and serving malicious or manipulated content to other users.

This usually happens when a web application uses user-controlled input — such as headers, parameters, or cookies — to generate a response, but the caching layer does not include that input in the cache key.

As a result:

• the attacker sends a specially crafted request,
• the malicious response gets cached,
• and normal users later receive the poisoned content from the cache.

Web cache poisoning can lead to:

• content manipulation,
• phishing attacks,
• SEO poisoning,
• malicious redirects,
• or even stored XSS in severe cases.

In simple terms:

The attacker poisons the cache once, and the cache serves the malicious response to everyone else.

It Started With a Different Cache Poisoning Bug.

I was hunting on a particular target when I stumbled across what looked like a Web Cache Poisoning vulnerability.

At first glance, the issue looked promising, but exploitation felt difficult. I couldn't immediately prove impact, so instead of wasting too much time on it, I documented everything carefully in my notes and moved on to test other subdomains.

That decision would later come back in an unexpected way.

The SaaS Platform.

One of the subdomains worked like a SaaS platform for businesses.

It allowed work owners and managers to:

• manage accounts.
• handle invoices.
• manage payments.
• access premium business features.

But most advanced functionalities required a paid subscription.

So I decided to test the payment workflow.

I requested a subscription and some weeks later an invoice was generated.

The invoice amount?

Equivalent to $500

To proceed, users could:

• enter a debit/credit card.
• provide the CSC/CVV.
• or pay directly through an IBAN bank transfer.

Since I was only testing functionality, I entered my card number but intentionally used an incorrect CSC code.

The payment failed as expected.

At that point, I tested the remaining functionality, found nothing interesting, and eventually deleted the account entirely.

Or at least…

I thought I did.

Four Days Later…

Four days later, I received a debit alert from my bank. At first, I assumed it was a mistake, but when I opened the message, my heart dropped. The charge was coming from the exact card I used on the SaaS platform.

They had successfully debited the full $500 equivalent from my account. In my local currency, that amount was nearly 6K.

And the craziest part?

I had entered the wrong CSC code during testing.

Immediately, I called my bank and cancelled the card to prevent any additional charges.

Trying to Contact the Company.

I contacted the company's sales manager on WhatsApp. The first message was read. After that?

Silence… No replies…

I also emailed the company directly, explaining the situation in detail. They eventually responded the next day and told me:

There would be no refund.

Not only that…

They somehow reactivated the account I had already deleted and informed me that the subscription had been activated successfully.

They also assured me they "would not charge me next year," since the subscription renews annually.

At that point, I was frustrated, confused, and honestly angry.

I still had no idea how they managed to process the payment successfully despite the incorrect CSC.

But once a hacker, always a hacker… we do understand. 🗿

Returning to Hunt Again.

After losing the money, I went back to the main target to continue hunting.

Not out of revenge.

But because I wanted to recover the loss through a legitimate bounty.

That's when I remembered the cache poisoning issue I had documented earlier.

I reopened my notes and started digging deeper.

Discovering the Real Vulnerability.

I intercepted the homepage request in Burp Suite and immediately noticed something interesting:

Cache-Control: public, max-age=604800
Pragma: public
Cf-Cache-Status: HIT

That's always a signal worth investigating.

So I sent the request to:

Param Miner → Guess Headers.

A few moments later, Param Miner flagged:

X-Original-Host

as an unkeyed header.

That was the breakthrough.

Exploiting the Cache Poisoning.

To safely test the issue without affecting normal users, I used a cache-busting parameter:

?cb=test123

⚠️ Important Note About ?cb=test123

The cache-busting parameter was only used for safe testing.

It does not limit the vulnerability.

The real issue is:

The header is unkeyed, meaning poisoned responses can be cached and reused for the same resource.

Then I sent:

X-Original-Host: attacker.com

The response reflected my malicious host value into the HTML.

Even more interesting?

The response was cached.

After removing the malicious header and revisiting the same URL, the poisoned response was still being served from cache.

That confirmed it:

✔️ Stored Web Cache Poisoning.

The application trusted user-controlled headers, but the cache layer ignored them.

Classic cache poisoning.

The Impact.

What made this vulnerability dangerous was not just the header injection itself.

It was the fact that the poisoned response was being cached and served to other users.

That means an attacker could potentially:

• Poison cached pages seen by multiple visitors.
• Manipulate canonical URLs used by search engines.
• Inject attacker-controlled URLs into application responses.
• Abuse trust in the legitimate domain.
• Use poisoned content as part of phishing or social engineering campaigns.

And because the response was publicly cacheable for hours, the malicious content could persist long after the attacker's original request.

The dangerous part about cache poisoning is that victims do not need to do anything special.

They simply visit the normal website and receive attacker-influenced content directly from a trusted domain.

The Ending 😅

After documenting everything carefully, I submitted the report.

And then came the response every hunter hates seeing:

"Marked as duplicate."

Another hacker had already reported the same root issue before me.

Honestly?

That hurt. Especially after everything that happened earlier.

But that's part of bug bounty hunting. Sometimes:

• you find the bug late.
• someone else reports it first.
• or life simply gets in the way…

What I Learned. 🧠

This experience taught me several things.

1. Document Everything.

That original note I wrote down became important later. Never ignore weird behavior.

2. Small Clues Matter.

A simple caching header eventually led to a real vulnerability.

3. Bug Hunting Isn't Always Glamorous.

Sometimes you lose:

• time
• sleep
• money

And sometimes even your own card gets charged. 😅

4. There Will Always Be Bugs.

Software changes constantly:

• new features.
• new integrations.
• outdated dependencies.
• rushed deployments.

And because of that:

As long as software exists, vulnerabilities will continue to exist too.

That's why researchers keep hunting.

Final Thoughts.

Even though this report became a duplicate, I still consider it a win. Not because of money.

But because every real vulnerability found sharpens your skills for the next one.

And the next one might not be a duplicate. 🌾🍀

👏 If you enjoyed this story.

• Leave some claps.
• Follow me for more security stories.
• Keep hacking and keep learning…

Because every bug hunter has a story behind the screenshots. See you in the next story, bye…