SSRF to internal dashboards: a bug-bounty walkthrough

Server-Side Request Forgery turns your server into my HTTP client. Point it at 169.254.169.254 and a cloud metadata service hands over credentials. Here's a real-shaped walkthrough of how a benign-looking feature became a full read of an internal network.

The entry point

A "link preview" endpoint fetched any URL the user submitted and rendered its <title> and og:image. Classic SSRF surface.

request.http

1POST /api/preview HTTP/1.12{ "url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/" }

Why this is dangerous

The metadata endpoint requires no authentication — it trusts the network position. A server that fetches attacker-controlled URLs is that trusted position.

Escalation path

timeline

Confirm SSRF — fetch a server you control, see the request land.

Probe internal ranges — 169.254.169.254, 10.0.0.0/8, localhost ports.

Read IAM creds — temporary keys from the metadata service.

Pivot — use the keys against internal dashboards and S3.

The fix

Allowlist

owns: which hosts are reachable

deny RFC-1918deny link-local

Resolve the host, check the *resolved IP* against a denylist — not the string.

IMDSv2

owns: metadata hardening

require a session tokenhop limit = 1

Session-token metadata defeats the simplest SSRF-to-credentials chain.

🔒

Disclosure note

This composite walkthrough is for education and authorized testing only. Never point these techniques at infrastructure you don't have written permission to test.