External risk intelligence

JetBrains TeamCity Kotlin DSL Sandbox Escape Leading to Code Execution

CVE advisorySeverity: CRITICAL (CVSS 10.0)

CVE-2026-65906

JetBrains TeamCity is commonly deployed as a continuous integration and delivery server. These platforms frequently serve as centralized, network-accessible web applications or management portals within development environments, making them a common target for network-based interaction.

Code Injection

Jetbrains Teamcity

before 2025.11.62026.1 to before 2026.1.2

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 critical vulnerability in JetBrains TeamCity allows for unauthenticated code execution, potentially impacting systems that manage software development pipelines. This issue arises from an escape vulnerability within the Kotlin DSL sandbox, meaning an attacker could potentially run arbitrary code on affected servers without needing any credentials. The main concern is confirming relevance and exposure, as the broad applicability of TeamCity in development workflows means a wide range of organizations could be affected.

Unauthenticated code execution in development tools.
Critical flaw could disrupt software build processes.
Confirm relevance to protect development pipelines.

Attack Path

How an attacker could exploit the issue

An attacker could potentially achieve code execution by exploiting a sandbox escape vulnerability in the Kotlin DSL feature of JetBrains TeamCity. This could occur if an attacker can interact with a vulnerable TeamCity instance over the network, without requiring any user interaction or prior authentication. Successful exploitation may lead to the attacker gaining control over the server.

No authentication or user interaction needed.
Triggered through interaction with Kotlin DSL.
Risk of remote code execution.

Live Threat

Current exploitation, exposure, and threat context

When supported by the advisory, an attacker could execute arbitrary code on the server by escaping the Kotlin DSL sandbox. This could potentially impact the integrity and availability of the TeamCity service and any data it processes.

Server code execution.
Exploiting Kotlin DSL sandbox escape.
Compromise of service and data.

Operational Fix

Recommended remediation, mitigation, and detection steps

JetBrains TeamCity instances, particularly those exposed externally, require immediate attention from platform and security teams due to a critical code execution vulnerability. The first practical step is to inventory all TeamCity deployments, determine their external reachability and business criticality, and then assign ownership for remediation. Planning for updates should consider existing maintenance windows or vendor coordination.

Platform and security teams own this issue.
Verify external reachability and criticality.
Plan remediation, considering maintenance windows.

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 continuous integration and delivery (CI/CD) server used by development teams to automate the building, testing, and deployment of software. It functions as a central management hub for development pipelines, often connecting to code repositories and cloud infrastructure to orchestrate automated workflows.

What does CVE-2026-65906 mean for code security?

This vulnerability is classified as CWE-94, which involves the improper control of code generation. In this case, an attacker can escape the Kotlin DSL sandbox. A sandbox is a protective barrier intended to restrict code to a safe, isolated environment. By bypassing this, an unauthorized user can execute arbitrary code on the underlying server, effectively breaking the security isolation that usually contains build scripts.

How does an attacker trigger this TeamCity vulnerability?

An attacker triggers this flaw by interacting with the Kotlin DSL feature over the network. Crucially, the vulnerability does not require the attacker to have valid credentials or perform any prior authentication, nor does it require any action from a legitimate user to initiate the exploit.

Is my TeamCity instance at high risk?

According to Halo Surface Signal, TeamCity servers are frequently deployed as network-accessible portals for development teams, making them attractive targets. If your instance is reachable over the internet or accessible to untrusted network segments, it is considered more exposed to external interaction than a system restricted to a private, internal-only network.

How should I respond to this advisory?

Start by identifying all TeamCity instances running in your environment. Check their version numbers against the affected ranges provided in the advisory and prioritize those that are internet-facing. Once you have an inventory, coordinate with your infrastructure teams to plan and apply the necessary updates provided by the vendor to close the sandbox escape path.

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.