TeamCity Kotlin DSL sandbox escape (CVE-2026-106218): what to patch and how to hunt

A detection and hunting guide published on dev.to addresses CVE-2026-106218, a sandbox escape in the TeamCity Kotlin DSL integration rated 8.8 in severity that enables arbitrary code execution on the build host. The underlying advisories were covered by SecurityOnline as part of a broader set of JetBrains vulnerability disclosures.

The vulnerability and its precondition

According to the dev.to write-up, escaping the sandbox first requires an attacker to gain influence over Kotlin DSL configuration content. No exploitation has been confirmed in the wild and no public proof-of-concept exists, so security teams are, unusually, working ahead of attackers rather than reacting to them. The author argues this is a sensible moment to build detections, because the relevant signals remain readable and have not been drowned out by real attack noise.

Where to hunt first: configuration history

The recommended starting point is the set of repositories that feed TeamCity build configurations, examined across the exposure window. Specific things to look for include:

• commits that modify build-configuration files coming from accounts that seldom edit them
• edits introducing shell commands, outbound fetches or file writes
• merges that skipped the normal code review path
• settings changed directly through the TeamCity web UI instead of via version control

Any of these can suggest the precondition for the escape was being established.

Host-level telemetry

Because the impact lands as code execution on the TeamCity server itself, process telemetry is the most useful evidence. Build infrastructure is noisy by nature, so the guide stresses building a baseline before hunting. After that, watch for:

• child processes parented by the TeamCity server process rather than a build agent worker
• outbound traffic from the server host toward destinations outside the usual dependency set
• new scheduled tasks, services or persistence entries appearing on the build machine
• access to files that hold credentials

Artefact integrity

Tampering also shows up downstream. The dev.to piece recommends hashing artefacts produced during the exposure window and comparing them against a rebuild from a pinned source revision. Discrepancies deserve investigation even when the pipeline reported success — a clean build log does not guarantee a clean build.

Versions, fixes and exposure

The fix is available in TeamCity 2026.1.3 and 2025.11.7. Two related issues appear in the same advisory batch, per the article: one affecting versions of the Exposed library prior to 1.5.1, and a submodule URL handling flaw resolved in 2026.2.1. No installation counts have been published by the vendor.

For exposure sizing, a fingerprint query for the TeamCity application returns 1,868 internet-reachable instances globally, while a query using the CVE identifier returns no results yet. The instance count is the more useful anchor for an external attack-surface review, though it says nothing about how many of those systems are already patched.

Why it matters

Build servers concentrate exactly what attackers want: source code, signing material and credentials that reach deep into production environments. A sandbox escape in the DSL layer converts modest write access to build configuration into full execution on the host, turning a limited foothold into a potential supply-chain incident. The dev.to guide closes with a practical sequence — patch first, since a patched system still preserves forensic evidence, then work through configuration history, host process trees and artefact integrity, and finally rotate any credentials the build host could reach. Its closing caveat is worth keeping in mind: an empty hunt result means no evidence was found, not that no compromise occurred.