Uber (2016): Hardcoded Credentials in a Private Repository
Summary
In late 2016, attackers accessed a private GitHub repository used by Uber engineers and found hardcoded AWS credentials inside the code. Those credentials were used to access an AWS S3 environment containing personal data of approximately 57 million Uber riders and drivers, including roughly 600,000 U.S. driver's license numbers. The breach was not disclosed publicly until November 2017, after it emerged that Uber had paid the attackers $100,000 through its bug bounty program and had them sign non-disclosure agreements, rather than reporting the incident as a breach. This later resulted in regulatory penalties and a criminal case against Uber's former Chief Security Officer.
Technical Root Cause
The proximate technical cause maps to CWE-798 (Use of Hard-coded Credentials): long-lived AWS access keys were committed directly into application source code stored in a repository, rather than being managed through a secrets manager or short-lived credential mechanism. Repository access alone was sufficient to obtain cloud infrastructure credentials with broad data access.
Why It Mattered
Beyond the technical failure, this incident is widely cited for the response failure: rather than disclosing the breach and notifying affected individuals and regulators as required, Uber treated the incident as a bug bounty payout and had the attackers sign confidentiality agreements, which converted a technical incident into a significant legal and regulatory liability once it came to light.
OWASP / CWE Mapping
- CWE-798: Use of Hard-coded Credentials
- OWASP A02:2021: Cryptographic Failures (in the broader sense of secrets exposure)
Lasting Impact
The Uber case is a standard reference point for two separate lessons: the technical one (secrets scanning and short-lived credentials over hardcoded long-lived keys) and the governance one (breach response and disclosure obligations cannot be substituted with an informal payoff).
How Safeguard Helps
Secrets and credential scanning across source repositories is a standard SCA capability aimed directly at catching hardcoded credentials like this before they reach production, or flagging them for rotation if already committed.
