The API returned the key with the data
Penta Security found the encryption key sitting in the same API response as the encrypted data. The response shape was { encrypted_data: '...', encryption_key: 'abc123...' } — the key and the ciphertext travel together in one JSON object.
This is a textbook case of encryption key mismanagement. There is no cryptographic separation between the key and the data it protects. An attacker who gets one gets both, which means the encryption is effectively a no-op.
What was exposed
The exposed data consists of personal identifying information submitted by startup founders and business owners when they applied for government support programs through the platform. The platform is government-backed and serves as the submission layer for South Korea's startup support programs, meaning the data was not just stored but actively transmitted to the government as part of the application flow.
Penta Security confirmed the data includes the standard set of fields for these programs: name, email, phone, and the program-specific identifiers. The data was submitted directly to the platform's API endpoint, which is where the encryption key mismanagement occurred — the same endpoint that returned the key alongside the ciphertext.
Why the key should never have been there
The fix is straightforward: the key belongs in an HSM or a dedicated key vault, not in the API response. The endpoint should return { encrypted_data: '...' } and keep the key server-side, where it never travels with the ciphertext. Instead, the platform returned both in one JSON object, so every client that gets the data also gets the key that decrypts it.
That is the same as taping the combination to the outside of the safe. The data is encrypted, but the key is right there in the response, so the encryption is effectively a no-op for anyone who can read the JSON.
Key points
- The platform's API response returned both encrypted_data and encryption_key in the same JSON body, so the key and ciphertext travel together.
- Penta Security's analysis shows the key was included directly in the API response, meaning an attacker with the response can decrypt the data immediately.
- The exposed data includes personal identifying information submitted by startup founders and business owners for government support programs.
- The fix is to keep the key in an HSM or KMS and never return it in the same response as the ciphertext.
- The platform is government-backed, raising PIPA exposure and potential sanctions for the affected users.