CVE-2026-106218 in TeamCity
Summary
by MITRE • 10/06/2026
In JetBrains TeamCity before 2026.1.3 2025.11.7 kotlin DSL sandbox escape leading to RCE on the server was possible
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/06/2026
The vulnerability identified in JetBrains TeamCity prior to version 2026.1.3 and build 2025.11.7 represents a critical security failure within the platform's Kotlin Domain Specific Language (DSL) sandboxing mechanism. This flaw allows an authenticated user with sufficient permissions to configure builds using custom scripts written in Kotlin DSL, which are executed by TeamCity’s internal agent or server components. The core technical issue lies in the insufficient isolation of the execution environment for these scripted build steps. While JetBrains implements a security manager and classloader restrictions intended to prevent arbitrary code execution outside of approved APIs, attackers were able to bypass these controls through specific manipulation of reflection capabilities or by exploiting gaps in the whitelist of allowed classes and methods. This sandbox escape effectively neutralizes the protective boundary designed to contain potentially malicious script behavior within a restricted context.
From an operational perspective, this vulnerability leads directly to Remote Code Execution (RCE) on the TeamCity server itself. Because build scripts often run with elevated privileges necessary for compiling code, accessing repositories, and deploying artifacts, successful exploitation grants the attacker full control over the underlying operating system of the affected machine. This level of access enables a wide range of malicious activities including data exfiltration from connected version control systems such as Git or SVN servers, theft of stored credentials and secrets managed by TeamCity’s secret storage mechanism, installation of persistent backdoors for long-term access, and lateral movement within the internal network to compromise other critical infrastructure. The impact is severe because it compromises not only the CI/CD pipeline integrity but also potentially exposes sensitive intellectual property and authentication tokens used across multiple development projects hosted on the platform.
This vulnerability aligns with Common Weakness Enumeration (CWE) category CWE-94, which describes Improper Control of Generation of Code or Script, specifically in contexts where user input influences code generation without adequate validation or sandboxing. Furthermore, it maps to MITRE ATT&CK technique T1059 Command and Scripting Interpreter, as the attacker utilizes scripting capabilities inherent to the platform for execution, and potentially T1203 Exploitation for Client Execution if the attack vector involves triggering a build via web interface interactions that lead to server-side processing. The failure here is not merely in code injection but in the architectural assumption that DSL scripts are inherently safe due to language constraints, ignoring the reality that dynamic languages like Kotlin can often circumvent static analysis protections through runtime reflection and class loading mechanisms if not strictly locked down.
Mitigation strategies must prioritize immediate patching of all TeamCity instances to version 2026.1.3 or later build 2025.11.7, where JetBrains has addressed the sandbox escape vector by tightening restrictions on reflective operations and limiting accessible system classes within the DSL execution context. In environments where upgrading is not immediately feasible, administrators should enforce strict least-privilege principles for user accounts that have permission to create or modify build configurations involving custom scripts. It is advisable to disable Kotlin DSL support entirely if it is not actively required by development workflows, thereby removing the attack surface associated with script interpretation. Additionally, network segmentation should be reviewed to ensure that TeamCity servers are isolated from sensitive data stores and critical production systems, limiting the blast radius in case of a successful compromise. Regular auditing of build configurations for suspicious or overly complex scripts can also serve as an early warning mechanism for potential exploitation attempts targeting this class of vulnerabilities.