How do I install the Cloud Imds Ssrf skill?

Run npx skillmds@latest add noorqureshi/cloud-imds-ssrf in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Cloud Imds Ssrf safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Cloud Imds Ssrf?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Cloud Imds Ssrf free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Cloud Imds Ssrf?

NoorQureshi (@noorqureshi) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Cloud Imds Ssrf by noorqureshi — Agent Skill

Name: Cloud Imds Ssrf
Author: NoorQureshi

Cloud Imds Ssrf

Escalate SSRF to cloud credential theft via the instance metadata service (IMDS). Load when SSRF is confirmed AND the target runs on AWS/GCP/Azure. Signals: 169.254.169.254 reachable, cloud-hosted app, SSRF that can set arbitrary Host/headers, "metadata".

NoorQureshi 958fa29 2.2 KB Updated Sep 17, 2026

File contents

SSRF → cloud metadata → IAM credential theft

When it applies

You have SSRF and the app runs on a cloud VM/container with an attached role. The metadata endpoint hands out temporary credentials to anything that can reach it from the instance.

Why it works

IMDS lives at a link-local IP (169.254.169.254) and trusts network position, not identity. SSRF gives you that position, so the app fetches the instance's role credentials for you — then you use them against the cloud API with the app's permissions.

Method

AWS IMDSv1 (no token): SSRF to http://169.254.169.254/latest/meta-data/iam/security-credentials/ → role name → .../security-credentials/<role> returns AccessKeyId, SecretAccessKey, Token.
AWS IMDSv2 (token required): needs a PUT to get a token, then a header on the GET — possible only if the SSRF can set method + X-aws-ec2-metadata-token header. Many SSRFs can't; note IMDSv2 as the mitigation if it blocks you.
GCP: http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token with header Metadata-Flavor: Google (needs header-setting SSRF).
Azure: http://169.254.169.254/metadata/identity/oauth2/token?... with Metadata: true.
Use the creds (in scope only): configure the CLI with the temp key/secret/token and run read-only calls (aws sts get-caller-identity, s3 ls) to prove impact — don't touch data.

Gotchas

IMDSv2/Metadata header requirements defeat header-less SSRF — that's a finding (says v2 is on), not a dead end.
Temp creds expire fast; grab sts get-caller-identity immediately as proof.
Containers may hit the ECS task metadata (169.254.170.2) instead of EC2 IMDS.

Verify success

aws sts get-caller-identity (or GCP/Azure equivalent) returns the instance role identity using credentials pulled through the SSRF.

References

PortSwigger SSRF labs; AWS IMDSv2 docs; "SSRF to cloud takeover" write-ups.

---name: cloud-imds-ssrfdescription: Escalate SSRF to cloud credential theft via the instance metadata service (IMDS). Load when SSRF is confirmed AND the target runs on AWS/GCP/Azure. Signals: 169.254.169.254 reachable, cloud-hosted app, SSRF that can set arbitrary Host/headers, "metadata".---# SSRF → cloud metadata → IAM credential theft## When it appliesYou have SSRF and the app runs on a cloud VM/container with an attached role. The metadataendpoint hands out temporary credentials to anything that can reach it from the instance.## Why it worksIMDS lives at a link-local IP (`169.254.169.254`) and trusts *network position*, not identity.SSRF gives you that position, so the app fetches the instance's role credentials for you —then you use them against the cloud API with the app's permissions.## Method1. **AWS IMDSv1** (no token): SSRF to `http://169.254.169.254/latest/meta-data/iam/security-credentials/` → role name → `.../security-credentials/<role>` returns `AccessKeyId`, `SecretAccessKey`, `Token`.2. **AWS IMDSv2** (token required): needs a PUT to get a token, then a header on the GET — possible only if the SSRF can set method + `X-aws-ec2-metadata-token` header. Many SSRFs can't; note IMDSv2 as the mitigation if it blocks you.3. **GCP**: `http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token` with header `Metadata-Flavor: Google` (needs header-setting SSRF).4. **Azure**: `http://169.254.169.254/metadata/identity/oauth2/token?...` with `Metadata: true`.5. **Use the creds** (in scope only): configure the CLI with the temp key/secret/token and run read-only calls (`aws sts get-caller-identity`, `s3 ls`) to prove impact — don't touch data.## Gotchas- IMDSv2/`Metadata` header requirements defeat header-less SSRF — that's a finding (says v2 is on), not a dead end.- Temp creds expire fast; grab `sts get-caller-identity` immediately as proof.- Containers may hit the ECS task metadata (`169.254.170.2`) instead of EC2 IMDS.## Verify success`aws sts get-caller-identity` (or GCP/Azure equivalent) returns the instance role identityusing credentials pulled through the SSRF.## ReferencesPortSwigger SSRF labs; AWS IMDSv2 docs; "SSRF to cloud takeover" write-ups.

Frequently asked questions