29CM Customer Data Exposure: What Happened Through the Order Lookup API

Incident Overview

South Korean fashion and lifestyle platform 29CM disclosed that abnormal external access to an integration used to retrieve order information exposed customer data. The company said it detected the activity on August 27, 2026, blocked the affected access path, and reported the incident to the Korea Internet & Security Agency (KISA) and the Personal Information Protection Commission (PIPC). The confirmed total is 159,852 records.

The scope is best understood through the fields 29CM identified rather than by treating this as a compromise of every customer account. The company said payment information, account IDs, and passwords were not among the exposed fields. The incident instead centers on the order-information lookup API and the customer attributes returned through that integration.

Confirmed Timeline

According to 29CM, the key event was abnormal external access to an order-information lookup integration on August 27. The company blocked the relevant access route, notified KISA and PIPC, and sent affected customers individualized information about the fields involved and steps to reduce follow-on risk. A self-service lookup on the official notice page is available for 30 days from the posting date.

Customers should begin with the official 29CM app or by typing the company’s website address directly. A message that mentions a real order can still be deceptive, so the safest sequence is to locate the company notice independently, complete the official identity check, and use the resulting field list as the basis for any response.

Two Exposure Groups

The disclosed population falls into two groups. The first consists of 138,841 records containing names. The second consists of 21,011 records containing names together with email addresses, mobile phone numbers, and shipping information. Combined, those groups total 159,852 records. Because the fields differ by customer, another person’s notice is not a reliable guide to an individual’s own exposure.

The second group requires particular caution around order-related messages. A combination of contact and shipping data can make a fraudulent delivery, refund, or payment-error message appear more credible. The correct response is not to infer that every such message is malicious, but to verify it through an independently opened official channel before clicking, calling, installing anything, or entering information.

Why the Order API Matters

An API lets websites, apps, customer-service tools, and fulfillment systems exchange data in a defined way. In online retail, order status and shipping workflows often depend on these connections. The confirmed link in this case is the order-information lookup integration and abnormal external access to it. That makes request authorization, access volume, response-field minimization, anomaly detection, and durable query logs the relevant defensive review areas.

The disclosed facts do not justify assigning a specific exploit technique. A useful defensive review can stay within the confirmed structure: determine which identities and systems may call the order endpoint, verify that every lookup is authorized for the requested order, detect unusually broad or sequential queries, and ensure each response includes only the data required for that workflow.

Company Response and Customer Notice

29CM said it blocked the affected path, reported the event to the relevant Korean authorities, and contacted impacted customers individually. Its official notice provides a route for customers to authenticate and see the fields associated with their record. That lookup remains available for 30 days from the notice date.

The company specifically warned about texts, calls, and emails that cite an order while claiming a payment, refund, or delivery problem. It also stated that 29CM does not request a password or verification code by text or email. A customer who receives such a request should stop the interaction and re-check the matter through the official app, website, or customer-service path.

Customer Response Sequence

1. Open the official 29CM notice independently and complete its identity check to review the fields tied to your record.
2. Verify any order-related text, call, or email through the official app or website rather than using the link or phone number in the message.
3. Refuse requests for passwords, one-time codes, or app approvals.
4. Change passwords that were reused on other services, using each service’s official app or website.
5. If an active building entry code was stored in delivery notes, change it through the normal building-management or access-system process and keep future notes minimal.

How to Judge Follow-On Messages

Knowing a name, phone number, email address, or shipping detail does not prove that a caller or sender represents 29CM or a delivery company. The stronger test is whether the same issue appears when the customer independently opens the official service. Urgent prompts about address errors, refunds, canceled payments, or extra delivery fees should be paused while the customer checks the order inside the official app.

If card details were entered or money was transferred during a suspicious interaction, the customer should contact the card issuer or financial institution immediately to stop use and review transactions. That step is separate from the 29CM account itself and addresses the financial action that occurred during the follow-on contact.

Defensive Review for Retail Platforms

Organizations that run shopping or delivery services can use this incident to review every externally reachable order API and the identities allowed to call it. Customer, seller, logistics-partner, and internal support permissions should be separated. Monitoring should distinguish ordinary order lookups from bursts, enumeration patterns, and requests that cross account or tenant boundaries.

Responses should carry only the fields required for the active workflow, and expired tokens or partner permissions should be removed. After blocking one path, teams should check whether similar requests move to other accounts, API keys, network ranges, or user agents. The customer-notification population should also reconcile with query logs so the disclosed scope matches the evidence used in the investigation.

What the Incident Means

The central facts are specific: abnormal access affected an order-information lookup integration; 138,841 name records and 21,011 records containing names, emails, phone numbers, and shipping information were exposed; and 29CM responded by blocking the path, reporting the incident, notifying customers, and opening a 30-day lookup.

For customers, the practical starting point is equally specific: confirm the exposed fields through the official notice, independently verify order-related messages, reject credential and verification-code requests, update reused passwords, and replace any still-valid building entry information that was left in delivery notes.