Attackers are stepping up scans for cloud instance metadata services by hiding the well-known 169.254.169.254 address behind crafted hostnames, making it harder for simple filters to block server-side request forgery traffic[4][14]. Recent telemetry described by the SANS Internet Storm Center shows automated probes hitting generic /proxy endpoints with hostnames that ultimately resolve to the metadata IP, rather than using the raw numeric address defenders typically look for[4][14]. The tactic directly targets applications that naïvely block requests containing the literal string 169.254.169.254 or maintain static denylists of URLs, but fail to re-validate the resolved destination before connecting[4][6].
The cloud instance metadata service has long been identified as one of the highest-value SSRF targets because it exposes configuration details and, critically, temporary credentials for roles attached to virtual machines[2][3][12]. In AWS, Azure and GCP, the metadata service is reachable from each instance via the link-local 169.254.169.254 address, which never leaves the host but can be reached by any process with network access on that machine[2][5][9]. Numerous offensive write-ups show how a single SSRF primitive can be pointed at paths such as /latest/meta-data/iam/security-credentials/ to retrieve access keys, secret keys and session tokens for the cloud account, turning an innocuous-looking web request into full-control cloud compromise[3][5][12]. This combination of fixed address, unauthenticated metadata access in older configurations, and high-value secrets has made 169.254.169.254 a staple in red-team playbooks and automated exploit tools for several years[2][3][13].
The latest scans highlight how easily attackers can bypass brittle defenses that only recognize direct IP literals in outbound URLs[4][6]. Instead of requesting http://169.254.169.254/ outright, tools encode the numeric address inside hostname labels—such as subdomains where each octet appears as part of the name—so the application happily forwards the request, trusting the benign-looking domain[4]. When that hostname is resolved, DNS responds with the forbidden 169.254.169.254 address, and the proxy or SSRF-vulnerable feature completes the connection anyway, because it never checks the final destination against any blocklist[4][6]. More sophisticated campaigns may combine this with DNS rebinding, returning a harmless IP during validation and then switching to the metadata IP for the actual request, further undermining static filtering strategies[4][6].
Cloud incident reports over the past year underline that this is not a theoretical concern but a regularly abused access path[3][5][15]. A recent misconfiguration spotlight from the Cloud Security Alliance, for example, described an unauthenticated SSRF flaw in MLflow that allowed attackers to redirect webhook traffic to metadata services and steal IAM credentials, earning a critical CVSS 9.3 rating and a place on CISA’s Known Exploited Vulnerabilities list[15]. That entry was added with an explicit remediation deadline, reflecting regulators’ view that SSRF-to-metadata chains represent systemic risk for cloud tenants who expose internal control-plane services to the internet[15]. Similar cases across multiple platforms show that once metadata credentials are obtained, adversaries move quickly to create new access keys, pivot into storage and data analytics services, and establish durable footholds that are difficult to distinguish from legitimate cloud activity[3][5].
Defenders attempting to protect cloud workloads from these campaigns are being pushed beyond simple pattern matching and IP denylisting[6][9]. Application-layer SSRF controls need to resolve hostnames and verify the resulting IPs against allowlists or blocklists immediately before connecting, rather than trusting user-supplied URLs or relying solely on the absence of suspicious strings[6]. Network teams are increasingly advised to block egress to metadata service addresses such as 169.254.169.254/32 from application subnets, and to restrict access via host-level firewalls so only tightly controlled processes can query metadata[6][9]. On AWS, enforcing IMDSv2—which requires a session-oriented token and specific HTTP methods—adds a crucial defense-in-depth layer that can foil many commodity SSRF exploits even when they reach the metadata endpoint[7][9]. More broadly, routing server-side URL fetching through dedicated proxy services with strict destination allowlists, combined with continuous monitoring for odd hostnames resolving to link-local IPs, is emerging as a practical baseline to keep these obfuscated SSRF probes from turning into full-blown cloud breaches[6][9].
References
- Exploiting Cloud Metadata via SSRF: 169.254.169.254 on AWS …
- SSRF to AWS Metadata Exposure: How Attackers Steal Cloud …
- Internet Storm Center Diary 2026-08-24 – SANS ISC
- Vulnerable Code /…
- Server-Side Request Forgery (SSRF): From Internal Port Scan …
- Add defense in depth against open firewalls, reverse proxies, and …
- Securing the EC2 Instance Metadata Service | Datadog Security Labs
- Abusing the AWS metadata service using SSRF vulnerabilities
- AWS – Metadata SSRF – Internal All The Things
- /proxy/ URL scans with IP addresses – SANS ISC
- CISO Daily Briefing – August 19, 2026
