In 2016 attackers accessed data on around 57 million Uber riders and drivers after finding credentials in a private code repository. Uber paid the attackers to stay quiet and did not disclose the breach for over a year. It is a lesson in both credential exposure in code and the cost of covering up a breach.

The 2016 Uber data breach is a useful case study because the initial security failure was relatively straightforward. Attackers obtained credentials that gave them access to a private source code repository. From there, they found an access key that allowed them to reach data stored in Uber’s cloud environment.

The incident ultimately exposed information associated with approximately 57 million Uber users and drivers, including information relating to about 600,000 driver’s license numbers. Uber discovered the intrusion in November 2016 but did not publicly disclose it until November 2017.

The technical intrusion was serious. The subsequent response made the incident significantly more damaging.

Uber paid the attackers $100,000 through a third party and treated the payment as part of its bug bounty process. The company then failed to disclose the breach to regulators and affected users for more than a year. The US Department of Justice later described the concealment as part of a criminal investigation, while the Federal Trade Commission pursued enforcement action concerning Uber’s security and privacy practices.

What Happened and When

The 2016 attack occurred in October and November 2016.

According to the US Department of Justice, the attackers used stolen credentials to access a private source code repository. They obtained a private access key from that repository and used the key to access and copy Uber data. The stolen information included records associated with approximately 57 million users and drivers, including approximately 600,000 driver’s license numbers.

Uber learned about the breach on November 14, 2016, after the attackers contacted the company and demanded payment in exchange for deleting the stolen information. The attackers provided evidence that they had obtained Uber’s data.

Uber paid $100,000 in Bitcoin through a third party associated with its bug bounty programme. The DOJ later confirmed that the payment was made to the attackers after they had stolen the information.

The breach was not disclosed publicly until November 2017, more than a year after the company discovered it. Uber’s new management investigated the incident and disclosed it to affected users, regulators, law enforcement and other authorities.

That timeline is central to understanding the incident.

The initial compromise was a security failure. The decision to conceal the breach created a separate legal and regulatory problem.

The Entry Point: Credentials Found in a Private Code Repository

The attack did not begin with an exotic vulnerability.

The attackers first obtained credentials that allowed access to a private source code repository. They then found a private access key in that repository. That key gave them access to Uber’s cloud environment and ultimately to sensitive user and driver information.

The FTC’s investigation provided additional detail about how Uber’s security controls contributed to the incident.

Uber allowed engineers to access company GitHub repositories through individual accounts that were generally connected to personal email addresses. At the time, Uber did not prohibit credential reuse and did not require multi-factor authentication for access to its GitHub repositories. The attackers told Uber they had used passwords exposed in other major data breaches to gain access.

This created a chain of weaknesses.

An exposed password gave attackers access to a private repository.

The repository contained an access key.

The access key provided access to cloud resources.

Those resources contained sensitive customer and driver information.

The important lesson is that credentials do not have to provide direct access to customer data to become dangerous.

They only need to provide access to the next system in the chain.

Why Secrets in Code Are a Recurring Cause of Breaches

Source code repositories are designed to store and manage software. They are not intended to function as password vaults.

Yet developers can sometimes place passwords, API keys, access tokens or other secrets in source code because applications need those values to communicate with other systems.

Once committed to a repository, a secret can become difficult to remove completely. Version control systems maintain history, meaning deleting the value from the latest version does not necessarily mean it has disappeared from every historical copy.

The Uber case demonstrates why this matters.

The FTC reported that an Uber engineer had posted an access key to GitHub. In the 2016 incident, that key was located in a private repository. Attackers who gained access to the repository were therefore able to find the key and use it against Uber’s cloud environment.

A private repository is not automatically a secure repository.

Access controls, authentication requirements, credential management and secret scanning all matter.

A secret sitting behind a login is still a secret that can be stolen if the account protecting it is compromised.

The Connection Between Credential Exposure and Source Code

The Uber breach also demonstrates why credential monitoring and source code security should not be treated as separate problems.

The attackers reportedly used credentials that had been exposed in other data breaches to access employee accounts. Those accounts then provided a path into the private repository.

This creates an important relationship between historical breaches and current attacks.

A password stolen in an unrelated incident can become the starting point for an attack against another organisation if an employee reused that password.

The original breach may have happened years earlier.

The attacker only needs the credential to remain valid.

This is one reason employee credential monitoring can form part of an organisation’s broader security controls.

If an employee credential appears in a known criminal dataset, the organisation has an opportunity to reset the password before an attacker tests it.

That does not replace MFA, secure coding or access controls.

It provides another opportunity to break the attack chain.

The Cover-Up and Why It Made Things Worse

Uber’s response became one of the defining aspects of the incident.

After discovering the breach, Uber paid the attackers $100,000 and treated the payment as part of its bug bounty process. The attackers had maliciously accessed and downloaded personal information, rather than responsibly reporting a vulnerability.

Uber then failed to disclose the incident to the Federal Trade Commission despite an ongoing FTC investigation into its data security practices.

The DOJ stated that the breach was not reported to the FTC until approximately a year later, when new executive leadership investigated the incident and disclosed it.

The FTC subsequently reached a settlement with Uber concerning its privacy and data security practices. The regulator stated that Uber had failed to monitor employee access to consumer information adequately and had not reasonably secured sensitive consumer data stored in the cloud.

The consequences extended beyond regulatory action.

In 2022, Uber entered a non-prosecution agreement with federal prosecutors relating to the investigation into the breach’s concealment. Uber accepted responsibility for the actions of its officers, directors, employees and agents in concealing the incident from the FTC.

The former Uber Chief Security Officer, Joseph Sullivan, was later convicted of federal charges related to the cover-up. The DOJ said Sullivan had taken steps to conceal the breach and prevent information about it from reaching the FTC.

The security lesson is straightforward.

A breach requires containment, investigation and notification decisions.

Trying to make the incident disappear creates additional risk.

How Exposed Credentials and Repositories Are Found and Abused

The Uber incident illustrates a common attack pattern.

Attackers first need a valid path into an organisation.

That path might be an employee credential, an exposed API key, a cloud token or another secret.

Once inside a development environment, attackers can search for additional credentials and configuration information. Those secrets can provide access to other systems.

In Uber’s case, the attackers used stolen credentials to reach the private repository and then obtained a cloud access key from it. That key became the bridge to the company’s stored data.

The broader security problem is that organisations have many places where credentials can appear.

They can exist in source code, configuration files, developer notes, build systems, logs, cloud environments and third-party services.

They can also appear outside the organisation after a breach.

Criminals trade exposed credentials and stolen information through different environments, including Tor, Telegram and I2P, as well as forums and marketplaces. No single source provides complete visibility into every criminal community or dataset.

This makes external monitoring useful as a complement to internal controls.

The Lesson: Keep Secrets Out of Code and Disclose Breaches Properly

The Uber incident offers several practical lessons for security teams.

Keep Secrets Out of Source Code

Passwords, API keys and access tokens should not be embedded directly into application code.

Use appropriate secrets-management systems and ensure that credentials cannot be retrieved simply by gaining access to a source repository.

Protect Developer Accounts

Developer accounts can provide access to highly sensitive systems.

Organisations should require MFA, enforce strong authentication, prohibit password reuse and apply appropriate access controls to development environments.

Rotate Exposed Credentials

If a secret is committed to a repository, removing it from the latest version is not enough.

The credential should be considered exposed and rotated.

Teams should also review repository history and determine whether the credential was accessed or used.

Monitor Employee Credentials

If employee credentials appear in breach datasets or criminal intelligence, security teams need to know quickly.

DarkThreatX monitors 100B+ records and 1M+ new stealer logs per week, with monitoring operating 24/7, alerts in under five minutes, and zero false positives.

Relevant criminal intelligence can appear across Tor, Telegram and I2P, alongside forums and marketplaces. Monitoring does not provide full visibility into every source, but it can identify exposures that warrant investigation.

Respond Transparently

Once a breach has been identified, organisations need a clear incident response process.

Legal, security, privacy and executive teams should understand their respective responsibilities.

The Uber case demonstrates why disclosure cannot be treated as an afterthought.

Why the Uber Breach Still Matters

The Uber breach remains relevant because the attack chain is still familiar.

A credential is exposed.

An attacker obtains access.

A repository contains another secret.

That secret provides access to a cloud environment.

Sensitive data is copied.

The attacker then demands payment.

None of these steps requires a highly complex exploit.

The weakness comes from the connection between systems and credentials.

An organisation can have strong security controls around its customer database and still be exposed if an attacker can obtain a valid credential that leads to the environment containing that database.

This is why security teams need visibility beyond their own perimeter.

Enterprise dark web monitoring can help organisations identify exposed credentials and other information appearing in criminal intelligence.

The earlier an organisation identifies an exposed credential, the more opportunity it has to reset the account, revoke sessions, rotate secrets and investigate associated activity.

Conclusion

The 2016 Uber data breach exposed information associated with approximately 57 million users and drivers. Attackers used stolen credentials to access a private source code repository and then obtained an access key that allowed them to reach Uber’s cloud data.

The incident shows why secrets in code remain dangerous, why developer accounts require strong authentication, and why exposed credentials can become an entry point into much larger systems.

It also demonstrates the consequences of poor breach response.

Uber discovered the incident in November 2016 but did not disclose it for more than a year. The resulting regulatory and criminal investigations extended well beyond the original intrusion.

The practical response is clear.

Keep secrets out of code. Protect development accounts with MFA. Rotate exposed credentials. Monitor for credentials that have already escaped the organisation. And when a serious breach occurs, follow the appropriate disclosure and incident response process.

The initial mistake may be technical.

The response determines how much worse it becomes.

Frequently Asked Questions

How did the 2016 Uber breach happen?

Attackers used stolen credentials to access a private Uber source code repository. They then found a private access key in the repository and used it to access Uber’s cloud environment, where they copied data associated with approximately 57 million users and drivers.

How many people were affected?

The breach involved records associated with approximately 57 million Uber users and drivers, including approximately 600,000 driver’s license numbers. The stolen information also included names, email addresses and phone numbers.

Why was the Uber breach controversial?

Uber paid the attackers $100,000 after learning about the breach and did not disclose the incident to the FTC or affected users for more than a year. The DOJ later investigated the concealment, and Uber entered a non-prosecution agreement related to the matter.

What is the lesson from the Uber breach?

Organisations should keep passwords and access keys out of source code, protect developer accounts with MFA, rotate exposed credentials, and monitor for compromised employee credentials. A breach also requires an appropriate response and disclosure process. Concealing an incident can create additional legal, regulatory and operational consequences.