SSRF in Metadata Proxy Endpoint Allows Cloud Credential Theft

Overview

A “fetch remote resource” feature intended to let users import a file from a URL did not restrict which hosts could be requested, allowing a request to be redirected at the cloud provider’s instance metadata endpoint (169.254.169.254) and returned to the attacker in the response body.

Impact

An authenticated user could retrieve the temporary IAM credentials assigned to the underlying compute instance’s role, potentially escalating access to any cloud resource that role was permitted to reach — well beyond what the application itself was meant to expose.

Affected Products

• Halden Cloud’s internal metadata-proxy microservice, prior to the mitigation described below

Technical Details

The fetch feature accepted an arbitrary URL, performed a server-side HTTP request to it, and returned the response body to the caller. No allowlist or denylist was applied to the target host, and the service ran with an attached instance role that had broader permissions than the application itself required. Pointing the fetch at the metadata service’s credential path returned the role’s active access key, secret key, and session token in plaintext.

Remediation

Short-term mitigation blocked outbound requests to link-local address ranges (169.254.0.0/16) at the network layer and enforced IMDSv2 (which requires a session token obtained via a PUT request that this SSRF pattern could not replicate) on the underlying instances. Longer-term, the fetch feature was rebuilt with an explicit allowlist of permitted destination hosts, and the instance role was scoped down to only the permissions the service actually uses.

Disclosure Timeline

• 2025-08-10 — Identified during an internal cloud security review
• 2025-08-12 — IMDSv2 enforcement and network-layer block deployed same day
• 2025-08-22 — Allowlist-based fix deployed, advisory published