High priorityDisclosed

Advisory · CVE-2026-65906

TeamCity Kotlin DSL escape breaks out of the sandbox

A sandbox escape in TeamCity's Kotlin DSL handling allows code execution on the server, fixed in TeamCity 2025.11.6 and 2026.1.2.

Vendor
JetBrains
Product
TeamCity
Identifier / CWE
CVE-2026-65906
CWE-94
Action timing
Immediate
ELI5

Explain it like I’m five

TeamCity lets developers describe their build setup in a fenced-off playground so the descriptions cannot touch the real machinery. This bug is a tunnel under the fence that leads straight into the server room.

SIMPLIFIED_ATTACK_PATH04 STEPS
  1. 01Attacker edits project settings

    A user with permission to modify a project's Kotlin DSL settings supplies crafted DSL content.

  2. 02Sandbox boundary crossed

    The Kotlin DSL sandbox escape allows the crafted content to break out of its restricted execution context.

  3. 03Code runs on server

    Arbitrary code executes on the TeamCity server.

  4. 04Build pipeline at risk

    Server compromise can be leveraged against build configurations, artifacts, and connected agents.

What happened

JetBrains disclosed CVE-2026-65906: in TeamCity before 2026.1.2 and 2025.11.6, code execution via a Kotlin DSL sandbox escape was possible (CWE-94). Kotlin DSL lets project settings be defined as code; the sandbox that is supposed to confine that code could be escaped, allowing execution on the TeamCity server. JetBrains’ own CVSS 3.1 assessment is 8.8 (requiring low privileges), while a secondary assessment rates it 10.0. Fixed versions are 2025.11.6 and 2026.1.2. The flaw was reported by Antoni Tremblay, and there are no known public exploits at the time of writing.

What to do

  1. Upgrade TeamCity to 2025.11.6 or 2026.1.2 or later, matching your release line.
  2. Audit recent changes to project settings, Kotlin DSL scripts, and Git VCS roots for unexpected modifications.
  3. Review which users and service accounts can edit project configurations, and apply least privilege; this flaw requires an attacker with project-level access.
  4. Check build agent activity and server logs around the disclosure window for signs of unexpected code execution.

Management note

Build servers are high-value targets because they sit upstream of everything you ship, which makes even a privileged-user code execution bug worth prompt attention. The saving grace here is that exploitation requires project configuration access, not anonymous network access, so the priority is patching plus a permissions review rather than an emergency.