A Brief Analysis of the TVING and "Modu-ui Changeop" Personal Data Breaches

TL;DR

In June 2026, personal data breaches occurred back to back at TVING and at "Modu-ui Changeop" (a government startup-support program). The two incidents have different causes. For TVING, poor credential management and weak cloud access control are the central issues in an external intrusion. For Modu-ui Changeop, direct access to the database itself has not been confirmed to date; instead, private data was obtained through a backend API with inadequate authorization (the Korea Institute of Startup and Entrepreneurship Development's breach report is reported to describe abnormal API calls and crawling by a participating AI-solution vendor as the means of data acquisition). What the two share is this: they trusted something that should not have been trusted, and there was no point in the server/infrastructure layer where access was actually verified.

This article is based on news reports, breach-report filings, and government/company announcements. Both incidents are still under investigation, so the final intrusion paths will be confirmed by the investigation results.

1. TVING: Credential Exposure and Detection Failure

According to the breach report, at 6:01 p.m. on May 30 an anomaly was recorded in which the database server's CPU usage reached 100%. TVING recognized the breach at 3:09 p.m. on May 31 and, on June 2, confirmed a personal-data leak caused by unauthorized access. The scale of the leak grew from the government's initial estimate of about 13 million people to roughly 19.53 million, and the leaked items included Connecting Information (CI) and Duplication Information (DI), which are difficult to change.

According to the breach report submitted to KISA, this was not a simple database leak; there was evidence that the attacker accessed the internal system or data and directly executed queries. TVING's actions immediately after the incident hint at the cause: it revoked the AWS access key used in the attack, removed and rotated credentials that had been hardcoded in GitHub, and changed its cloud access-control policy. This suggests that, at a minimum, there were problems in how the code repository and cloud credentials were managed. Depending on the scope of permissions granted to that key, it could lead to access to major systems such as servers, storage, and databases. That said, whether this credential was the actual intrusion path, and whether the attacker gained control of the system in advance via GitHub, is not yet confirmed and remains circumstantial; the final path will be determined by the investigation.

On top of this, two response failures overlapped. From the point when the abnormal data queries/commands occurred until they were recognized, about 21 hours passed, and the KISA report was filed after 23 hours and 59 minutes—just one minute short of the mandatory 24-hour deadline. TVING was also criticized for keeping values like CI and DI—hard to change and susceptible to misuse for cross-service identification—in its operational database, where they were leaked along with everything else.

2. Modu-ui Changeop: Inadequate Server-API Authorization

For this incident, direct access to the database itself has not been confirmed to date; it is explained as abnormal access exploiting inadequate authorization in a backend API. It was reported that the breach report submitted by the Korea Institute of Startup and Entrepreneurship Development to the Personal Information Protection Commission describes abnormal API calls and crawling by a participating AI-solution vendor as the means of data acquisition. On June 15, the profiles of 5,000 first-round finalists were made public (these are the people covered by the breach notification). Emails, if set to private, were not shown on screen—but the authorization on some backend APIs (challenger profiles, review comments) was inadequate, so a specific call would return the values as-is.

[Screen]              [Server API response]
Email: (private)  ←→  "email": "gildong@example.com"  ← returned as-is

According to the breach report and news coverage, the vendor is described as having used AI tools and web crawling to call the system as if it were a properly authorized user, and it sent promotional email to the email addresses it obtained before being caught. During the investigation, evidence of abnormal API calls from 9 IPs was also confirmed. The leaked personal information is the email address, and along with it, private (non-personal-information) content such as idea summaries and review comments was also found to have been exposed externally (the Ministry of SMEs and Startups assessed that direct database access was not confirmed and that resident registration numbers, contact numbers, and detailed applications were not leaked). The Ministry and the National Intelligence Service also view it as a case where a user without permission called the system as if authorized and took the information. That said, the Ministry's position is that, with the investigation ongoing, it is difficult to conclusively name a specific vendor as the source of the leak, and the vendor claims it used only publicly available information. Meanwhile, the Ministry did acknowledge that there was, in the end, a problem with the server API. In OWASP API-security terms, the fact that an email field hidden on screen was nonetheless included in the API response makes this closer to a Broken Object Property Level Authorization (BOPLA) case (if access were gained by manipulating an object ID, it would also fall under BOLA). Security experts assessed it not as a sophisticated attack but as a basic, preventable vulnerability.

Also, one month before the incident, on May 7, the security team "Zento" reported a similar type of vulnerability—personal data exposed through API responses—together with a reproduction path and improvement recommendations; it was not fundamentally resolved, and a similar type of incident followed.

For reference, there was also a suspicion that "the platform was built with a generative-AI coding tool (vibe coding), which made it insecure," but the Ministry stated that "according to confirmation with the developer, that method was not used (though the investigation results should be seen)." In other words, vibe coding has not, to date, been confirmed as a cause of this incident, and the claim that the platform became insecure because it was AI-developed has not been confirmed.

3. What Actually Went Wrong?

The causes differ, but the underlying problems come down to three.

Failure to set trust boundaries — TVING trusted whoever held the credentials; Modu-ui Changeop trusted a partner vendor and the screen-level hiding of data. Neither can be a basis for trust.
Absence of an enforced verification point — For TVING, it has been raised that credential/cloud-permission management issues may have led to internal system access, and anomaly detection was also late; for Modu-ui Changeop, the requester's permission was not verified before responding.
Ignored warnings and excessive retention — TVING kept hard-to-change CI/DI in its operational database, where they were leaked as well; Modu-ui Changeop saw a vulnerability reported a month earlier go unresolved at a fundamental level, leading to a similar incident.

4. Where Should It Have Been Stopped?

TVING should not hardcode secrets in source code but use a dedicated secret-management tool, and it needs regular credential rotation with immediate invalidation upon exposure, least-privilege IAM, and real-time detection of abnormal queries.

Modu-ui Changeop should filter fields at the server-response layer according to the requester's permissions rather than on screen, treat all API callers—including partner vendors—as untrusted, and apply detection of abnormal API calls/crawling along with rate limiting. Reported vulnerabilities should be closed out with a fundamental fix, not a temporary block.

There is one principle common to both incidents: hiding something on screen is not security, and authorization must be enforced on the server.

5. Closing Thoughts

The causes differ, but in both incidents, trusting a particular party or the screen-level handling of data—and not verifying access permissions at the server layer—is what led to the leak. For reference, according to a report released by the Personal Information Protection Commission and KISA in May 2026, personal-data breach reports in 2025 totaled 447, a 45.6% increase over the prior year (307), with fines of 157.7 billion KRW across 40 cases and the overall scale of fines/penalties up 172% year over year. In addition, under the amendment to the Personal Information Protection Act promulgated on March 10, 2026, starting September 11 a fine of up to 10% of total revenue may be imposed in cases such as repeated violations through intent or gross negligence, or causing large-scale harm to 10 million or more people through intent or gross negligence. (That said, the amended law applies to incidents occurring after it takes effect.)

What stands out about these two cases is that neither was a particularly sophisticated or novel attack. And this is less a problem unique to specific companies than a set of points anyone can miss while operating a service. Precisely because things like secret management and server-side permission checks feel familiar and obvious, they tend to slip down the priority list.

So I think security is less about defending against difficult, complex attacks and more about steadily checking these basics. Rather than treating it as someone else's problem, it would be good if we all took care to check whether our own services—the ones we build and operate—have gaps like these.