exploiting-ssrf-to-cloud-metadatalisted

# Exploiting SSRF to cloud metadata: reach is what makes it critical A server that fetches a URL an attacker can influence is only dangerous if that fetch reaches something worth reaching. The highest-value target in a cloud environment is the instance metadata service, a link-local endpoint that returns the workload's credentials to anything that can make it a request. Turning an SSRF lead into a real finding means proving the request is steerable, reaches an internal target, survives the filters, and returns something that matters, usually a credential. ## When to use - A feature makes a server-side request to a URL, host, or address the user influences (a webhook, importer, link preview, URL parameter). - You are triaging an SSRF lead and need to know its real impact. - You are assessing exposure of a cloud workload's metadata and credentials. ## Scope check Test only infrastructure you are authorized to assess. Retrieve credentials solely from your own instances and revoke them after. If you can't name the authorization, stop. ## The loop 1. **Confirm the fetch is attacker-steered.** Find the feature that makes a server-side request and confirm the destination, or part of it, comes from your input. If you cannot influence where the request goes, there is no SSRF; if you can, establish exactly which part (scheme, host, path, port). 2. **Establish internal reach.** Point the request at addresses the server should never fetch on your behalf: loopback, l