External risk intelligence

JetBrains TeamCity Kotlin DSL Sandbox Escape to RCE

CVE advisorySeverity: CRITICAL (CVSS 10.0)

CVE-2026-106218

JetBrains TeamCity is a continuous integration and deployment server frequently deployed as an internet-accessible web application to facilitate remote build management, integration with external services, and access by distributed development teams.

Jetbrains Teamcity

before 2025.11.72026.1.1 to before 2026.1.3

Halo Surface Signal: 4 out of 5 — likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

A security vulnerability has been identified in JetBrains TeamCity, a platform used for continuous integration and deployment. This issue could allow for unauthorized remote code execution on the server, potentially impacting operations that rely on this system. The main concern is to confirm whether our environment is affected by this vulnerability.

Unrestricted code execution on TeamCity servers.
Critical for environments using TeamCity for development.
Verify TeamCity relevance and exposure immediately.

Attack Path

How an attacker could exploit the issue

An attacker could exploit this vulnerability by sending specially crafted input to a TeamCity server exposed to the internet. This input would target the Kotlin DSL sandbox, allowing the attacker to escape its confines and execute arbitrary code on the server. This could lead to a complete compromise of the TeamCity server.

No authentication required for access.
Triggered by Kotlin DSL sandbox escape.
Results in remote code execution on server.

Live Threat

Current exploitation, exposure, and threat context

This vulnerability could allow an unauthenticated attacker to execute arbitrary code on the TeamCity server. When supported by the advisory's conditions, this could impact system data, user data, and sensitive information by enabling unauthorized access and control over the server and its operations.

Server code execution and data compromise.
Network-based exploitation without authentication.
Full server control and sensitive data theft.

Operational Fix

Recommended remediation, mitigation, and detection steps

Security teams and infrastructure owners are likely responsible for addressing this vulnerability in JetBrains TeamCity, as it allows for remote code execution. The first practical step is to determine the reachability and business criticality of all TeamCity instances, identify the accountable owner for each, and then prioritize remediation based on the potential impact.

Security and Infrastructure teams own remediation.
Verify TeamCity instance reachability and criticality.
Plan and coordinate updates based on risk.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is JetBrains TeamCity?

TeamCity is a software platform designed for continuous integration and continuous deployment (CI/CD). Developers use it to automate the building, testing, and deployment of their applications. By acting as a central hub for code pipelines, it bridges the gap between software development and release, allowing teams to manage complex build processes and integrate with various version control systems and cloud services.

What does Kotlin DSL sandbox escape mean for CVE-2026-106218?

This vulnerability involves a weakness in how TeamCity isolates code, classified as CWE-184. The Kotlin DSL acts as a secure container or 'sandbox' meant to limit what commands scripts can run. This flaw allows an attacker to break out of that restricted environment. By escaping the sandbox, the attacker can run unauthorized commands directly on the underlying server, bypassing the safety boundaries intended to keep build scripts from accessing the host operating system.

How is this TeamCity vulnerability triggered?

An attacker triggers this by sending specially crafted input to the TeamCity server. Because the flaw exists within the Kotlin DSL processing, the attacker does not need prior authentication or a user account to initiate the attack. Crucially, simply using the standard Kotlin DSL features for normal build configurations does not trigger the bug; it requires the malicious input specifically designed to exploit the sandbox escape mechanism.

Is my TeamCity instance at risk?

Halo Surface Signal indicates that TeamCity servers are often deployed as internet-accessible web applications to support distributed teams and external service integrations. If your instance is reachable from the internet, it is considered higher risk because the vulnerability is exploitable over the network. Even internal instances should be evaluated, but those exposed to the public internet are the primary focus for potential unauthorized access.

What should I do if I run TeamCity?

First, identify all TeamCity instances within your infrastructure and confirm their current version numbers. Check if your versions fall into the affected ranges—specifically before 2025.11.7 or between 2026.1.1 and 2026.1.3. Once you have an inventory, coordinate with your infrastructure team to prioritize updating these servers to a secure version to neutralize the remote code execution risk.

References

www.jetbrains.com/privacy-security/issues-fixed/

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.