most SSRF bugs fetch data from internal services and return it to the attacker. impactful but usually bounded. this one used SSRF to take over an entire Google Cloud project. Sreeram found a client-side SSRF, where the browser is the one making the request, not the server. a JavaScript execution context on a Google domain was making fetch requests that could be redirected. the target: the GCP metadata endpoint. metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token this endpoint, accessible from any GCP instance, returns the OAuth token for the instance's service account. from the browser running JavaScript on a Google domain, hitting this endpoint returns the token for the underlying cloud instance's service account. with that token, he could authenticate to Google Cloud APIs as the service account, modify project configurations, access cloud resources, and project takeover. client-side SSRF is underrated because people assume SSRF requires server-side execution. if the JavaScript on a page makes fetch() calls and you can influence the URL, the browser itself becomes the SSRF proxy. and browsers on cloud infrastructure have access to metadata endpoints.