South Korea's Financial Supervisory Service has opened examinations at two electronic payment gateway (PG) firms, Coem Payments and Toss Payments, after evidence surfaced that an attacker widely described in Korean media as a Chinese national obtained credit card and payment record data. Korean outlets including Asia Business Daily (S1/S3), Digital Times (S5) and Bizwatch (S8) report the FSS began checks on 7 September and escalated them to a formal on-site examination on 9 September. Volume estimates vary sharply by source and by victim: Asia Business Daily reports "tens of thousands" of card records spanning nearly every domestic card issuer at a rate of several thousand per issuer, while Toss Payments has publicly quantified its own incident at 4,131 payment records affecting 2,671 individuals. The FSS itself has told reporters only that "the gap in the number of cases between the two firms is large" and that it cannot confirm scale while the examination is live. No source in this set is a regulator filing or CERT advisory; everything below is press reporting plus company statements quoted within it.
What Happened
The sequence that Korean reporting agrees on is unusual. Asia Business Daily (S1/S3) reports that a hacker who identified himself as Chinese contacted the Financial Services Commission, the FSS, the Ministry of Science and ICT and the Korea Internet & Security Agency directly, naming the organisations he had hit and handing over samples of the data he had taken. According to that reporting, neither the regulators nor at least some of the affected companies were aware of any compromise before the tip arrived. An FSS official quoted by Bizwatch confirmed the notification channel plainly: "The tip came in by email." The FSS is now cross-referencing the data the hacker supplied against live PG and card issuer customer records to determine which of it is genuine.
DailySecu (S4) reports that the same actor did not use any of the bug bounty or coordinated disclosure channels available to him, and treats both the choice of regulator-first notification and the deliberate emphasis on Chinese nationality as anomalous for a financially motivated intruder. That outlet also reports that a breach investigation review committee was scheduled for 11 September.
Reporting also indicates the target set extended past finance. Asia Business Daily says the victims named by the tipper included small and mid-sized businesses alongside the payment firms, which is what has driven the "weak link" framing across Korean coverage.
What Was Taken
The two incidents need to be read separately, because the data exposure is not comparable.
Coem Payments is the more serious of the two on current reporting. Per its own website notice as summarised by Digital Times (S5) and Bizwatch (S8), the intrusion window ran from 08:13 on 30 August to 05:34 on 1 September, and the company only became aware of it on the morning of 2 September. Because of the structure of its payment request messages, Coem has said it is possible that card numbers and expiration dates were taken, and that for certain payment methods the date of birth and the first two digits of the card PIN were also in scope. Critically, Coem states it does not itself retain the individual transaction records and card data the attacker obtained, so it cannot currently identify which customers were affected and is working with authorities to establish the real scope. Treat the Coem figures as unbounded rather than small.
Toss Payments disputes the characterisation entirely. Per NOCUTNEWS (S7) and Bizwatch (S8), the company puts the affected scope at 4,131 payment records covering 2,671 data subjects, all belonging to a single merchant. It says the exposed fields were receipt-level: buyer name, partially masked card number, authorization number, and per DailySecu also payment timestamp, purchased item and amount. Toss states that card PINs, expiration dates and CVCs were not included, that no fraudulent transactions have been identified, and flatly that "it is not true that customer information was leaked due to hacking."
The aggregate "tens of thousands of records including passwords" figure that leads most English-language coverage traces to Asia Business Daily's exclusive and is echoed by B2Bdaily (S6) and BigGo (S2). It has not been confirmed by the FSS on the record.
Where the Accounts Diverge
Accounts genuinely differ, and defenders should not average them.
On volume: Asia Business Daily reports tens of thousands of records across nearly all Korean card issuers. DailySecu reports the Toss-linked case at "several thousand" and, in follow-up reporting, states that the large PG's internal systems were not directly breached at all. Toss's own number is 4,131. Coem's number does not exist yet.
On attribution: Asia Business Daily and B2Bdaily present the Chinese attribution as established. Digital Times quotes an FSS official taking a materially more cautious line, saying that source IP tracing does point to Chinese infrastructure but that "IP relay techniques are so varied and advanced that it is difficult to state this definitively at this stage." Bizwatch goes further, reporting that claims of a Chinese hacker or overseas group remain unverified. The cautious regulator framing should carry more weight than the headline framing.
On the generative AI angle: Asia Business Daily raises the possibility that the attacker used generative AI, and B2Bdaily builds an entire thesis on insufficient AI guardrails enabling mid-tier operators. This is speculation raised within the financial sector, not a finding. There is no forensic evidence in any source that AI tooling was used.
The Attack Technique
For the Toss Payments case the mechanism is comparatively clear and, if accurate, is the more instructive half of this incident. DailySecu (S4) and NOCUTNEWS (S7) both report that a single merchant exposed the payment integration key issued to it by a payment integration platform provider. A third party picked up that key and used it to call the PG's API over the normal integration path, retrieving that merchant's payment history. Toss says log analysis found no intrusion attempt and no vulnerability exploitation against its own systems, and that other merchants and Toss group services were unaffected. From the platform's perspective the requests looked substantially like legitimate merchant traffic, which is exactly why detection failed until the attacker himself raised his hand.
For the Coem Payments case, the company describes abnormal external access to a specific payment integration system during a roughly 21-hour window. The precise entry vector has not been published, and the FSS examination is explicitly looking at intrusion path as well as at whether card data was stored and managed appropriately, which puts information protection architecture and internal controls squarely in scope.
DailySecu's structural read is worth repeating: directly attacking a tier-one PG is hard because those firms run large security teams, monitoring, access control and red teams. Harvesting an API key, token or credential from a merchant or a second-tier integrator and then walking in through a sanctioned path is cheaper and quieter. That is the pattern here.
Why It Matters
This is a payment supply chain failure, not a perimeter failure, and it lands on a stack that Korean e-commerce depends on. Three points matter for defenders outside Korea.
First, the credential was the perimeter. A merchant-issued integration key gave a third party a legitimate-looking read path into transaction data at a well-defended provider. Any organisation issuing long-lived API keys to thousands of downstream merchants has the same exposure profile, and the blast radius is defined by whatever those keys are scoped to see.
Second, partial secrets are still secrets. If Coem's assessment holds and the first two digits of card PINs were exposed alongside card numbers and expiration dates, the remaining keyspace for that factor collapses to a hundred combinations, which is trivially brute-forceable against any endpoint that does not rate-limit hard. B2Bdaily makes this point aggressively; it follows directly from the data types Coem itself listed. Korean authorities and card issuers have responded by running Fraud Detection System monitoring at elevated intensity against overseas fraudulent-payment scenarios.
Third, detection was zero. The regulators found out because the attacker told them. Whatever monitoring existed did not flag an authenticated-looking bulk query pattern, and in Coem's case the company noticed roughly a day after the window closed. That gap, not the record count, is the finding.
What Organizations Should Do
- Inventory every integration key you have issued and every one you hold. Treat merchant-side or partner-side API keys as credentials with the same lifecycle requirements as employee secrets: expiry, rotation, revocation on demand, and an owner. Any key that has never rotated is a live finding.
- Scope keys to the minimum data they need and enforce it server-side. A merchant integration key should not be able to enumerate that merchant's full payment history in bulk. Cap per-key query volume, restrict result fields, and require additional authorisation for historical retrieval.
- Alert on behaviour, not just authentication. The Toss traffic was authenticated and structurally valid. Baseline normal per-merchant API call volume and query patterns, and alert on deviations such as sudden bulk historical reads, off-hours access, or new source geographies for an established key.
- Scan for exposed keys in merchant-controlled surfaces. Public repositories, client-side JavaScript, mobile app bundles and misconfigured storage are where integration keys leak. If you issue keys, run the scanning on your customers' behalf rather than assuming they will.
- Reduce what transits and what is retained. Coem cannot identify its own affected customers because it does not hold the data the attacker took. Minimise sensitive fields in payment request messages, tokenise aggressively, and ensure logging is sufficient to reconstruct scope after an incident without retaining the sensitive values themselves.
- Assume partial PIN or partial secret exposure is exploitable. Rate-limit and lock out on repeated failures against any endpoint validating a short secondary factor, and feed suspected-exposure card ranges into fraud monitoring immediately rather than waiting for confirmed leak counts.
Sources: Exclusive Even Passwords Compromised by Chinese Hacker... Tens of T... | Tens of Thousands of Card Records Leaked at Two South Korean Paymen... | 단독中 해커에 비밀번호까지 털렸다…수만 건 카드정보 유출에 금감원, PG사 2곳 현장심사 | 단독 해커는 왜 버그바운티 대신 기관 제보 택했나…대형 PG 사고 둘러싼 의문과 팩트 체크 내용 < 긴급속보 < 이슈 <... | “카드 비밀번호 노출 우려”…금감원, 코엠·토스페이 PG사 검사 착수 디지털타임스 | South Korean Payment Gateways Hit by Major Data Breach B2Bdaily.com | FSS launches inspection into Toss Payments over 'merchant payment i... | PG사 해킹에 카드정보 '비상'…토스페이먼츠는 "해킹 아닌 인증정보 노출"