Not affiliated with AWS
← Back to Blog

93 HackerOne Reports Show the Same AWS Blast Radius Problem

blast-radiusssrfiamcredential-exposurebreach-analysis

HackerOne's public hacktivity feed is one of the richest sources of real-world vulnerability data available. We analyzed 1,169 AWS-related reports across bug bounty programs from GitLab, Shopify, Slack, the US Department of Defense, and dozens of others. We were looking for a specific pattern: how often does an initial foothold (an SSRF, a leaked credential, an exposed secret) cascade into broad AWS infrastructure access?

The answer: constantly. 93 reports described blast radius escalation where a single compromised credential or SSRF vulnerability unlocked access far beyond the original vulnerability's scope. The organizations affected aren't small startups with immature security programs. They're companies with dedicated security teams, bug bounty programs, and substantial AWS footprints.

The problem isn't that these organizations got breached. The problem is that in nearly every case, the blast radius of the compromised identity was never measured.

The dominant pattern: SSRF to metadata to everything

Of the 93 blast-radius reports, 39 involved SSRF attacks targeting the EC2 instance metadata service at 169.254.169.254. The pattern is always the same:

  1. Find any server-side request forgery vulnerability
  2. Point it at http://169.254.169.254/latest/meta-data/iam/security-credentials/
  3. Retrieve the IAM role name, then fetch temporary credentials (AccessKeyId, SecretAccessKey, Token)
  4. Use those credentials to access whatever the role permits

The attack takes seconds. The blast radius depends entirely on what permissions the stolen role has, and in report after report, those permissions were far broader than necessary.

Real examples from bug bounty programs

Shopify. A researcher exploited a bulk customer update feature on kitcrm to achieve remote code execution. From there, they hit the metadata service, stole IAM credentials, discovered the role could assume additional roles via sts:AssumeRole, and ultimately reached production RDS databases. One SSRF turned into database access across the environment.

US Department of Defense. A Jenkins instance with the Groovy script console enabled allowed direct code execution. The researcher curled the metadata service and retrieved credentials for AmazonSSMRoleForInstancesQuickSetup, a role with permissions to manage AWS resources, create and delete infrastructure, and manage IAM users. In a separate DoD report, a PDF generation tool (FAST) allowed JavaScript injection that reached the metadata service and stole EC2CloudWatchRole credentials.

GitLab. Multiple SSRF bypass reports demonstrated access to internal services including Prometheus, Alertmanager, and Redis. On AWS-hosted instances, the same vulnerabilities reached the metadata service. One researcher noted that on Google Cloud, an equivalent attack could escalate to full root access.

Evernote. A full-read SSRF on www.evernote.com could leak AWS metadata and perform local file inclusion. A separate report chained an open database with XXE in Apache Hive to reach cloud metadata.

DuckDuckGo. The image proxy at proxy.duckduckgo.com accepted an image_host parameter that could be pointed at 169.254.169.254, exposing the instance's IAM credentials.

Slack. A Host header manipulation vulnerability created a blind SSRF that could reach Slack's internal infrastructure metadata.

The list goes on: Dynatrace, Helium, Lichess, Kubernetes, Basecamp, and multiple Node.js ecosystem libraries including Ghost and Uppy all had SSRF-to-metadata paths reported.

Why this keeps happening

EC2's Instance Metadata Service (IMDS) was designed for convenience. Any process running on an EC2 instance can reach it. IMDSv2, which requires a session token obtained via a PUT request, mitigates SSRF-based theft because most SSRF vulnerabilities only allow GET requests. But IMDSv2 adoption remains incomplete. AWS made IMDSv2-only the default for new instances in 2024, but existing instances, containers running on EC2, and services behind legacy configurations often still expose IMDSv1.

The metadata service itself isn't the vulnerability. The vulnerability is what happens after the credentials are stolen. An EC2 instance profile scoped to exactly the permissions the application needs yields a small blast radius even if credentials are stolen. An instance profile with s3:*, secretsmanager:GetSecretValue on *, or sts:AssumeRole without resource constraints turns a simple SSRF into full infrastructure compromise.

The second pattern: leaked credentials as skeleton keys

Beyond SSRF, 16 reports documented direct credential exposure: AWS access keys found in Docker images, public ZIP files, build artifacts, installers, and even leaked from application memory.

Mozilla. A researcher found AWS access keys and database credentials embedded in a Docker image published to Docker Hub. Anyone who pulled the image had the keys.

Glovo. Hardcoded AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY were discovered in an application deployment, along with the S3 bucket name (glovos3), region (eu-central-1), and MySQL and Pusher credentials.

US Department of Defense. A publicly accessible ZIP file contained AWS credentials for us-gov-west-1 — a GovCloud region — along with SMTP credentials, database passwords, and Secrets Manager references. The blast radius of this single file extended across government infrastructure.

Basecamp. A memory safety vulnerability in librsvg, used for image conversion, leaked uninitialized memory from the Rails process. That memory contained AWS access keys and user session cookies. A bug in an image processing library became a credential theft vector.

8x8. AWS credentials were hardcoded directly into an MSI installer package distributed to customers. Anyone who examined the installer had valid AWS keys.

These aren't exotic attack chains. They're credentials sitting in places that anyone can find: public registries, downloadable files, application memory. The blast radius of each leaked credential depends on what that credential can do, and in every one of these reports, it could do too much.

What the data tells us about blast radius

Across all 93 reports, the same structural problem appears: nobody measured what the compromised identity could reach before it was compromised.

Consider the Shopify chain:

SSRF in bulk update feature
  → EC2 metadata service (169.254.169.254)
    → IAM role credentials
      → sts:AssumeRole (multiple target roles)
        → RDS database access
          → Production data

Or the DoD credential exposure:

Public ZIP file
  → AWS keys (us-gov-west-1)
    → Secrets Manager references
      → Database credentials
        → Government data

Or the Mozilla Docker image:

Public Docker Hub image
  → Hardcoded AWS credentials
    → S3, databases, other services
      → Whatever those credentials authorize

Each chain starts differently (SSRF, file exposure, memory leak) but they all end the same way: the attacker reaches everything the identity can reach. The blast radius was determined long before the vulnerability was discovered.

S3 buckets: the quiet multiplier

A related pattern appeared in 26 reports involving S3 bucket misconfigurations. While not credential theft directly, misconfigured buckets amplify blast radius in two ways.

First, bucket takeovers through unclaimed S3 names. Reddit had an S3 bucket referenced in a CI build script that no longer existed. A researcher registered it and could have served malicious build artifacts as official Reddit packages. Brave had the same issue with two separate buckets (brave-apt and brave-browser-rpm-staging), meaning an attacker could distribute malware disguised as Brave browser updates. Kubernetes had an unclaimed Google Cloud Storage bucket loading JavaScript into a release dashboard.

Second, data exposure through misconfigured permissions. The DoD had S3 buckets with full listing and download enabled. Zomato exposed all user chat images. Shopify Ping leaked private store images. Acronis left a ZIP containing admin JWT tokens in an accessible bucket.

In each case, the blast radius of the misconfiguration was never assessed. Nobody asked: "If this bucket is compromised, what does an attacker get?"

The overpermissioned role problem

Four reports targeted AWS's own open-source projects and services for overpermissioned IAM roles:

  • experimental-programmatic-access-ccft: unrestricted sts:AssumeRole capability in a Lambda function
  • aws-lambda-ecs-run-task: overly broad IAM permissions on a Lambda that runs ECS tasks
  • cloudFrontExtensionsConsole: overly broad permissions on a CloudFront Extensions Lambda
  • Amazon MWAA: an outdated Apache Airflow version enabling RCE and lateral movement

If AWS's own projects ship with overpermissioned roles, it's a strong signal that permission scoping is genuinely difficult to get right, and that automated validation is necessary.

IMDSv2 is necessary but not sufficient

The reflex response to SSRF-to-metadata attacks is "enforce IMDSv2." That's correct. IMDSv2 blocks the most common exploitation path. But it only addresses one of the entry points we found.

IMDSv2 does nothing for:

  • Credentials hardcoded in Docker images, installers, or config files
  • Keys leaked through memory safety bugs
  • Credentials exposed in public S3 buckets or ZIP files
  • Overpermissioned roles that grant excessive access regardless of how they're assumed
  • CI/CD build scripts that embed or expose secrets

The common factor across all 93 reports isn't how the credential was obtained. It's that the credential had far more access than it needed. Fixing the entry point is important. Fixing the blast radius is essential.

What blast radius validation looks like

Static IAM policy review catches the obvious cases, like Resource: "*" on sensitive actions. But the HackerOne data shows that the most damaging scenarios involve transitive access: an IAM role that can read secrets, which contain database credentials, which grant access to production data. Or a role that can assume other roles, each with their own permissions.

Effective blast radius validation starts from an identity and maps everything it can actually reach:

  • Which roles can it assume? (And what can those roles do?)
  • Which secrets can it read? (And what do those secrets unlock?)
  • Which databases, buckets, and services can it access?
  • What data is in those resources?

This is the kind of analysis that would have changed the outcome in every one of these 93 reports. Not by preventing the initial vulnerability, but by ensuring the compromised identity couldn't reach beyond its intended scope.

Key takeaways

  • SSRF to IMDS is the most common path to AWS credential theft. 39 of 93 blast-radius reports used this exact chain. Enforce IMDSv2 on every instance, but don't stop there.
  • Leaked credentials are more common than you think. Docker images, installers, ZIP files, memory leaks, build scripts. Credentials end up in places that are trivially accessible. Assume they'll be found.
  • The blast radius is set before the breach. Every one of these reports exploited permissions that already existed. The time to measure blast radius is before an attacker does it for you.
  • Transitive access is the real risk. A role that can read secrets effectively inherits the permissions of every credential stored in those secrets. A role that can assume other roles inherits their permissions too. Linear policy review misses these chains.
  • Even AWS ships overpermissioned roles. If the team that built IAM can get it wrong, your team can too. Automated validation isn't optional.
  • Bug bounty data is blast radius data. Every SSRF, credential exposure, or misconfiguration report is implicitly a blast radius report. The bounty goes to the researcher. The lesson should go to your IAM policies.

Ready to map your blast radius? Sign up for hackaws.cloud and find out what an attacker could reach from your AWS identities before a researcher submits the report.