A data breach at South Korea's government-backed startup support platform, Modu-ui Changup, has surfaced an important lesson in data security: encryption alone doesn't guarantee protection if the keys used to unlock that encryption aren't secured just as carefully.
What the Platform Does, and What Went Wrong
Operated under the oversight of South Korea's Ministry of SMEs and Startups (MSS), the platform supports a nationwide startup audition programme and stores sensitive participant information, including names, email addresses, and summaries of startup ideas. Authorities later determined that the encryption key used to decrypt this protected information had itself been exposed through an application programming interface (API), effectively handing attackers both the locked data and the key to unlock it.
How the Breach Was Discovered
The incident surfaced after concerns were raised about how the platform was handling applicants' personal information. In response, the Ministry of SMEs and Startups confirmed that personal information and startup idea summaries had leaked, and launched a joint investigation with South Korea's National Intelligence Service, Cyber Security Center, and National Police Agency.
On July 31, authorities confirmed the decisive cause: the encryption key itself had been exposed through the platform's API. According to the ministry, the key was embedded within API data, and an external party allegedly gathered the exposed information using techniques like web crawling, obtaining both the protected data and the means to decrypt it in one go.
Investigators also found that information not visible through the platform's public-facing interface, including email addresses applicants had specifically marked as private, could still be retrieved through API responses that weren't properly locked down.
Roughly 5,000 Applicants Affected
The exposed data reportedly included email addresses, evaluation comments, and startup idea summaries belonging to around 5,000 successful applicants. Authorities identified 39 IP addresses that accessed the leaked information, all originating within South Korea, and the investigation is continuing, including examining possible links to AI solution providers.
The breach also raised broader questions about a common but risky practice: storing encryption keys as fixed values directly within application code, configuration files, databases, or other systems connected to the encrypted information itself. When a key sits right alongside the data it's meant to protect, compromising the application or API can expose both at once.
Why Key Management Matters as Much as Encryption Itself
This incident illustrates a point security experts have long emphasised: encryption converts sensitive data into a protected form, but anyone holding the corresponding key can still decrypt it. A properly designed security architecture needs to keep encryption keys genuinely separate from the databases and applications storing the encrypted information, not bundled together where a single breach exposes both.
The recommended approach is storing keys in dedicated Key Management Systems (KMS), with applications requesting temporary access to a key only when actively processing protected information, rather than holding permanent copies. A compromised key can also open the door to risks beyond just data exposure, depending on system design, attackers might use stolen credentials or keys to impersonate legitimate users or move further into an organisation's broader infrastructure.
Fixing This Isn't as Simple as Swapping the Key
One of the harder lessons here: simply revoking the exposed key and generating a new one often isn't enough. Organisations typically also need to re-encrypt existing data that was protected by the compromised key, and dig through key-access logs to determine exactly what was accessed and when. On top of that, security teams generally need to reassess permissions across APIs, servers, and internal storage systems, notify affected individuals, and put continuous monitoring in place to catch any further unauthorised activity. In practice, a single compromised key can force an organisation into a genuinely extensive security review, and sometimes a redesign of parts of its security architecture altogether.
A Higher Bar for Government-Linked Platforms
This case carries particular weight because the affected platform was tied to a government-backed startup programme, holding information related to real business ideas and applicants. It's a clear reminder that public institutions and enterprises need to treat encryption and key management as two distinct, but tightly interconnected, security controls. Protecting an encrypted database while leaving the key itself poorly secured still leaves the underlying data genuinely vulnerable.
The incident also underscores something increasingly relevant for any organisation running APIs: data hidden from a website's visible interface can still be exposed through an improperly configured API endpoint. For organisations handling sensitive personal, financial, or intellectual-property data, secure key storage, strict API access controls, detailed logging, regular security testing, and rapid key-rotation procedures are becoming essential components of any serious data-protection strategy, not optional extras.
FAQs
Q1. What caused the data breach at South Korea's Modu-ui Changup platform?
The encryption key used to decrypt protected participant data was itself exposed through the platform's API, allowing an external party to access both the encrypted data and the means to decrypt it.
Q2. How many people were affected by this breach?
Around 5,000 successful applicants had their email addresses, evaluation comments, and startup idea summaries exposed.
Q3. Why is storing encryption keys separately from data so important?
If a key is stored alongside the data it protects, compromising the application or API can expose both the encrypted information and the key needed to decrypt it, defeating the purpose of encryption entirely.
Q4. Is simply replacing a compromised encryption key enough to fix the problem?
No. Organisations typically also need to re-encrypt affected data, review key-access logs, reassess permissions across systems, notify affected individuals, and introduce ongoing monitoring for further unauthorised activity.