JetBrains TeamCity CVE-2026-100253

Exploitation requires an authenticated TeamCity account with permission to create or modify a project's versioned settings using the Kotlin DSL (settings-as-code) feature - this is the exact feature named in the advisory. The attacker must be able to supply/commit a Kotlin DSL configuration that TeamCity will evaluate; the flaw is the DSL sandbox failing to block certain disallowed inputs (CWE-184). Limiting factors: PR:L means it is not exploitable by fully anonymous remote users, and organizations that do not use versioned settings / Kotlin DSL, or that tightly restrict who can edit build configurations, materially reduce exposure. No user interaction is required once malicious settings are processed (UI:N).

This is a genuine high-priority issue rather than an inflated CVSS score. The vendor-provided CVSS:3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H = 8.8) is internally consistent with the described impact: a sandbox escape in the versioned settings Kotlin DSL that yields code execution on the TeamCity server. The critical honest caveat is PR:L - this is NOT an unauthenticated bug. An attacker needs a valid account with sufficient permission to author or modify versioned settings (Kotlin DSL) for a project, so the realistic threat model is a malicious or compromised project/build engineer, a rogue contributor to a repository whose settings are stored as code, or an attacker who has already phished a developer account. No EPSS score, no CISA KEV listing, and no public POC are present in the supplied data, so there is no evidence of active exploitation or automated weaponization at this time; exploitation status is 'no public exploit identified at time of analysis.' The CWE-184 mapping (incomplete list of disallowed inputs) fits a sandbox that fails to block certain Kotlin constructs. Net: because successful exploitation gives full RCE on a CI/CD server - a high-value software-supply-chain target - defenders running TeamCity with self-service versioned settings should treat this as urgent to patch despite the authentication requirement.

An attacker with a low-privileged TeamCity account that can edit a project's versioned settings commits or supplies a crafted Kotlin DSL configuration that abuses constructs the sandbox fails to disallow. When TeamCity evaluates the DSL, the payload escapes the sandbox and executes arbitrary code in the server process context. No public exploit code was identified in the supplied data, but the attack requires no user interaction once the malicious settings are processed.