Introduction

In the world of cloud security, the Instance Metadata Service (IMDS) is a fundamental building block. It’s designed to provide virtual machines with a simple way to securely get temporary credentials and critical data without hardcoding secrets. But what happens when that convenience is turned against us?

Over the years, threat actors have learned to turn IMDS into a stepping stone for credential theft, lateral movement, and privilege escalation. This post is about how we used a data-driven methodology to uncover and stop anomalous IMDS usage, and how that approach led us to discover a zero-day vulnerability being exploited in the wild in a popular web service.

What is IMDS?

The Instance Metadata Service is a server running on every cloud compute instance that provides temporary, short-lived credentials and other data to be used by applications running on cloud compute. This allows them to securely access cloud services without needing to hardcode credentials on the machine. While Azure and AWS call this service IMDS, in GCP it’s known as the VM metadata service.

Here’s a basic example of how IMDS is used: Suppose you have an EC2 instance in an AWS environment running an application that needs to access an S3 bucket. Instead of hardcoding AWS credentials into your application or environment variables, the application can retrieve temporary credentials from the instance metadata. From within the EC2 instance, the application can make an HTTP request like this:

This returns temporary credentials associated with the IAM role assigned to the instance. These credentials can then be used to securely interact with AWS services like S3, RDS, or DynamoDB. This allows your application to authenticate securely without storing credentials on the machine, reducing the risk of accidental exposure.

AWS offers two versions of IMDS:

• IMDSv1, the original implementation, allows direct unauthenticated HTTP requests to the metadata endpoint without additional protections. This version is famously susceptible to Server-Side Request Forgery attacks (SSRF) - more on this later.

• IMDSv2, the newer version, introduces session-oriented requests that require a token. This token-based approach increases the complexity of SSRF exploitation since it requires both control of the HTTP Method used (PUT and GET) and the ability to forge request headers.

Most modern guidance recommends enforcing IMDSv2 wherever possible, since many IMDS abuse techniques specifically rely on the weaker security posture of IMDSv1.

The Attacker's Playbook

In order to gain initial access to a cloud environment, attackers typically look for a way to “trick” an application running on an exposed compute instance into querying the IMDS and providing them with the retrieved temporary credentials. They can then move laterally and escalate privileges throughout the environment. In our experience a typical attack targeting IMDS involves exploitation of one of the following types of application vulnerabilities:

• Server-Side Request Forgery (SSRF): A classic technique where attackers leverage a vulnerable web application to send requests on their behalf. If the application can reach the IMDS endpoint and is susceptible to SSRF, the attacker can harvest temporary credentials without needing any direct host access (such as RCE or path traversal).

• Code Injection and Misconfigured Workloads: Applications with injection flaws or unnecessary network access can be manipulated to query IMDS internally, effectively turning the workload into a proxy for the attacker.

Our Approach to IMDS Exploitation Hunting

The Wiz Research team continuously monitors trends across the threat landscape using Wiz Defend’s threat detection rules. Our goal is to track attacker tradecraft (TTPs) as it evolves, so we can rapidly adapt defenses and keep our customers protected.

Part of this includes hunting for global anomalies - behavior that stands out from normal activity across all cloud environments. Our initial threat hunting hypothesis concerning IMDS is that if a common application that doesn’t normally use IMDS suddenly does so, it might indicate that the application has somehow been compromised by an attacker. Using data from our runtime Sensor, we apply a multi-step approach to detect deviations from expected patterns:

1. Finding the Baseline for Normal IMDS Usage

The first question is: "What processes consistently access IMDS, and how often?"

By analyzing telemetry from across environments, we can build a high-confidence list of common, expected IMDS clients like AWS SDKs, nm-cloud-setup, and EC2 agents. This gives us our baseline of “normal” behavior.

2. Identifying Suspicious or Infrequent Access Patterns

Once we know what’s normal, we look for what isn't. We search for processes that access IMDS in only a small fraction of environments; things that commonly exist in cloud environments but usually just never access IMDS.

These rare or one-off access patterns often point to:

• Exploitation of SSRF or RCE vulnerabilities

• Malicious code introduced via supply chain or post-compromise tooling

3. Filtering by Suspicious Metadata Paths

To be even more precise (to avoid false positives caused by rare yet legitimate IMDS usage), we narrow our focus to requests made to sensitive IMDS endpoints. Legitimate software rarely needs to access these, but attackers are drawn to them because they reveal valuable information. For example, an attacker would be highly interested in the following endpoints:

• /latest/meta-data/iam/info:
  Returns information about the IAM role assigned to the instance.

• /latest/meta-data/iam/security-credentials/:
  Returns the list of IAM roles this EC2 instance can assume.

• /computeMetadata/v1/instance/service-accounts/:
  Returns a list of service accounts that the compute instance has access to.

These endpoints are goldmines for attackers trying to figure out what permissions they can abuse. By focusing our detections on these, we can more accurately identify potential threats.

4. Filtering by Compute Context 

Wiz Sensor gathers valuable contextual information about both the process and the container or compute instance it’s running on. This data helps enhance our threat hunting efforts by allowing us to prioritize high-risk scenarios - for example, compute instances with internet exposure, access to sensitive data, or those exhibiting other, less obvious signs of suspicious activity during the same time period.

The following visualization shows our results after filtering the dataset to exclude programs with 0% IMDS access or insufficient data (e.g., those appearing in only one environment).

Real-World Finding 1: Pandoc SSRF

Using the process described above, we uncovered exploitation in the wild of a previously unknown zero-day vulnerability in a popular web service stemming from insecure use of pandoc.

The hunt began with a process named pandoc making an unusual IMDS request. While this binary can be found in numerous environments, in less than 2% of those environments it was consistently accessing sensitive IMDS endpoints, including /latest/meta-data/iam/info. This immediately raised a red flag.

We were initially unfamiliar with pandoc, but a quick search showed it to be a Linux utility used for converting between markup formats. There was no indication in the documentation that it should access cloud credentials or interact with IMDS.

Our investigation led us to a GitHub issue reporting an SSRF vulnerability in pandoc when converting HTML to PDF. The vulnerability, tracked as CVE-2025-51591, stems from pandoc rendering <iframe> tags in HTML documents. This would allow an attacker to craft an <iframe> that points to the IMDS server, or other private resources.

In this case, the web service that was using pandoc failed to include the raw_html flag or the sandbox flag when converting HTML documents, both of which are recommended in the documentation when handling untrusted HTML:

The attacker submitted crafted HTML documents containing <iframe> elements whose src attributes targeted the AWS IMDS endpoint at 169.254.169.254. The objective was to render and exfiltrate the content of sensitive paths, specifically /latest/meta-data/iam/info and /latest/meta-data/iam.

However, the attack was neutralized by the mandatory enforcement of IMDSv2. This protocol invalidates stateless GET requests, such as those initiated by an <iframe>, by requiring a pre-negotiated session token. As the attacker's payload could not perform the initial token retrieval, all requests to the metadata service were rejected, effectively mitigating the threat. If the application were running in an environment still dependent on the IMDSv1 protocol, this attack vector would likely have resulted in credential compromise. Thanks to the use of IMDSv2, the attacker could only access other internal servers, and was unable to pivot to the cloud control plane.

Real-World Finding 2: Clickhouse SSRF

Using the same technique, we identified a Server-Side Request Forgery (SSRF) vulnerability being abused in another widely used application: ClickHouse.

ClickHouse can be found in many cloud environments, but during our hunt we only found one case where the application had access to the Instance Metadata Service (IMDS) within the examined timeframe. That anomalous single hit led us to dig deeper into potential SSRF vectors in ClickHouse.

We came across a particularly useful blog post by researcher PizzaPower, who detailed how ClickHouse’s SELECT * FROM url SQL method can be abused when misconfigured if unauthenticated users are allowed to query arbitrary URLs. We expanded on that research and found that it can be used to access IMDS and read sensitive data such as tokens and secrets provided to the machine.

In our case, the vulnerable instance was running in a GCP environment, which highlights how this technique isn’t limited to AWS, and therefore the hunting methodology described above can be considered cloud-agnostic.

In this case, the attack was unsuccessful due to platform mitigations; the compromised instance simply lacked credentials with sufficient privileges to cause significant damage. However, this outcome was more a matter of luck than design. Had a misconfigured ClickHouse instance with access to private S3 buckets been running instead, the situation could have been far more serious. Combining that access with a feature like READ ON URL open to unauthenticated users would have provided a direct path to a major data breach.

How Can Wiz Help?

These discoveries highlight a key principle of modern cloud security: to find what others can't, you have to look beyond traditional signatures and understand the full context of the environment. At Wiz, our customers benefit from two powerful layers of protection built on this principle.

1. Expert Cloud Threat Intelligence: Our research team combines our knowledge of the cloud threat landscape with threat hunting engagements that reveal real-world vulnerabilities and novel attack techniques like exploitation of previously unknown SSRF vulnerabilities. This proactive, human-driven research provides unique intelligence that goes beyond what automated tools can find on their own.

2. The Wiz Platform: This intelligence is then built into the Wiz platform, which provides continuous, automated protection for your environment:

• Proactive Prevention: Wiz helps you identify misconfigurations, like instances using IMDSv1, and apply the principle of least privilege. This enables you to address attack vectors before they're exploited.

• Real-time Detection: The Wiz platform integrates anomaly-based principles at the environment level, similar to those that found the Pandoc and Clickhouse issues, to raise an alarm when a process that previously did not access IMDS begins to do so.

• Context and Prioritization: Our Security Graph visualizes how a compromised instance could be used for lateral movement or privilege escalation. This helps customers prioritize and fix the issues that pose the most significant risk to your environment.

By combining the power of our threat research with a robust, integrated platform, we help you protect your cloud environment not just from known threats, but from new ones as well.

Securing your cloud environment against IMDS abuse requires both a strong prevention strategy and a robust detection capability. Wiz can help you with both:

Prevention

1. Wiz CSPM and Cloud Configuration Monitoring: Wiz continuously monitors your cloud configurations to identify instances that might be vulnerable to IMDS exploitation, such as those with overly permissive network access or unpatched applications.

2. This includes detection of misconfigured instances for applications like ClickHouse.

3. Identify and Enforce IMDSv2 Usage: Wiz helps you identify instances still using IMDSv1 and provides recommendations to enforce IMDSv2, which requires session tokens, significantly mitigating SSRF risks.

4. Least Privilege Access for Instances: By mapping permissions, Wiz helps ensure that instances and the roles they assume have only the minimum necessary permissions, limiting the blast radius even if IMDS is compromised.

Detection

1. Wiz Runtime Sensor: The Wiz Runtime Sensor detects real-time events and behaviors associated with anomalous IMDS usage, alerting you to suspicious activity as it happens. This includes:

2. Anomalous IMDS Query Patterns: Detection of unusual request volumes or access to sensitive metadata endpoints.

3. IMDS Access from Unexpected Sources: Identifying queries originating from processes not typically associated with IMDS access.

4. Exfiltration Attempts: Monitoring for attempts to move credentials or other sensitive data out of the instance after IMDS interaction.

5. Security Graph Analysis: Wiz's Security Graph visualizes the interconnectedness of your cloud assets, allowing you to quickly identify how IMDS exploitation could lead to lateral movement or privilege escalation within your environment.

6. Threat Intelligence Integration: Wiz integrates with our own internal IOC database as well as 3rd-party threat intelligence feeds to identify known malicious IP addresses or patterns associated with IMDS abuse campaigns, enhancing detection capabilities.

Conclusion

IMDS is a fundamental part of a secure cloud architecture, but its potential for abuse means you can’t take it for granted. By understanding how attackers leverage this service, properly configuring your applications to limit their potential for abuse, and implementing proactive risk and threat monitoring with a platform like Wiz, you can dramatically reduce your attack surface and protect your critical cloud assets from advanced threats. And from a threat hunting perspective, we believe that the key is to stop hunting for needles in a haystack and start looking for what shouldn't be in the haystack at all.

Relevant TTPs