😓 The Long Road Before the Win

My journey lasted a year and a half. For eighteen months, I spent my evenings and weekends digging through code, analyzing requests, hunting for vulnerabilities. My wallet remained empty. At some point, your hands start to drop. You begin to think: "Maybe this just isn't for me? Maybe all the bugs have already been found by automation?"

That evening, I was doing yet another investigation of a major educational platform (let's call it EdTech Corp). I stumbled upon an interesting endpoint that accepted a URL parameter. Out of habit, I entered the address of my server — and got a response. I tried accessing an internal resource — and suddenly saw in the response a page title that shouldn't be accessible from the internet.

A couple of weeks later, when the payment notification hit my email, I didn't just smile. I screamed "THE MONEY CAME!" 🎉 across the entire room. The emotions overwhelmed me so much that I literally cried on my friend's shoulder. This wasn't just €250. This was a year and a half of suffering, sleepless nights, and doubts that had finally paid off.

💰 The Moment That Changed Everything

It was February 10th, 2026, when my phone buzzed with a notification I'd been chasing for 18 months:

Security Team rewarded a bounty of €250 to savi0r

But this story isn't just about finding a bug. It's about something far more valuable: learning how to fight for your findings when they're being underestimated.

🔍 The Hunt: Finding a Partial SSRF

I was testing EdTech Corp's bug bounty program, specifically focusing on their API subdomains. While fuzzing API endpoints, I stumbled upon something interesting:

https://example-api.edtechcorp.example/user/work/external?url=<PAYLOAD>

The parameter name url immediately caught my attention. Classic SSRF (Server-Side Request Forgery) territory. I started testing:

Test 1: External collaborator (Beeceptor)

?url=https://my-collaborator.free.beeceptor.com

✅ Result: Hit received! The server was making outbound requests.

But here's where it got weird. The response only returned:

{"title": "My Page Title"}

Just the <title> tag. Not the full HTML. Not the response body. Just... the title.

Most researchers would stop here. They'd think: "Partial SSRF with limited output? That's Low severity at best. Maybe even Informative." I almost did too.

💡 The Breakthrough: Internal Network Access

But then I remembered something crucial: Impact isn't about what you CAN extract. It's about what you CAN REACH.

I started thinking about EdTech Corp's internal infrastructure. They're a tech education company with sophisticated backend systems. There had to be internal services.

I tried a common naming pattern:

?url=http://netbox.ops.internal

NetBox is a popular infrastructure documentation tool that companies use internally to map their network topology, IP addresses, devices, etc. It's NEVER supposed to be public.

Response:

{"title": "Home - NetBox"}

🎯 Jackpot.

Let me explain why this is massive:

1. I tried accessing netbox.ops.internal directly from my browser
2. Result: Connection Timeout (ERR_TIMED_OUT)
3. It's behind a firewall, only accessible from their internal network

But through the SSRF vulnerability, I could reach it.

This wasn't just "reading a title tag." This was bypassing network segmentation and accessing Tier-0 internal infrastructure from the public internet.

🕵️ The Investigation: Metadata Leakage

I dug deeper. Using my Beeceptor collaborator URL, I analyzed the headers being sent by EdTech Corp's backend server:

User-Agent: axios/0.26.1
x-datadog-trace-id: 78XXXXXXXXXXXXXX
x-b3-traceid: aXXXXXXXXXXXXXXXX
x-forwarded-host: my-collaborator.free.beeceptor.com

This revealed three critical pieces of information:

1. axios/0.26.1: The backend was using Axios to make requests
2. x-datadog-trace-id: Internal Datadog tracing headers were being forwarded
3. x-b3-traceid: B3 propagation headers (service mesh indicators)

The presence of these internal tracing headers proved that:

• The request was routing through their internal Service Mesh
• I could correlate external requests with internal traces
• An attacker could map their internal request flow and architecture

⚔️ The Battle: Fighting for Impact

I submitted my report on January 25th, 2026. Initial severity: Low.

Five days later, I received this message from the triage team:

"Can you provide additional impact, disclosure of a host title does not pose a significant security risk"

This is where most new bug hunters give up.

They accept the Low rating. They move on. They think "Well, the triager must know better than me."

I didn't.

Here's the response I sent that changed everything:

My Response to Triage (January 30th, 2026)

Hi @triager,

Thank you for the update. I understand that a <title> tag by itself may seem low-risk, but I would like to clarify why this SSRF represents a significant security breach in this specific context:

1. Bypass of Network Segmentation: The core issue isn't the disclosure of the title, but the reachability. The fact that I can successfully establish a connection and receive a response from netbox.ops.internal proves that the example-api has unauthorized access to your internal management network (Tier-0/Tier-1 assets).

2. Internal Reconnaissance & Attack Surface: NetBox is a source of truth for network infrastructure. Reaching it via SSRF confirms that an attacker can map your internal topology and target internal services that are often unauthenticated because they rely on 'network trust' (RFC1918).

3. Infrastructure Metadata Leakage: As shown in my report, the request leaks internal tracing headers (x-datadog-trace-id). This confirms the request is routed through your internal Service Mesh. This leakage allows an attacker to correlate external requests with internal traces, revealing the logic of your backend interactions.

4. Impact vs. Exploitation: As an ethical researcher, I demonstrated the capability to interact with internal hosts. Proving 'more impact' by attempting to exploit unauthenticated internal APIs or brute-force management tools would exceed the scope of responsible disclosure and risk disrupting your internal services.

This is a confirmed bypass of your network isolation policy. Does the organization consider public access to internal ops infrastructure to be within their risk appetite?

kind regards, savi0r

🏆 The Result

30 minutes later:

• ✅ Severity changed from Low → Medium (5.3 CVSS)
• ✅ Bounty increased to €250
• ✅ Status changed to Triage → Pending → Accepted

The triager's response:

"Considering the impact, we will pass your findings along to the company for further review."

Ten days later, EdTech Corp's security team accepted the report and paid the bounty.

📚 Lessons for Bug Bounty Hunters

1. 🎯 Impact ≠ Data Extraction

The biggest mistake new researchers make is thinking: "If I can't dump a database or steal credentials, it's not severe."

Wrong.

Impact can be:

• 🚪 Bypassing network segmentation (what I did)
• 🔓 Accessing internal services
• 📊 Metadata leakage that aids further attacks
• 🛡️ Breaking security boundaries

2. 💬 Learn to Articulate Risk

Notice my response structure:

1. Acknowledge their concern ("I understand that a <title> tag may seem low-risk...")
2. Reframe the vulnerability ("The core issue isn't disclosure, it's reachability…")
3. Provide business context ("NetBox is a source of truth…")
4. Explain ethical boundaries ("I won't exploit further because…")
5. Ask a pointed question ("Does COMPANY consider this within their risk appetite?")

This isn't arguing. It's educating the triager about the business risk.

3. Use Evidence, Not Emotion

I didn't say "This is obviously critical, you're wrong!"

I said:

• ✅ "Here's proof it's behind a firewall" (screenshot of timeout)
• ✅ "Here's proof of internal routing" (tracing headers)
• ✅ "Here's what this service does" (NetBox explanation)

Evidence > Emotion

4. 🛑 Know When to Stop

I explicitly stated I wouldn't try to:

• ❌ Enumerate internal APIs
• ❌ Brute-force admin panels
• ❌ Attempt authentication bypass

Why? Because:

1. It's unethical and against responsible disclosure
2. It could harm the company's infrastructure
3. It weakens your credibility if something breaks

Instead, I proved capability, not exploitation.

5. ⏰ Patience Pays Off

• January 25: Submitted
• January 30: Asked for more impact
• January 30 (same day): I responded
• February 10: Accepted and paid

16 days from submission to payout.

During those 16 days, I was checking the platform every hour. I was anxious. I was doubting myself.

But I trusted my research and held my ground.

🔧 Technical Deep Dive: Why This SSRF Mattered

For those who want to understand the technical severity:

Attack Chain

1. Public Entry Point: example-api.edtechcorp.example (Cloudflare protected)
2. Vulnerable Parameter: /user/work/external?url=
3. Backend Behavior: Server makes HTTP request using axios/0.26.1
4. Network Routing: Request goes through internal Service Mesh
5. Accessible Targets: Internal services on .ops.internal domain

Why Network Segmentation Bypass is Critical

Most companies follow this security model:

┌─────────────────────────┐
│   Public Internet       │
│   (Cloudflare/WAF)      │
└──────────┬──────────────┘
           │
           ▼
┌─────────────────────────┐
│   DMZ / Edge Services   │ ← example-api.edtechcorp.example
│   (Can access internet) │
└──────────┬──────────────┘
           │
           ▼
┌─────────────────────────┐
│   Internal Network      │ ← netbox.ops.internal
│   (Should be isolated)  │    (NOT supposed to be reachable)
└─────────────────────────┘

The vulnerability broke this model.

An attacker could:

• Map internal infrastructure (NetBox)
• Discover internal services (Keycloak for IAM)
• Fingerprint internal tech stack
• Correlate external activity with internal traces

What Could Have Been Exploited (Hypothetically)

If I were malicious (I'm not), the next steps would be:

1. Enumerate internal services using common names:

• jenkins.ops.internal
• grafana.ops.internal
• vault.ops.internal

2. Test for unauthenticated endpoints:

• Many internal services don't require auth because "it's internal"
• SSRF bypasses this assumption

3. Chain with other vulnerabilities:

• Find API keys in environment endpoints
• Access internal documentation
• Reach cloud metadata services

But I didn't do any of this. I stopped at proving reachability.

🎢 The Emotional Rollercoaster

Let me be real with you for a moment.

1.5 years is a long time to grind with zero results.

I questioned everything:

• 🤔 Am I wasting my time?
• 😔 Am I just not smart enough?
• 😞 Should I give up?

Every "Informative" or "Duplicate" or "N/A" felt like a punch to the gut.

But when that €250 bounty notification came through, it wasn't just about the money.

It was validation. ✨

It proved that:

• ✅ My methodology was sound
• ✅ My persistence mattered
• ✅ I could compete in this space

To anyone reading this who's in their own "1.5 year drought":

💪 Keep going.

Your breakthrough is one report away. One endpoint away. One argument away.

🎯 Key Takeaways

For Beginners 🌱:

1. Partial SSRF isn't useless — focus on what you can REACH, not just what you can READ
2. Internal network access is high impact — even if you can't extract data
3. Learn to write persuasive reports — technical skills get you 50%, communication gets you the other 50%

For Intermediate Hunters 🚀:

1. Understand business context — NetBox isn't just "an internal tool," it's infrastructure documentation
2. Metadata leakage matters — tracing headers, internal user agents, etc. all add to impact
3. Don't be afraid to push back on triage — but do it professionally with evidence

For Programs 🏢:

1. Listen to researchers who demonstrate thorough understanding — my response showed I understood their architecture
2. Network boundary violations are serious — even without full data exfiltration
3. Researchers who self-limit exploitation deserve credit — ethical behavior should be rewarded

💭 Final Thoughts

This bug taught me more than any tutorial or course ever could:

✅ Technical Skill: How to identify and exploit SSRF ✅ Risk Assessment: How to evaluate true business impact ✅ Communication: How to defend your findings professionally ✅ Ethics: How to demonstrate risk without causing harm ✅ Persistence: How to keep fighting for 1.5 years without giving up

The €250 is nice. But the real reward was proving to myself that I belong in this field. 🏆

📚 Resources

Want to learn more about SSRF?

• PortSwigger Web Security Academy — SSRF
• OWASP SSRF Guide
• HackerOne SSRF Reports

About the Author 👨‍💻

I'm savi0r, a bug bounty hunter who spent 1.5 years learning the hard way. This was my first accepted medium-severity finding and my first real payout.

If this story resonated with you, connect with me on:

• Twitter/X: https://x.com/btwsavi0r
• GitHub: https://github.com/iamsavi0r

And remember: Your first bounty is just one argument away. Keep hunting. Keep learning. Keep fighting for your findings. 🔥

Vulnerability Timeline:

• January 25, 2026: Report submitted
• January 30, 2026: Triage questioned impact
• January 30, 2026: I provided detailed justification
• January 30, 2026: Severity upgraded to Medium
• February 10, 2026: €250 bounty awarded

Disclosure Note: This writeup was created after the vulnerability was fixed and with permission from the bug bounty platform. The company name has been anonymized to "EdTech Corp" and all technical details have been sanitized. All information shared is for educational purposes only.