The 2019 Capital One Breach: A Cloud Misconfiguration at Scale

In July 2019, the US bank Capital One announced that an outsider had accessed data belonging to around 100 million people in the United States and about 6 million in Canada. The attack did not involve a stolen password or malware on a laptop. It involved a mistake in the configuration of a cloud setup, and it became a standard teaching example of how small settings can matter enormously.

What was taken

Capital One said the information came from credit card applications dating from 2005 to early 2019. It included names, addresses, phone numbers, dates of birth and self-reported income. Smaller amounts of more sensitive data were involved: about 140,000 US Social Security numbers, roughly one million Canadian Social Insurance numbers and about 80,000 linked bank account numbers. The bank said that credit card numbers and login credentials were not compromised.

How the attack worked

According to the US Department of Justice's complaint and later reporting, the intruder was Paige Thompson, a software engineer who had previously worked at Amazon Web Services. The technical steps, as described, were:

1. Capital One ran a web application firewall on a cloud server, and it had been configured in a way that could be tricked into making requests on the attacker's behalf. This kind of flaw is known as server-side request forgery, or SSRF.
2. The attacker used it to ask the server for its own credentials from the cloud provider's metadata service, an internal address that hands out temporary access keys to software running on the instance.
3. Those credentials belonged to a role with far broader permissions than a firewall needs, including the ability to list and read data in many storage buckets.
4. The attacker used them to copy data from the storage buckets.

The cloud provider's infrastructure was not hacked in a general sense. As both companies pointed out, the problem lay in how the customer had set up its own environment.

How it came to light

Capital One was alerted by a person who saw information about the data posted on GitHub and sent an email to the bank's responsible disclosure address. The bank investigated, fixed the vulnerability and contacted the FBI, and Thompson was arrested on 29 July 2019, the day the breach was announced. She was later convicted in June 2022 on several federal counts, including wire fraud and computer intrusion offences.

The penalty

In August 2020 the US Office of the Comptroller of the Currency fined Capital One 80 million dollars for failing to establish effective risk management when moving its information technology operations to the cloud. In 2021 the bank agreed to pay 190 million dollars to settle a class action brought by customers. The company said that it expected the costs of the incident, including customer notification and credit monitoring, to be substantial.

Least privilege in practice

The principle behind the main lesson is called least privilege: every account, role and program should have only the permissions it needs to do its job. A firewall does not need to read every storage bucket. If the role had been limited, the stolen credentials would have been far less useful. Cloud providers reacted too. Amazon introduced a more secure version of its metadata service that is much harder to abuse through SSRF.

Checks any site owner can run

• Review the users and roles on your hosting, domain, payment and email accounts, and remove any you do not need.
• Check that backups, database dumps and private files are not reachable from the web.
• Give your website's database user only the rights it needs.
• Use separate credentials for separate purposes instead of one master key.
• Set up alerts for unusual access or large downloads.

Misconfiguration is the common cause

The Capital One case is often grouped with a long list of incidents where the cloud itself worked as designed and the customer's settings were the issue: storage buckets left open to the internet, access keys committed to public code repositories, test databases without passwords. These are less dramatic than malware, and also far more frequent. Cloud platforms make it easy to create powerful resources in minutes, and just as easy to leave a setting at a dangerous default.

The same applies on ordinary hosting. A staging site left online without a password, a database backup stored in the web root, an exposed admin folder or a forgotten test installation each count as misconfiguration. Automated scanners look for these constantly, because they are cheap to find. A routine check of your own site from the outside, as a stranger would see it, will reveal many of them.

The practical lesson for site owners

Convenience tempts people to give everything broad access, and then a single weak point opens everything. Take an hour to tighten permissions: separate accounts for different people, limited rights on databases and no shared root logins. On a self-managed server, that also means restricting which services can reach each other.

A VPS gives you the control to configure users and permissions properly, and our security page and knowledge base help you apply them.