Overview

Amazon Web Services (AWS) Singapore confirmed that all servers containing Malindo Air customer data were secured “with no further vulnerabilities” following a data breach that exposed the personal information of approximately 21 million passengers. The breach also affected customers of Malindo Air’s sister company, Lion Air, both members of the Lion Group.

Crucially, AWS stated that no payment details were leaked and that its own infrastructure was never compromised. The incident instead traced back to a misconfigured AWS S3 data bucket — a configuration error on the customer side, not a flaw in AWS’s underlying platform.

How the Breach Came to Light

The incident was first surfaced when Kaspersky Lab alerted its cloud users in Thailand, advising them to exercise caution with incoming emails, text messages, and phone calls. The cybersecurity vendor reported that personal data belonging to passengers of Malindo Air and Lion Air had been posted in online forums and listed for sale on the dark web.

According to Check Point Software Technologies, the personal data exposed in the breach included:

• Date of birth
• Passport numbers
• Mobile phone numbers

The reported root cause was an unsecured (publicly accessible) AWS S3 bucket containing passenger data.

AWS’s Position: Infrastructure Worked as Designed

An AWS spokesperson issued the following statement to ZDNet:

“While we can’t get into details regarding a customer issue, it is important to clarify that AWS services and infrastructure worked as designed and were not compromised in any way. Neither the use of cloud services nor the geographic location of the data had any bearing on the issue.”

When pressed on why the data bucket was unsecured if its infrastructure “worked as designed”, AWS declined to comment further, citing its policy of not discussing specific customer issues. AWS also declined to confirm the geographic location of the servers involved, or to detail how the security issue was remedied.

This response reflects the AWS Shared Responsibility Model: AWS is responsible for securing the infrastructure that runs cloud services, while customers are responsible for securing the data and configurations within those services — including S3 bucket access policies.

Malindo Air’s Response

Malindo Air issued a public statement confirming that forensic and data consultants had been appointed to assess the overall data security infrastructure, with a focus on passenger data protection across all platforms. The airline also stated that:

• Financial institutions, the police, and other relevant authorities had been notified.
• The airline does not store customer payment details on its servers and was compliant with the Payment Card Industry Data Security Standard (PCI DSS).
• Adequate measures compliant with Malaysia’s Personal Data Protection Act (PDPA) had been in place.
• Members of the Malindo Air frequent flyer programme were advised to change their passwords, especially if those passwords were reused across other online services.
• Customers were warned to be alert for suspicious or unsolicited calls and emails requesting personal data verification.

The investigation was being conducted jointly by AWS and Malindo Air’s e-commerce vendor, GoQuo.

Expert Commentary: S3 Misconfiguration Is a Persistent Risk

Michael Petit, Asia-Pacific Head of Cloud Security at Check Point Software Technologies, highlighted the wider systemic problem exposed by this incident:

“Data stored in cloud services like AWS S3 buckets are only as secure as their security configuration settings. Cloud services are convenient, but require proper configuration for the best security possible within the confines of such technologies. Companies may have hundreds, thousands or even millions of S3 buckets or similar cloud data storage on other competing platforms. With such complexity of data storage in the cloud, it is imperative for companies to persistently audit and correct misconfigurations, as cloud services may also change their settings occasionally. This is a necessarily laborious and time-consuming process for companies.”

Key Lessons for DevOps and Cloud Engineers

The Malindo Air breach is a textbook example of the risks that come with misconfigured cloud storage. For teams managing data on AWS or any cloud platform, this incident reinforces several operational imperatives:

• Understand the Shared Responsibility Model: Cloud providers secure the underlying infrastructure. You are responsible for configuring access controls, encryption, and permissions on the resources you provision.
• Audit S3 bucket permissions regularly: Use AWS tools such as S3 Block Public Access settings, AWS Config rules, and AWS Trusted Advisor to detect publicly exposed buckets before attackers do.
• Enable S3 server-side encryption and access logging: Encryption at rest and detailed access logs add both a protective and a forensic layer to your data storage.
• Apply least-privilege IAM policies: Restrict bucket access to only the roles and services that genuinely require it. Avoid wildcard permissions.
• Implement automated misconfiguration detection: Tools such as AWS Security Hub, AWS Macie (for sensitive data discovery), and third-party cloud security posture management (CSPM) platforms can continuously scan for configuration drift.
• Have an incident response plan: Malindo Air’s response involved forensic consultants, regulatory notifications, and customer communications. These steps should be planned before a breach occurs, not improvised during one.

Background: The S3 Misconfiguration Problem

Exposed S3 buckets have been the cause of numerous high-profile data breaches across industries. By default, AWS S3 buckets are private, but they can be made publicly accessible through misconfiguration — either via bucket policies, access control lists (ACLs), or by explicitly disabling block public access controls. In complex environments with many buckets across multiple accounts and teams, maintaining consistent access controls requires deliberate, ongoing governance.

AWS has progressively strengthened its default configurations and added tooling to help prevent accidental public exposure. However, the responsibility for applying and auditing those controls remains with the customer.

Summary

The Malindo Air breach was not caused by a vulnerability in AWS’s platform — it was caused by a misconfigured data bucket that left sensitive passenger data publicly accessible. AWS’s infrastructure functioned as intended. The failure was in how customer-controlled access settings were managed.

For any organisation storing sensitive data in the cloud, this incident is a clear reminder that cloud adoption does not automatically confer security. Security must be deliberately engineered, continuously audited, and owned by the teams operating the infrastructure.

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.