Uber, 2016: a key in a repository, and a year before anyone was told.
Intruders found a cloud access key in plain text in a private code repository and downloaded rider and driver data. Uber paid them through its bug bounty programme and disclosed the breach a year later. What the FTC and the state attorneys general found.
Last updated Published by TryTrustableNot legal advice
In late 2016 intruders accessed Uber's GitHub repositories, by their own account with passwords exposed in earlier breaches, found an access key in plain text and used it to download 16 files from Uber's Amazon S3 storage. The files held data on 57 million users worldwide. Uber paid the intruders $100,000 through its bug bounty programme and did not disclose the breach to consumers or the FTC until November 2017. The FTC expanded its 2017 consent order, and in September 2018 Uber agreed a $148 million settlement with all 50 states and the District of Columbia.
What happened
| Date | What happened |
|---|---|
| 13 October to 15 November 2016 | Intruders download 16 files from Uber's Amazon S3 datastore (FTC complaint). |
| 14 November 2016 | An attacker contacts Uber, claims to have compromised its databases and demands a six-figure payout (FTC complaint). |
| After discovery | Uber pays the attackers $100,000 through the third party that runs its bug bounty programme (FTC complaint). |
| 21 November 2017 | Uber discloses the breach publicly, more than a year after discovery. |
| April 2018 | The FTC announces an expanded settlement covering the 2016 breach. |
| 26 September 2018 | Uber agrees a $148 million settlement with the 50 states and the District of Columbia. |
| October 2018 | The FTC gives final approval to the expanded settlement. |
Root cause
The FTC's revised complaint sets out the chain of events (FTC complaint):
- A credential in code. The access key for Uber's Amazon S3 datastore was in plain text in code posted to a private GitHub repository.
- Weak access to the repository. Engineers reached Uber's repositories through individual GitHub accounts, generally tied to personal email addresses. Uber had no policy against credential reuse and did not require multi-factor authentication for GitHub. The intruders said they got in with passwords exposed in other large breaches.
- Unencrypted data at rest. Nearly all the exposed data was collected before July 2015 and stored in unencrypted database backup files.
- Concealment. The breach happened while the FTC was already investigating Uber's data security, including the security of the same datastore, and Uber did not tell the Commission until November 2017.
The complaint also describes an earlier 2014 breach through the same pattern: an access key an engineer had posted publicly on GitHub, in May 2014. The 2016 breach repeated it.
Impact and regulatory outcome
- People affected: 57 million Uber users around the world, with about 600,000 US drivers' licence numbers, by Uber's account. For the US, the FTC counts about 25.6 million names and email addresses, 22.1 million names and mobile numbers and 607,000 names and driver's licence numbers.
- FTC: the expanded settlement requires Uber to submit all of its third-party audit reports to the FTC, not only the first, report future incidents, and keep records of bug bounty reports about unauthorised access; it received final approval in October 2018.
- States: a $148 million settlement with all 50 states and the District of Columbia, announced on 26 September 2018, over the failure to notify affected people promptly.
Uber's chief executive said in November 2017 that the company had failed to notify affected individuals or regulators, and that two people who led the response were no longer with the company.
The controls that address it
| Control | SOC 2 criteria | ISO 27001:2022 Annex A |
|---|---|---|
| No secrets in source code; secret scanning before and after commit | CC6.1, CC8.1 | A.5.17, A.8.4, A.8.28 |
| Multi-factor authentication for source code hosting | CC6.1 | A.8.5 |
| Short-lived, rotated and scoped cloud credentials | CC6.1, CC6.3 | A.5.17, A.5.18 |
| Encryption of personal data at rest, including backups | CC6.1, CC6.7 | A.8.24, A.8.13 |
| Incident response with defined notification duties | CC7.4, CC7.5, CC2.3 | A.5.24, A.5.26, A.6.8 |
| Legal and regulatory requirements identified, including breach notification | CC2.3 | A.5.31 |
SOC 2 references are the 2017 Trust Services Criteria (points of focus revised 2022); Annex A references are ISO/IEC 27001:2022. These are the usual mappings: agree yours with your auditor.
How TryTrustable checks these controls
- Secrets in repositories: the GitHub integration checks that secret scanning is enabled, and the SDK's secret scan runs in CI and in the pre-push hook, so a key can be caught before it reaches the remote (code security scanning).
- MFA on the code host: a GitHub check that two-factor authentication is required for every member of the organisation.
- Cloud credentials: AWS access key age and root access keys; GCP user-managed service-account keys and Secret Manager rotation.
- Encryption at rest: AWS RDS storage encryption; Cloud SQL encrypted connections on GCP.
- Incident handling: the incident management module records detection, triage and containment times, affected systems, regulatory deadlines and the post-mortem, and the free breach notification deadline calculator works out the clocks for India and the GDPR.
These are the checks TryTrustable runs today. None of them is a claim about what would have happened in this incident: they test whether the control is in place in your environment, continuously, and record the result as audit evidence.
Sources
- FTC: Uber agrees to expanded settlement with FTC related to privacy, security claims (April 2018)
- FTC: In the Matter of Uber Technologies, Inc., revised complaint
- FTC: Federal Trade Commission gives final approval to settlement with Uber (October 2018)
- New York Attorney General: record $148 million settlement with Uber over 2016 data breach (26 September 2018)
- Uber: 2016 data security incident, statement of 21 November 2017
Every figure on this page is taken from the official documents listed here, read in October 2026. Regulatory findings quoted are the regulator's; where a company neither admitted nor denied them, or where proceedings are still open, the page says so. Not legal advice.
More case studies: all breach case studies · Research
The things people ask us
How did the 2016 Uber breach happen?
According to the FTC, intruders accessed Uber's private GitHub repositories, which did not require multi-factor authentication, found an Amazon S3 access key in plain text and used it to download 16 files of rider and driver data.
How many people were affected by the Uber breach?
Uber said 57 million users around the world, including about 600,000 US drivers whose licence numbers were accessed.
Why was Uber penalised for disclosure?
Uber paid the attackers $100,000 through its bug bounty programme and did not tell consumers or the FTC for about a year, while an FTC investigation into the same datastore was open. The states' $148 million settlement concerned the failure to notify promptly.
What controls stop credentials leaking through code?
Secret scanning in the repository and before each push, multi-factor authentication for the code host, and short-lived, rotated cloud credentials so a leaked key expires quickly.
Check these controls in your own environment.
We connect GitHub and one cloud account in a demo and show which of these checks pass, with the evidence an auditor would ask for.