Products Lemma APIProof issuance & verification platformTrust402Delegate to agents, and transactSealSign-in for the agent era — no keys handed over
Use cases Manufacturing & Critical InfraInspection Record AssuranceFinance & FinTechCounterparty Record VerificationPublic SectorCertificate-less ProceduresHealthcareQualified Worker AssuranceProcurement & Supply ChainSupplier Credential MonitoringMedia & ContentContent AuthenticityService & RetailCross-group IdentityAI Adoption (cross-industry)AI Run GovernanceDevelopers & Agent OpsAgent Authority Control ▸ Browse the use-case index
Pricing
Resources Critical BriefThe frontier of AI × trustBlogThinking and implementation notesDocumentationAPI & specsVerification CenterReal verification & issuance countsAbout usFRAME00, Inc.ContactSales & press inquiriesGlossaryDefinitionsFAQFrequently asked questions
Get Started ↗ JA
Home / Critical Brief / No. 155
No. 155 Critical Brief · Agent Authority Proof

TVING: Development projects taken with a developer key held production keys, and user data leaked (Korean government investigation)

Nothing checks each key use against whose work it is for

39.5Maccounts
TVING accounts whose data the investigators confirmed leaked (including dormant, deleted and test accounts, and duplicates of the same person). The Personal Information Protection Commission will confirm the detailed scale
43keys
Production access keys inside the 361 development projects taken (in source code and settings). Two of them were used in the attack
05-29→05-31
From entry into the development environment to the bulk exfiltration of user data
CountrySouth Korea
Incident date2026-05-29
Published2026-10-23
AuthorsLemma Critical Team
Contents
  1. 01TL;DR
  2. 02What happened
  3. 03Timeline — disclosure and response
  4. 04Why it wasn’t stopped
  5. 05How to counter this
  6. 06Sources

TL;DR

  1. 01What happened

    On September 3, 2026, South Korea’s Ministry of Science and ICT (MSIT) published its investigation into the breach of the streaming service TVING. An attacker used a developer’s access key to enter the development environment and took all 361 development projects. Inside them, in source code and settings, were 43 keys to the production environment. With two of them, the attacker entered production, obtained the database ID and password, and exfiltrated user data from 39.5 million accounts (including duplicates).

  2. 02Why detection didn't stop it

    TVING stopped the first exfiltration attempt after an alert when database CPU hit 100%. The next day, the attacker created a virtual server in the cloud with a different key and exfiltrated through it. CPU stayed under 10%, and no alert fired.

  3. 03The missing layer

    Load monitoring stopped the first attempt. What was missing was a layer that checks, at each use of a production key, whose work it is being used for.

What happened

  • The company: TVING, a South Korean video streaming service.
  • The investigation: MSIT began on-site work with KISA on June 2 and formed a joint public-private team on June 3. It ran forensics on nine developer devices to learn how the key was stolen, and traced the path through logs from security equipment, databases and systems, splitting it into five stages (per MSIT).
  • Source code taken: 361 development projects (30.35 GB), including recommendation and search, user management and authentication, and payments. The development environment was entered twice: 14 projects were taken the first time and all 361 the second. Two development keys were used (per MSIT).
  • User data taken: 39.5 million accounts (22.06M active, 17.37M dormant or deleted, 0.11M test; including one person with up to 13 accounts). ID, one-way hashed password, name, phone, email, date of birth, Korea’s identity-verification identifier (CI) and more, 20 items in all. Phone numbers (last four digits) and emails (the part before the @) were partly encrypted, but the key leaked too, so investigators treated them as plaintext (per MSIT).
  • Not determined: How the first development key was stolen. Investigators examined phishing, malware, supply-chain attack, key sharing and vulnerabilities, and could not determine it (per MSIT).
  • Problems the investigators named (per MSIT):
    • Production keys were written directly into source code (41) or kept in plaintext settings (3, one duplicate).
    • Every developer had access to every development project, so even one key reached all of them.
    • There was no procedure for issuing, using, changing or retiring keys, and no policy to control access by unauthorized parties (they cited source-IP limits and MFA as examples).
    • Monitoring relied on simple signals such as CPU load, with nothing to watch and block network and data flows. With it, they judged, the mass leak would not have happened.
    • A 2024 penetration test had found keys written into source code, but it had not been fixed.

Glossary
TVING — A South Korean video streaming (OTT) service.
Development and production environments — The development environment stores source code for developers to work on together. The production environment is the cloud system that runs the service (AWS, per the findings). Both require an access key to enter.
Access key — A secret string used to enter a system. Like a password, whoever holds it can act with the owner's rights.
Virtual server — A server created and deleted on demand in the cloud. Anyone with the right to create one can also use it as a path for data.
Joint public-private investigation team — The team formed by South Korea's Ministry of Science and ICT (MSIT) with the Korea Internet & Security Agency (KISA) and others.

Exhibit 1The five stages the investigators set out

The stopping points are ③ and ⑤. Had each use of a production key been checked against whose work it was for, a key with no requested work behind it could not enter production or create a server. How ①'s key was stolen has not been determined.

Attacker
1
Enters the development environment with a developer's key

May 29. How the key was stolen is not determined.

Attacker
2
Takes all 361 projects and finds production keys

Even one key could reach them all (per investigators).

Attacker
3
Enters production and obtains the database ID and password

Kept in plaintext, investigators said.

Attacker
4
Tries a first exfiltration

May 30. Stopped after a CPU 100% alert.

Attacker
5
Creates a virtual server with another key and sends 24 GB out

May 31. No alert; the server was later deleted.

Timeline — disclosure and response

  • A penetration test finds access keys written into source code. Per the investigators, it was not fixed.
  • From 14:42, the development environment is entered with its access key. From 15:15, production (AWS) is entered too.
  • From 09:22, a first exfiltration is attempted. At 18:00, database CPU reaches 100% and an alert fires. TVING sees it and stops the job. Per the investigators, the dedicated security unit and the CISO were told about 14 hours after this anomaly.
  • At 10:10, suspicion that production keys were stolen and data leaked reaches the information security team. From 19:00 to 22:20, user data is sent out through a virtual server created with a different key. Investigators found CPU stayed under 10% and judged the attacker held it down to avoid the alert.
  • At 15:08, TVING reports to KISA. TVING reported becoming aware at 15:09 on May 31, but investigators set it at 10:10 and found the 24 hours the law allows had passed.
  • MSIT publishes the findings.

The facts rest on the joint team’s findings published by MSIT on September 3 (primary), including times and counts. The Personal Information Protection Commission says it will publish the detailed scale of personal data after its analysis. As of the findings, no harm to users or signs of sale on the dark web had been confirmed.

Response

  • TVING: Opened a damage-consultation line from June 3, and had a private security firm review the stolen source code for vulnerabilities (per MSIT).
  • MSIT: Plans a fine for the late report. It will have TVING submit a prevention plan in September and inspect the October–December implementation from January 2027, ordering corrections where needed.

Why it wasn’t stopped

This case was not only about a stolen key. The production keys let whoever held them through, and whose work each use was for was never asked.

The core of this case
The production keys let whoever held them through. Whose work each use was for was never asked.
Exhibit 2The detection–proof gap

Proof here means checking, before a production key performs a high-impact operation, "whose work, for which task, is this?", and recording it. Detection means noticing operations from symptoms such as load.

Proof layer · absentBefore use, check whose work it is
The gapAnother key
created a server
Detection layer · stopped the firstA CPU 100% alert halts the job
STEP 1
Key taken
STEP 2
Production entered
STEP 3
05-30 alert stops it
STEP 4
05-31 another key exfiltrates

Detection stopped the first attempt, but it watched only CPU load. “Holding a key” and “this person is using it for this work” are separate facts, and no layer checked the first against the second. That distance is the detection–proof gap, and it is a structural one.

The same structure appears in the Studio case (the keys to decrypt the data were read along with it).

How to counter this

Each time a production key performs a high-impact operation (creating servers, bulk-reading data), check whose work it is for. Then a key lifted from code cannot carry out operations with no requested work behind them. This is not a substitute for detection; it sits in front of it.

Industries and operations to watch

IndustryMedia & content
Video and music streaming services that hold member and payment data for years. The database here held data back to 2011, including dormant and deleted accounts.
IndustryDevelopers & agent operations
Organisations with many developers, where keys easily end up on laptops or in code. Apart from the 43 keys in the projects, investigators found 37 development keys and 52 production keys on eight developers’ devices.
OperationAccounts & permissions
The scope of rights given to developers and keys, and how keys are issued and retired.
OperationLookup & data access
Bulk database reads, and where their ID and password are kept.

Do today’s controls close it?

ControlThis caseWhy
Revoking leaked keysPartialKnown keys stop. But there were 43 keys in the projects, and the second attempt used a different key from the first.
CPU load monitoringPartialIt stopped the first attempt. The second stayed under 10% CPU and no alert fired.
Source restrictions and MFAPartialInvestigators said there was no access-control policy. These narrow the entry but don’t ask what an entry is used for.
Penetration testingPartialThe 2024 test found how keys were stored. Finding it is not the same as preventing use.
ControlsWhat is needed
  1. Keep keys out of code and tie them to an owner and assignment. Developer keys should reach only the projects they work on (least privilege, as the investigators said).
  2. Check each high-impact production operation against whose work it is before letting it through. Creating virtual servers or bulk-reading databases should not go through without a linked work request, even with a valid key, and allowed uses should be time-limited.
  3. Record key issuance and use separately from the user. Keep which key did what, for whose work, in a form that can be checked later: in other words, as proof.
CheckChecklist

Three things to confirm in your organisation about development and production keys

  • Are production keys or database passwords left in plaintext in source code or config files?
  • Can a single developer key reach every repository?
  • Besides load monitoring, can you notice bulk reads or new virtual servers?

Note: if a developer’s own device is taken over and the work request is forged too, this check can be passed. Investigators could not determine how the first development key was stolen. If follow-up reports reveal it, this Brief will be revised.

Sources

  1. Primary, government investigationMinistry of Science and ICT, MSIT Findings on the TVING breach2026-09-03, Korean · korea.kr/briefing/pressReleaseView.do

References: “The last layer left in AI-era cyber defense”

The same method elsewhereSee all 12 "Account takeover" cases Get new cases and checks like these by email

This material is a structured analysis of public information; it is not an audit, diagnosis, or recommendation for any specific organization.

Cite this Brief

Lemma Critical Team. (2026).
"TVING: Development projects taken with a developer key held production keys, and user data leaked (Korean government investigation) — Nothing checks each key use against whose work it is for".
Lemma Critical Brief No.155. Lemma / FRAME00, Inc.
https://lemma.frame00.com/critical/briefs/155-tving-developer-key-hardcoded-production-keys/
Lemma

If it can't be verified,
it doesn't enter your operation.

Lemma attaches cryptographic proofs to data and AI execution, so the receiving side can confirm authenticity without asking the issuer. Detection stays; a proof layer is added in front of it.

Talk to enterprise See the verification center