TeamCity Kotlin DSL Sandbox Escape Lets a User Run Code on the Build Host

Vulnerability overview

TeamCity ships a Kotlin DSL that lets teams define build configuration as code. A vulnerability in that integration, CVE-2026-106218, allows a user to escape the sandbox that is supposed to contain DSL execution and run code directly on the TeamCity server. JetBrains rates the issue 8.8 on CVSS v3 and files it under CWE-184, an incomplete list of disallowed inputs. Fixed releases are available.

Mechanism and exploitation conditions

The Kotlin DSL feature exists to give developers a programmable build definition without granting them the host. The sandbox is the boundary that keeps the two apart. The escape turns that boundary into a suggestion. Because the underlying problem is an incomplete input restriction, the practical requirement is a user who can already submit or modify Kotlin DSL content. That is an ordinary permission on many installations. The attacker does not need administrative rights on TeamCity to reach the flaw, only the ability to get malicious DSL content evaluated.
The type of attacker matters here. Many organizations assume their build server is safe because only employees can log in. In a CI/CD system the relevant question is which internal identities have the right to push DSL changes, including service accounts, contractors, and any automation that syncs configuration from a repository.

Impact

Code execution on the TeamCity host is the worst outcome in a build environment. That host typically stores version control credentials, artifact repository tokens, deployment keys, and sometimes code signing material. An attacker who reaches it can modify builds so that every artifact the pipeline produces carries a backdoor, which pushes the compromise downstream to customers. The damage also outlives the incident, because injected artifacts may already be distributed before anyone notices.

Affected products and scope

TeamCity releases before 2026.1.3 and before 2025.11.7 are affected by the Kotlin DSL sandbox escape. Both version lines need attention, since organizations on a long-term branch can remain vulnerable while believing they are current.

Exposure context

JetBrains has not published installation counts. A ZoomEye query for app="JetBrains TeamCity" returned 1,866 matching assets on 2026-10-10, which shows the product is widely reachable on the public internet. Internet reachability is not required for this flaw, because the trigger is an authenticated action inside the product, but it widens the pool of servers that a stolen credential could be used against.

Remediation and mitigations

Upgrade to TeamCity 2026.1.3 or 2025.11.7 on the relevant branch. Until that is done, reduce the set of identities that can author or approve Kotlin DSL configuration, and review recent DSL changes for anything unexpected. Run build agents on separate hosts from the server, restrict outbound network access from the server, and keep repository credentials scoped to the projects that need them. If you cannot rule out prior abuse, rotate the credentials the server holds and compare built artifacts against a known good source.

References

• JetBrains security advisory for CVE-2026-106218
• SecurityOnline: JetBrains software vulnerabilities impact TeamCity