Cloud Security — Real World

Capital One, 2019 — the canonical SSRF-to-metadata-service breach

A misconfigured web application firewall in front of a Capital One web application allowed a Server-Side Request Forgery vulnerability to be exploited, which was used to query the AWS instance metadata service and obtain temporary IAM credentials for a role attached to the affected instance. Those credentials were then used to access and exfiltrate data from S3 buckets the role had permission to read, affecting a very large number of customers and applicants. > Note (unverified specifics): the exact number of affected individuals and precise technical details of the WAF misconfiguration are best confirmed against Capital One's own public disclosures and the subsequent legal/regulatory filings rather than this summary — the general attack chain (SSRF → metadata service → temporary credentials → S3 data access) is the well-documented, widely-cited part, and is precisely why this page's Intermediate section treats this attack class as a priority, not a theoretical edge case.

Lesson directly relevant to this page: this incident is the real-world reason IMDSv2 (see Intermediate/Cheatsheet) exists and why enforcing it — not just having it available — matters. At the time of this incident, the token-required metadata access model wasn't the default; a role's over-broad S3 permissions also compounded the impact, meaning least-privilege IAM (see Fundamentals) would have limited the blast radius even if the SSRF/metadata exploitation had still occurred.

Uber, 2016 — credentials leaked in a code repository

Attackers obtained AWS credentials that had been stored in a private code repository used by Uber engineers, and used those credentials to access cloud storage containing data on a large number of Uber users and drivers. > Note (unverified specifics): the exact scale of affected individuals and full details of how the credentials were specifically discovered are best confirmed against Uber's own disclosures and subsequent regulatory settlement documents — the general shape (long-lived credentials stored in a repository, later compromised and used to access cloud storage) is the well-documented, widely-cited part.

Lesson directly relevant to this page: this is a direct, real-world illustration of why this page's Fundamentals section emphasizes short-lived, role-based credentials over long-lived access keys wherever possible — a credential that exists indefinitely in a repository (even a private one, since "private" doesn't mean "immune to compromise") remains a standing risk for as long as it's valid, in a way a short-lived, auto-rotating credential structurally cannot be. It's also a case for secrets-scanning tooling in CI/CD pipelines (catching a credential committed to a repo before it's ever merged) as a concrete, automatable prevention step, not just a policy reminder to "not do that."

A general, widely-observed pattern worth naming: alert fatigue from unfiltered CSPM output

Not a single named incident, but a genuinely common organizational failure pattern worth flagging honestly as a pattern rather than attributing to one specific case: security teams that enable comprehensive CSPM/detection tooling without building a real triage framework (see Intermediate) commonly end up with hundreds or thousands of findings, most low-priority, with no clear signal for what's actually urgent — and the common real outcome isn't that the team fixes everything, it's that the volume becomes unmanageable and the tool's alerts start getting ignored wholesale, including the genuinely critical ones mixed in with the noise.

Lesson: enabling detection tooling is necessary but not sufficient — without a working triage process on top of it, more detection can paradoxically make an organization's actual security posture worse by training the team to tune out alerts generally, not just the low-priority ones.