Enabling IMDSv2: Strengthen Modern EC2 Security Effortlessly

CVE-2025-49127: Kafbat UI Remote Code Execution via JMX Unsafe Deserialization
CVE-2025-49127: Kafbat UI Remote Code Execution via JMX Unsafe Deserialization
July 14, 2025
Top 10 Offensive Security Companies in India (Updated 2025)
Top 10 Offensive Security Companies in India (Updated 2025) 
July 21, 2025

July 17, 2025

Misconfigured EC2 instances have opened the door to real-world SSRF attacks. The common culprit? Leaving IMDSv1 enabled and exposed. It’s a small oversight, but one that gives attackers access to sensitive metadata—sometimes even IAM credentials.

That’s why switching to IMDSv2 isn’t just best practice—it’s basic hygiene.

In this post, we’ll explain what IMDSv2 actually does, why it matters, and how you can enable it with minimal disruption. If you’re running workloads on AWS EC2, this is one setting you don’t want to ignore.

Understanding Instance Metadata

IMDSv1 served us well when cloud security was simpler. But in today’s threat landscape, it just doesn’t hold up.

IMDSv1 responds to requests without requiring any kind of identity or session control. That makes it an easy target for attackers using SSRF or other injection techniques to steal credentials.

IMDSv2 fixes that by requiring a token. Every request must first fetch a short-lived session token. Without it, access is denied—period. This simple change makes SSRF-style attacks far harder to pull off.

Think of it as locking the door and asking for ID before handing over the keys.

Why IMDSv2 is Critical for Cloud Security

IMDSv1 has been a longstanding method for accessing instance metadata. However, its vulnerability to SSRF attacks has become a significant security concern, potentially exposing metadata to unauthorized users. IMDSv2 addresses this issue by implementing session-oriented requests requiring requester authentication. By demanding a valid token with each request, IMDSv2 effectively mitigates the risks associated with IMDSv1.

How to Implement IMDSv2 for Enhanced Security

To upgrade to IMDSv2, you need to modify your EC2 instance configurations. Use the following AWS CLI command to implement these changes:

bash

aws ec2 modify-instance-metadata-options –instance-id i-1234567890abcdef0 –http-tokens required –http-put-response-hop-limit 2

  • Http-tokens required: This ensures that metadata cannot be accessed without a valid token, significantly improving security.
  • Http-put-response-hop-limit: This controls the number of network hops allowed, providing additional control over metadata access.

Key Things to Consider When Transitioning to IMDSv2

Here are the key things to consider while transitioning: 

  1. Evaluate Existing Configurations: Conduct a comprehensive review of your current EC2 instance settings.
  2. Plan the Transition: Develop a strategy for adopting IMDSv2 across your instances.
  3. Implement Changes: Use the AWS CLI command mentioned earlier to enable IMDSv2.
  4. Ongoing Monitoring: Regularly review your security practices and permissions to ensure optimal protection.

For further risk mitigation, consider leveraging specialized services such as SecureLayer7’s Red Team, Pentest, and API Scanner solutions to identify and address vulnerabilities in your infrastructure.

Conclusion

Misconfigurations like IMDSv1 exposure don’t always show up on your radar—until someone exploits them.

SecureLayer7’s penetration testing dig deeper than traditional scanners. We find the weak spots hiding in plain sight, like SSRF targets or open metadata endpoints.

Want to be sure your AWS setup is hardened against today’s threats? Let SecureLayer7 break it—before an attacker does. Contact us now to secure your system. 

Discover more from SecureLayer7 - Offensive Security, API Scanner & Attack Surface Management

Subscribe now to keep reading and get access to the full archive.

Continue reading