SSRF Bug Bounty 2026 — Server-Side Request Forgery from Finding to Full Cloud Takeover | Bug Bounty Course Day 33 of 60

This article is a comprehensive guide to identifying, testing, and reporting Server-Side Request Forgery (SSRF) vulnerabilities in web applications, with a focus on cloud environments. It addresses how attackers can leverage SSRF to access internal resources, cloud metadata endpoints, and sensitive credentials that are unreachable from the public internet. SSRF matters because it can escalate from information disclosure to full cloud account compromise, and systematic testing methodology is essential for both finding these bugs and writing credible reports.

• SSRF fundamentals and server network positionSSRF occurs when an application fetches a remote resource based on unvalidated user input, allowing the server to make requests with its own network privileges. The core vulnerability stems from the server's network position and permissions—it can reach internal services, private APIs, and cloud metadata that the attacker's browser cannot. The article emphasizes assessing each component separately (authentication, firewalls, URL parsing, supported methods) rather than treating one successful request as proof of total internal access.
• Systematic SSRF entry point discoveryThe article identifies SSRF by searching for URL-accepting parameters across HTTP history, with specific focus on parameter names like url=, src=, href=, link=, fetch=, proxy=, and callback=. It extends beyond obvious parameters to include less obvious vectors like PDF generators with img src attributes, SVG uploads, XML imports, webhook configurations, and integration setup fields. Filtering by parameters containing 'url' or 'src' in Burp Suite surfaces approximately 60-70% of SSRF candidates on modern SaaS applications.
• AWS metadata exploitation as critical findingWhen SSRF reaches 169.254.169.254 (the AWS Instance Metadata Service), the exploitation path is straightforward and high-impact. The attack chain involves confirming metadata access at the root, checking for available IAM roles, then fetching credentials from the path /latest/meta-data/iam/security-credentials/[RoleName]. The response contains AccessKeyId, SecretAccessKey, and Token—credentials valid for up to 6 hours that auto-rotate, creating persistent attack surface. The article emphasizes stopping immediately after screenshot documentation and reporting, explicitly forbidding further use
• Blind SSRF detection with out-of-band techniquesBlind SSRF occurs when the server makes internal requests but doesn't return response content. Detection requires out-of-band callbacks using tools like Burp Collaborator, webhook.site, or interactsh—the attacker provides a URL pointing to controlled infrastructure and observes whether the server makes DNS lookups or HTTP requests to it. A DNS callback confirms outbound hostname resolution (Medium severity); an HTTP callback confirms full outbound HTTP capability (Medium-High severity). The article notes that Burp Suite Pro's Collaborator is the standard tool, but Community edition users have
• SSRF filter bypass through alternate IP notationApplications attempting to block SSRF via string matching can be bypassed using alternate representations of the same IP address. Techniques include decimal notation (169.254.169.254 as 2852039166), hexadecimal (0xa9fea9fe), octal notation (0251.0376.0251.0376), URL encoding, IPv6 representation like [::ffff:169.254.169.254], and DNS rebinding using wildcard services like nip.io. The article also mentions redirect chains—if the server follows HTTP redirects, hosting the SSRF payload on attacker-controlled infrastructure and redirecting to the blocked IP can bypass simple blocklists.
• Severity rating based on reachable resourcesThe article establishes a severity framework: blind SSRF with DNS callback only = Medium; blind SSRF with HTTP callback = Medium-High; basic SSRF reading internal service responses = High; SSRF to AWS metadata with instance IDs = High-Critical; SSRF returning IAM credentials = Critical. Severity depends on what the server's identity can access rather than the word 'SSRF' alone. The rating must be supported by specific evidence—the accessible resource type and permissions available to the compromised identity.
• Report structure for credible impact narrativeEffective SSRF reports include numbered steps to reproduce, Burp Repeater screenshots at each key moment, and concrete impact statements describing what an attacker could do with the access gained. For blind SSRF findings, the Collaborator interaction screenshot is core evidence. For metadata findings, the response body showing AccessKeyId is what elevates severity. The article provides a template showing affected endpoint, vulnerable parameter, full reproduction steps, and specific remediation actions like IMDSv2 implementation, URL allowlisting, RFC 1918 blocking, and egress proxy enforcemen
• IMDSv2 as partial but incomplete mitigationIMDSv2 prevents most SSRF exploitation by requiring a PUT request with X-aws-ec2-metadata-token-ttl-seconds header before metadata access is granted. Standard SSRF via GET parameters cannot perform this PUT preflight, making it an effective defense against basic SSRF. However, the article notes this is a mitigation rather than complete fix—some HTTP libraries used for SSRF can make PUT requests, follow redirects, or send arbitrary headers, potentially bypassing IMDSv2 in specific circumstances. It is one layer of defense, not a complete solution.

Bottom line: SSRF is found by systematically identifying URL-accepting features in applications, confirmed through controlled testing against localhost and internal IP ranges, and escalated to critical severity when cloud metadata endpoints are reachable. The key to both finding and reporting SSRF is understanding what the server can reach with its own network privileges—not just proving you can make it make a request, but documenting what sensitive resources or credentials become accessible as a result.