Critical TeamCity flaw let attackers break out of Kotlin DSL sandbox to run code on the server

What’s actually been disclosed

A newly published vulnerability, CVE-2026-106218, affects JetBrains TeamCity, the continuous integration and deployment server widely used by software teams to automate builds. According to the National Vulnerability Database entry, versions before 2026.1.3 and 2025.11.7 contain a flaw in the Kotlin DSL sandbox — the isolated environment TeamCity uses to safely run configuration scripts written in Kotlin — that could be escaped to achieve remote code execution on the server itself. NVD rates it critical, with a CVSS score of 8.8.

JetBrains lists its security fixes on a dedicated issues-fixed page, which is the company’s standard channel for this kind of disclosure. That’s the extent of what’s independently confirmed right now: a named bug, a severity score, and a fixed version number.

What the bug actually does

TeamCity’s Kotlin DSL lets teams define build configurations as code rather than clicking through a UI. Because that code can come from less-trusted sources — a contributor’s branch, say — it’s meant to run inside a sandbox that stops it touching anything outside its own box. This vulnerability is a sandbox escape: a way of writing DSL code that breaks out of that containment and executes arbitrary commands on the underlying TeamCity server, rather than just within the confined build logic. On a CI/CD server, that’s a serious category of bug, since the server typically holds deployment credentials, source code access and the keys to pushing software into production.

So who is actually at risk

Only organisations running a self-hosted TeamCity server on an affected version are exposed — this is not a vulnerability in Kotlin, IntelliJ, or any consumer-facing JetBrains product, and ordinary developers using the IDE day-to-day have nothing to worry about here. The people who need to care are DevOps and platform teams responsible for maintaining TeamCity instances, particularly on-premises deployments that haven’t been updated past 2026.1.3 or 2025.11.7.

What we don’t yet know, and what NVD’s listing doesn’t tell us, is how many installations remain unpatched, nor whether anyone has exploited this in the wild before the fix landed. There’s no public evidence of active exploitation at the time of writing. Given how useful a CI server takeover is to an attacker — it’s a direct route into a company’s build pipeline and potentially its production environment — this is exactly the kind of flaw that tends to attract interest once technical details circulate more widely, but that’s a reasonable expectation rather than a confirmed fact.

What to do about it

If you administer a TeamCity server, the fix is straightforward: update to 2026.1.3, 2025.11.7, or later. JetBrains’ issues-fixed page is the place to confirm your specific build is covered. There’s no indication of a workaround for older versions beyond restricting who can submit DSL configuration changes in the meantime, which is sensible practice regardless.

For everyone else — developers, gamers, anyone not running infrastructure — this changes nothing about your day. The lesson, as ever with CI/CD tooling, is that these servers are high-value targets precisely because they sit upstream of everything else, so patching them promptly matters more than it might for a typical desktop application. Treat this as a prompt for IT teams to check their TeamCity version, not a reason for broader alarm.