Originally reported by The Hill. Original event date: August 2019.
Overview
Capital One and GitHub were named in a class-action lawsuit following a major data breach that exposed the personal information of more than 100 million Capital One customers across the United States and Canada. The breach is one of the largest financial-sector security incidents on record and drew immediate legal, regulatory, and congressional scrutiny.
What Happened: The Breach
The breach stemmed from a firewall misconfiguration in an Amazon Web Services (AWS) cloud storage environment used by Capital One. An attacker exploited that misconfiguration to gain unauthorized access to customer records.
The exposed data included:
- Credit card applications for millions of customers in the U.S. and Canada
- Approximately 140,000 Social Security numbers
- Approximately 80,000 bank account numbers
- Additional personal identifying information for tens of millions of individuals
According to the legal complaint, the unauthorized access occurred in March 2019. The stolen data was subsequently posted on GitHub in April 2019, where it reportedly remained visible for nearly three months before action was taken.
The Alleged Perpetrator
Paige Thompson, a Seattle-based software engineer and former Amazon employee, was arrested in connection with the breach. Prosecutors alleged that Thompson exploited the cloud misconfiguration, accessed the data, and discussed her actions on GitHub. Another GitHub user who encountered the post notified Capital One, which then alerted the FBI.
The Class-Action Lawsuit
Law firm Tycko & Zavareei LLP filed the class-action complaint on behalf of individuals affected by the breach, naming both Capital One and GitHub as defendants. The complaint centered on two core allegations of negligence:
Allegations Against GitHub
The complaint alleged that GitHub failed to monitor its platform for obviously stolen or improperly disclosed data. Specifically, it argued that GitHub did not recognize or act upon the presence of hacked customer data that had been posted publicly on GitHub.com. According to the filing:
“As a result of GitHub’s failure to monitor, remove, or otherwise recognize and act upon obviously-hacked data that was displayed, disclosed, and used on or by GitHub and its website, the Personal Information sat on GitHub.com for nearly three months.”
— Tycko & Zavareei LLP complaint
Allegations Against Capital One
The firm further alleged that Capital One’s own computer logs showed the company “knew or should have known” about the breach at the time it occurred in March 2019, yet did not take meaningful action until months later. The delayed response formed a central pillar of the negligence claim against the financial institution.
Regulatory and Congressional Response
The lawsuit was not the only institutional response to the breach. Several parallel investigations and inquiries were launched in its wake:
- New York Attorney General: Letitia James announced that her office was opening a formal investigation into the breach.
- Connecticut lawsuit: A separate lawsuit was filed by a Connecticut resident on behalf of all those affected, adding further legal pressure on the companies.
- House Oversight and Reform Committee: Republican leaders of the committee demanded answers from both Capital One and Amazon about the breach and the underlying cloud security failures.
- Senate Banking Committee: The committee was expected to examine the incident following Congress’s return from the August 2019 recess.
Key Security Lessons for DevOps Teams
The Capital One breach became a widely referenced case study in cloud security failures. For DevOps and platform engineering teams, several practical takeaways stand out:
- Firewall and IAM configuration reviews are critical: Misconfigured security groups, IAM roles, or metadata service access (a likely factor in this incident) can expose cloud storage to unauthorized access. Regular automated auditing is essential.
- Assume breach posture: Organizations should implement detection capabilities that alert on anomalous data access patterns, not just on perimeter intrusions.
- Secrets and sensitive data must never be committed to public repositories: This incident highlights the risk of sensitive data appearing on code hosting platforms. Tooling such as secret scanning and pre-commit hooks can help prevent accidental exposure.
- Platform responsibility is increasingly litigated: The inclusion of GitHub as a defendant signals that courts may scrutinize whether code hosting platforms bear responsibility for monitoring and removing clearly stolen data posted by users.
- Incident response timelines matter legally: The allegation that Capital One’s logs showed awareness of the breach months before public disclosure underscores that delayed response can itself become a legal liability.
Context and Background
The Capital One breach occurred during a period of heightened scrutiny around cloud security practices. AWS environments, when misconfigured, can expose storage buckets, metadata endpoints, and internal credentials to external actors. The Server Side Request Forgery (SSRF) technique—commonly cited in connection with this type of attack—allows an attacker to leverage a misconfigured application to query internal cloud metadata services and retrieve temporary credentials.
While the specific technical vector in the Capital One case was confirmed by federal prosecutors, the full technical details of the exploit were subject to ongoing legal proceedings at the time of the original reporting.
This article is based on reporting from The Hill published in August 2019. Legal outcomes of the referenced lawsuit are not covered here and should be independently verified.