This repository catalogs AWS customer breaches by root cause, not by exposed bucket

The taxonomy, not the logo wall

aws-customer-security-incidents is described as a repository of breaches of AWS customers, and the README states its purpose plainly: cloud security must be threat-informed, and this repository compiles public data on security incidents impacting AWS customers to guide prioritised security investment.

The catalog is a Markdown table with a fixed set of columns.

| Name  | Date | Root Cause | Escalation Vector(s) | Impact | Link to details|

Root Cause, Escalation Vector(s) and Impact are the columns that make this a dataset rather than a list of news stories. The company name is the least informative part of a breach, because the same company can appear twice with completely different causes. Uber appears in 2014 with a GitHub Gist holding AWS credentials, and again in 2016 with roughly thirteen hacked credentials bought on a forum that led to a private GitHub repository. Same company, different failure, different escalation path.

So the design choice here is to index incidents by the mechanism of compromise. A reader who wants to know what to fix first can look at the root cause column and see which failures recur, and can look at the escalation vector column to see what an attacker does once they have one credential.

The repository is not archived, the last push was on 2026-09-09, and there are no GitHub releases. The licence is GPL-3.0, with a LICENSE file at the root.

Exposed buckets are excluded on purpose

The most consequential sentence in the README is the exclusion rule.

The repository seeks to index all publicly disclosed AWS customer security incidents with a known root cause, and it will exclude incidents involving exposed data stores, for example S3 bucket leaks and exposed managed or hosted databases.

The stated reason is that those incidents are already well understood, and examples can be found catalogued in places like nagwww's s3-leaks repository, upguard's reports, hackmeggedon's annual rollup reports for 2022, and Corey Quinn's LWIAWS S3 Bucket Negligence Award.

That is a scope decision with a rationale, and it changes what the dataset is for. If you want a complete breach record, this is not it, and the README names four other catalogues that cover the excluded category. If you want to know which failures are less obvious than a misconfigured bucket, then this is the list.

The same logic applies to the root cause requirement. Only incidents with a known root cause are indexed, so there is no category for the compromise whose cause was never established. That is a deliberate gap, and it means the table under-represents the incidents where the vendor did not disclose enough.

It also means the entries are curated rather than scraped. Someone decided that the root cause was known, and recorded it.

Credentials in git are the recurring thread

Reading down the root cause column, one pattern dominates: credentials left where they should not be.

GitHub appears again and again. Uber in 2014 had a GitHub Gist containing a data analysis script with AWS credentials. Lynda.com in 2016 had a private GitHub repository with AWS credentials. DXC Technologies in 2017 had a private AWS key exposed via GitHub. Drizly in 2018 had AWS credentials committed to a public GitHub repository.

The escalation vectors in those rows are more varied than the root causes, which is the interesting part. For DXC the attacker started 244 EC2 instances, and the impact was cryptomining. For Drizly the impact was also cryptojacking. For Uber in 2016 the escalation was a private repository, and the impact was names and driver licence numbers of 600,000 drivers plus personally identifiable information of 57 million users in an unencrypted manual backup.

The same credential, two very different outcomes. A leaked key used for mining is a nuisance; a leaked key that also opens a path to a customer database is a breach. That difference is exactly what the escalation vector column makes visible, and it is why the catalogue is worth more than a list of company names.

A second thread is the human path: shared credentials used by people rather than machines. Chegg in 2018 had a former contractor abuse a broadly shared root credential. Reddit in 2018 had an employee SMS intercepted for a two factor bypass. Timehop in 2018 had compromised admin credentials without MFA, affecting 21 million users. Voova in 2019 had stolen credentials used by a former employee, who deleted 23 servers.

The catalogue is spread across several files

The README holds the main table, but the repository root shows that this is a structured archive rather than a single document. There are ACTORS.md, DISCLOSURE.md, KEYLEAKS.md, REPORTS.md, SSRF.md and USAGES.md alongside the README, a .claude directory, a .gitignore and the LICENSE file.

The names imply a decomposition by incident type. KEYLEAKS.md is presumably the credential exposure cases, which the table confirms is the dominant category. SSRF.md points at a distinct class: the Politifact entry in 2017 is attributed to a misconfigured cloud computing server with Coinhive cryptojacking as the impact, and a server side request forgery category would sit beside the key leak category rather than inside it.

DISCLOSURE.md and ACTORS.md point at a second axis, which is who disclosed and who was involved. The Uber 2014 and 2016 rows both link to a blameless post-mortem of the case against Joseph Sullivan, and the Drizly and Chegg rows link to Federal Trade Commission complaint documents, which are the kind of primary document that establishes a root cause in a way that a news report does not.

USAGES.md and REPORTS.md are less obvious from the names alone, and the README does not describe their contents, so it would be guessing to say what they hold.

For an evaluator, this file layout is the thing to check first. A single table with four thousand words and a dozen specialist files are different artifacts, and the table shown in the README is the readable front door to something larger.

Blameless framing, and why the repository says so explicitly

The README has a section headed A Note on Blameless Postmortems, and the point it makes is worth taking at face value.

The repository is in no way intended as a criticism of the listed companies. In the spirit of blameless postmortems, the goal is to learn from incidents without an atmosphere of blame.

That framing is doing real work here, because a table of companies with breach dates reads like an indictment no matter what the prose says. The Root Cause column is the mechanism that makes the framing coherent: a shared root credential is a control failure that an organisation can fix, and the entries that are most useful to a reader are the ones that recur, which is only visible if the same cause is recorded consistently across different companies.

The GitHub credential pattern is a good example. Reading the Uber 2014, Lynda.com 2016, DXC 2017 and Drizly 2018 rows together, the conclusion is not that those four organisations were careless people. It is that a specific failure mode, secrets in a git repository that is not private, is common enough to appear across years and industries, and that a secret scanning control with a defined response time would have caught all four.

One more field to note. The Impact column mixes magnitudes that are not comparable: 50,000 records in one row, 57 million users of personally identifiable information in another, cryptojacking in a third, and deleted servers in a fourth. That is a consequence of indexing every disclosed incident rather than only the large ones, and it means you should read the Impact column as a description rather than as a comparable score.

Where this dataset will not take you

The first limitation is that it is a summary layer over public reporting, not a primary source. Every row links out to a news article, a blog post from the affected company, a regulatory complaint or a court filing. Those links are the actual evidence. The root cause and escalation vector fields are somebody's reading of that evidence, sometimes from a postmortem the company wrote, sometimes inferred from what an attacker did afterwards. If a finding matters to you, follow the link and check the characterisation against the source.

The second limitation is the known root cause requirement. Incidents where the cause was never established are absent, and those are the ones that most often represent novel techniques. A catalogue indexed by cause will systematically under-represent the genuinely new attack, because the new attack is the one where nobody can yet say what the root cause was.

The third is that the entries are AWS-centric in the sense of AWS customer breaches, not AWS platform breaches. Code Spaces in June 2014 is the row that shows the difference: the root cause is listed as AWS Console Credentials with a question mark, and the impact was wiping S3 buckets, EC2 instances, AMIs and EBS snapshots. That is an incident about the console and its credentials, not about a customer misconfiguration, and the escalation vector, an attacker creating additional accounts and access keys, is a platform access path rather than a customer control failure.

The fourth is that the dataset is only as current as its last push on 2026-09-09, and there is no release, no version and no stated cadence. For a dataset meant to inform prioritised investment, a stale list is a specific kind of misleading, because it can read as exhaustive when it is not.

How it compares with the breach catalogues it points at

The README names four alternatives for the excluded category, and comparing with them shows the difference in kind between this repository and a general breach list.

nagwww's s3-leaks repository, upguard's reports, hackmeggedon's annual rollup reports and Corey Quinn's LWIAWS S3 Bucket Negligence Award all catalogue the same class: a bucket that was left open or misconfigured. That class is mechanical to detect, there are tools that find it automatically, and the interesting question is only how many are still open and who owns them.

This repository covers everything else, and everything else is where the design work has to happen. An attacker with a key needs somewhere to use it. The escalation vectors in the table describe those paths: creating IAM users and access keys, starting EC2 instances, mounting backups, copying snapshots to the attacker's own account, resetting an account password through email compromise, and using the cloud to mine cryptocurrency.

Those paths are what a security team can act on directly. A leaked key in a git repository is a scanning and secret rotation problem. An attacker creating IAM users is a permissions and detection problem. An attacker copying snapshots into their own account is a data protection and account monitoring problem. Each maps to a different control, which is why the escalation vector column carries more weight than the impact column for prioritisation.

The other alternative is simply using an incident response postmortem collection, or your own incident history. Those are richer per incident and they are about your organisation rather than about a population, but they have the obvious sample size problem. This catalogue trades depth for breadth, and the breadth is the point.

Editorial conclusion

aws-customer-security-incidents fits a security team that wants to know which failures lead to an AWS compromise rather than which companies were breached, and it is a reasonable starting point for a prioritisation exercise as long as you read the taxonomy columns rather than the company names. It does not fit a compliance task that needs a formal record of every breach, and it is not a substitute for the other breach catalogues it points at for exposed buckets. Before using it, read DISCLOSURE.md, KEYLEAKS.md, SSRF.md, USAGES.md, ACTORS.md and REPORTS.md to see how the catalogue is organised, and treat every entry as a lead rather than a finding, since the rows are summaries of public reporting and the repository itself states that its goal is to learn from incidents without an atmosphere of blame.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. ramimac/aws-customer-security-incidents on GitHub
4. README