Five SSRF Scenarios That Lead to Compromise
SSRF (Server-Side Request Forgery) is a technique that forces a server to make requests from within its own network.
➖ Cloud metadata → credential theft (AWS / GCP)
http://169.254.169.254/latest/meta-data/
🔜 Retrieve IAM credentials
🔜 Gain access to S3 / APIs / other services
One of the most common and repeatedly confirmed scenarios in bug bounty programs.
➖ Access to internal admin panels
— /admin
— /internal-api
— debug endpoints
🔜 SSRF bypasses network segmentation
🔜 The server itself makes “internal” requests
➖ Access to internal services (Redis / Elasticsearch)
If SSRF supports non-standard protocols:
— Redis → data injection / potential chains leading to RCE
— Elasticsearch → index and data leakage
🔜 Depends on SSRF implementation (e.g., gopher://, raw TCP)
➖ Local file read (file://)
file:///etc/passwd
🔜 Leakage of configs, keys, tokens
⚠️ Not supported in all implementations (depends on the client)
➖ SSRF → RCE chains
SSRF is rarely the final goal.
🔜 Often used as a pivot:
— Access to internal APIs
— Triggering webhooks / callbacks
— Further exploitation leading to RCE
