A South Korean startup portal left its own encryption key inside the API, and attackers walked in
Encrypted user data isn't protected if the key to unlock it ships alongside the data. A government-backed platform in South Korea just learned that the hard way.
Key points
- A South Korean government-backed startup platform suffered a breach that exposed personal data, even though the data was stored encrypted.
- The encryption key was included inside the platform's API, letting whoever accessed the API also decode the data it was meant to protect.
- Security vendor Penta Security, which analysed the incident, says keys must be stored separately from the data they encrypt.
- The failure is a key management problem, not a cryptography problem: the maths worked, the operational hygiene didn't.
- Incidents like this are one reason regulators increasingly ask for evidence of key separation and rotation, not just "we encrypt everything".
A government-backed startup support platform in South Korea has leaked personal data belonging to its users, and the twist is almost embarrassing. Encrypted records sat next to the key that scrambled them, bundled into the same API.
An API, short for application programming interface, is the doorway that lets one piece of software talk to another. Mobile apps use APIs to fetch your account details from a server. Whoever reached this one could pick up both the data and the key, which meant the encryption did essentially nothing.
The breach was first reported by BleepingComputer, citing analysis by South Korean security firm Penta Security. This is the third key-management incident we've covered since 11 August, when we found a Firefox signing key had briefly landed on GitHub.
What actually went wrong?
The platform encrypted user records but shipped the decryption key inside the same API that served those records. Anyone who could call the API could also unscramble the output. Encryption without separated key management is theatre.
Think of it like locking your front door and taping the key to the door. The lock's real. The protection isn't.
In sound design, the key lives somewhere the application must request, under strict conditions: a hardware security module, a cloud key management service, or at minimum a secrets vault with access logging. Application code and the API it exposes should never contain the raw key. This is where the distinction between authentication (proving who is calling) and authorisation (deciding what they're allowed to read) matters most: key material should sit behind both.
Who is affected?
Users of the platform, which supports early-stage South Korean startups, had personal details exposed. Exact figures for how many people were caught up in the leak haven't been published in the available material.
If you registered on a Korean government startup support portal recently, treat your contact details and any submitted business information as compromised. Watch for targeted phishing: fake emails that impersonate the platform or a government body and ask you to verify your account. Don't click login links in those messages. Type the address yourself.
MFA wouldn't have prevented this specific breach, because the attackers didn't need to log in as anyone. They read data straight out of the API. Being honest about that matters; MFA is essential, but it isn't a cure for careless key handling.
Why does this keep happening?
Because "we encrypt at rest" reads well on a compliance checklist, and nobody audits where the key actually lives. Developers ship keys in config files and environment variables because it's faster than wiring up a proper key store. The Paperclip AI platform we covered on 5 August had a similar failure mode: unprotected API routes leaking control-plane data.
Regulators are starting to notice. Frameworks focused on cryptographic controls increasingly expect organisations to demonstrate key separation, rotation, and access logging, not just the presence of a cipher somewhere in the stack. That expectation isn't new. The shortcuts just remain very tempting.
What should other platforms take from this?
Audit where your keys live before your regulator does. If a developer can search the repository and find a production key, so can an attacker who gets read access to the code, the build system, or, as here, the API itself.
Encryption's a control, not a blessing. It only works when the key is somewhere the attacker can't reach.
