Hey there!

You ever fix a leak in your house… but the wall still smells damp? 🧱💧 Or delete a toxic contact… but keep checking their status anyway? 📱😶 Or promise yourself "this time I'll sleep early"… and then open one more tab? 🌙💻 Yeah… this hunt felt exactly like that.

🧠 It Started Quiet… Too Quiet

This was a private program. One of those "we take security seriously" kind of targets.

No noise. No chaos. No obvious bugs. Everything looked… polished.

Almost like someone had already been here before me 👣

And that's what made me stay.

🔍 Digging Where Others Already Dug

I wasn't hunting for new bugs. I was hunting for forgotten mistakes.

Started with the usual recon:

subfinder -d target.com -all -recursive > subs.txt
httpx -l subs.txt -silent -threads 200 > alive.txt
katana -list alive.txt -depth 5 -jc > endpoints.txt

Filtered the noise:

grep -E "\.(json|js|map|log)" endpoints.txt > sensitive.txt

And then… something felt off.

An endpoint that looked… too structured to be random:

https://cdn.target.com/assets/v3/profile/edge-cache?region=ap-south-1&build=prod-2024

Not flashy. Not obvious. But it had that "I shouldn't trust this" energy.

🌐 The Cache That Remembered Too Much

Quick header check:

Cache-Control: public, max-age=600
X-Cache: HIT
Via: varnish

So yeah — CDN caching layer involved.

But the response?

It wasn't static.

It contained:

• regional routing logic
• backend API references
• dynamic values

That's when the thought hit me:

"Why is dynamic data being cached like this…?"

🧪 Understanding Before Breaking

I didn't rush. Just watched how the system behaved.

ffuf -u "https://cdn.target.com/assets/v3/profile/edge-cache?region=FUZZ&build=prod-2024" -w regions.txt -mc all

Patterns emerged:

• region affected the response
• cache persisted responses aggressively
• headers didn't seem to affect cache keys

That last one… stayed in my head.

🧬 The Moment It Started Slipping

I tried something small.

Nothing aggressive.

GET /assets/v3/profile/edge-cache?region=ap-south-1 HTTP/1.1
Host: cdn.target.com
X-Forwarded-Host: test.local

Response changed.

Not broken. Not crashing.

Just… different.

"api_base": "https://test.local/internal/api"

I paused.

Read it again.

That wasn't supposed to happen.

When Small Things Become Big

The frontend trusted that value:

fetch(`${api_base}/user/details`)

So I wondered…

"What if this response gets cached?"

🧪 Testing the Theory

Sent a crafted request:

curl -H "X-Forwarded-Host: attacker.local" \
"https://cdn.target.com/assets/v3/profile/edge-cache?region=ap-south-1"

Then accessed it normally:

curl "https://cdn.target.com/assets/v3/profile/edge-cache?region=ap-south-1"

And there it was.

The response stayed poisoned.

Not just for me… For anyone hitting that endpoint.

🧠 That Weird Silence After Discovery

No excitement. No adrenaline.

Just silence.

Because this wasn't just a bug anymore.

It was:

• trust broken between layers
• cache storing manipulated responses
• backend believing things it shouldn't

And the worst part?

It felt… familiar.

🕳️ A Strange Sense of Déjà Vu

While writing the report, I remembered something.

A discussion thread. Somewhere deep on the internet.

People talking about leaked API responses. From a system that sounded… similar.

At that moment, everything connected.

Not fully. Not provably.

But enough to feel uneasy.

📩 The Report

I documented everything carefully:

• cache behavior
• header influence
• response manipulation
• persistence via CDN

Added PoC:

X-Forwarded-Host: attacker.local

Also tested variations:

X-Host: attacker.local
Forwarded: host=attacker.local
X-Original-Host: attacker.local

Because fixes usually focus on one header… and forget the rest.

🤡 The Response

After some time…

They replied.

"This was already fixed in a previous report."

That sentence hit harder than expected.

Because I knew what I was seeing.

So I went back.

Tested again.

🔁 And There It Was… Still Alive

They had patched the obvious:

• validated X-Forwarded-Host

But the system still trusted:

X-Host
Forwarded

And the cache?

Still ignored everything.

Still storing poisoned responses.

Still repeating the same mistake… just wearing a different mask.

📭 And Then… Nothing

I followed up.

Shared updated proof.

Explained the root cause clearly.

No response.

No fix.

No acknowledgment.

Just silence.

🧠 What This Hunt Taught Me

Not every story ends with closure.

Some bugs don't get fixed. Some reports don't get accepted. Some truths just sit… unnoticed.

But this one stayed with me.

Because it wasn't about a single flaw.

It was about a pattern:

Fix the symptom. Ignore the cause. Repeat.

🛠️ Techniques That Helped Me See It

🔹 Cache Key Awareness

Always ask:

• What defines the cache key?
• What gets ignored?

🔹 Header Mutation Testing

Never trust one header test.

Try variations:

X-Forwarded-Host
X-Host
Forwarded
X-Original-Host

🔹 Observe Before Exploiting

Sometimes the biggest bugs don't break things.

They quietly change behavior.

🎯 Ending… Without an Ending

This wasn't my cleanest find. Not my loudest one either.

But it was the one that reminded me:

Just because something was "fixed"… doesn't mean it's gone.

Sometimes…

It's just waiting to be noticed again 👣

Still thinking about that endpoint…

Connect with Me!

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

#EnnamPolVazhlkai😇

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