Uber's Hidden Breach (Disclosed Nov 2017): AWS Keys in a Private GitHub Repo

Retrospective: this article looks back at events from November 2017, written in 2026 with the benefit of hindsight.

In November 2017, Uber disclosed that a year earlier attackers had stolen personal data on about 57 million riders and drivers, including the driver's license numbers of around 600,000 drivers. The disclosure was as damaging as the breach: Uber had paid the attackers $100,000 and concealed the incident for a year.

How it happened

The attackers accessed a private GitHub repository used by Uber engineers. Inside the code they found AWS access keys. Those keys gave access to an Amazon S3 bucket containing an archive of rider and driver data.

The cover-up

Instead of notifying regulators and affected people, Uber's security team treated the payment as a bug bounty and had the attackers sign non-disclosure agreements. When new leadership discovered it, the company disclosed the breach and dismissed its chief security officer. He was later convicted in US federal court of obstruction and concealing a felony — a landmark case for security executives.

Lessons for AWS teams

• Never store access keys in code, even in private repositories. Repositories get shared, cloned and breached.
• Prefer short-lived credentials. IAM roles, IAM Identity Center and OIDC federation for CI/CD remove long-lived keys entirely.
• Scan for secrets. Secret scanning in GitHub and in CI pipelines catches keys before they are pushed.
• Limit what each key can reach. A developer key should not unlock production data archives.
• Disclose honestly and on time. Concealment turns an incident into a legal crisis.

In hindsight

Leaked keys in code repositories remain one of the most common cloud breach paths nearly a decade later. The tooling to prevent it is now free and built into most platforms; the remaining gap is adoption.