Original reporting by ZDNet. This article summarises the incident based on public statements from AWS, Malindo Air, and security vendors.
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.