Safeguard
Vulnerability Analysis•

CVE-2026-106218: JetBrains TeamCity Kotlin DSL Sandbox Escape

CVE-2026-106218 is a Kotlin DSL sandbox escape leading to RCE on TeamCity before 2026.1.3 and 2025.11.7. Upgrade TeamCity and review who can edit build configs.

Safeguard Security Team
3 min read

CVE-2026-106218 is a high severity (CVSS 8.8) flaw in JetBrains TeamCity. A Kotlin DSL sandbox escape could lead to remote code execution on the server. The record lists fixes in 2026.1.3 and 2025.11.7. Upgrade your TeamCity server, and limit who can change build configurations.

What's affected

The record says: In JetBrains TeamCity before 2026.1.3 and 2025.11.7, a Kotlin DSL sandbox escape leading to RCE on the server was possible. In practice that reads as two fixed releases, 2026.1.3 on the 2026.1 line and 2025.11.7 on the 2025.11 line. Check JetBrains' issues fixed page to confirm which applies to your line, since the page did not render for us without a browser.

The vector lists low privileges, so the attacker needs an account that can influence the Kotlin DSL configuration.

How to check if you're exposed

Find your TeamCity server version on the Administration page, or in the footer of the web interface, and compare it with the two fixed releases.

Then think about who can change the Kotlin DSL: anyone who can push to a repository that holds versioned settings, edit project settings in the UI, or submit a pull request that your build runs with settings enabled. Write that list down, because it defines your exposure.

What to do now

  1. Upgrade TeamCity to 2026.1.3 or 2025.11.7 or later, whichever matches your line.
  2. Check JetBrains' issues fixed page for the matching entry and for any extra steps.
  3. Limit who can edit project settings and the Kotlin DSL, and require review of settings changes.
  4. Run the TeamCity server with the fewest rights it needs, and keep secrets away from the server's own account.
  5. Review recent changes to build configurations for anything you do not recognise.

Why it matters

A DSL sandbox exists to let people describe builds in code without letting that code do anything it likes on the server. A sandbox escape breaks that promise. The record files it under CWE-184 (incomplete list of disallowed inputs), which points to the usual cause: a list of things the sandbox refuses, with a gap in it.

A CI server is a particularly rich target. It holds repository access, deployment keys and signing material, and it runs code for many people. Code execution on it can reach production through the build pipeline.

The record gives no sign of exploitation in the wild, and the KEV flag is false.

Quick check

Who could take advantage of this?

The vector lists low privileges, so someone with an account that can influence Kotlin DSL configuration. Keep that group small and reviewed.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.