JetBrains TeamCity CVE-2026-65906

Exploitation requires the ability to supply crafted Kotlin DSL to a TeamCity server running a version below 2026.1.2 or 2025.11.6 - i.e., the target must use TeamCity's Kotlin DSL / versioned-settings feature, and the attacker must be able to introduce DSL content (typically via write access to the VCS repository backing project settings or via project-settings edit rights). The NVD vector marks this PR:N (unauthenticated), but the realistic prerequisite of submitting DSL implies at least VCS-write or project-edit privilege, so the true authentication requirement is not fully confirmed from available data and should be validated with JetBrains. Limiting factors: servers that do not enable Kotlin/versioned settings, that restrict settings-write permissions, or that are not network-reachable by the attacker are materially harder to exploit.

The NVD-style CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H = 10.0) paints a worst-case picture: unauthenticated, network-reachable, low-complexity RCE with a scope change and total impact. However, that maximal score partially conflicts with how the Kotlin DSL is actually reached - supplying DSL to a project normally requires write access to a connected VCS repository or project-settings edit rights, which implies some level of authenticated/privileged access; PR:N should be verified against the vendor's exploitation model, and my independent assessment uses PR:L for this reason. The supporting signals temper the raw score: SSVC records Exploitation=none and Automatable=no (only Technical Impact=total is severe), EPSS is a modest 0.40%, and no POC or KEV listing exists, so this reads as a high-impact-but-not-yet-exploited priority rather than an actively-weaponized emergency. That said, TeamCity is a high-value CI/CD target whose compromise enables supply-chain attacks, so even a mid-sized operator should treat patching as urgent and not defer it on the strength of the low EPSS alone. Bottom line: prioritize the update quickly, but the 'unauthenticated' framing warrants confirmation with JetBrains' advisory.

An attacker with the ability to submit Kotlin DSL settings - for example by committing to a VCS repository that TeamCity uses for versioned settings, or by abusing an exposed settings endpoint - crafts DSL that breaks out of the evaluation sandbox. When TeamCity compiles and evaluates the settings, the malicious code runs on the server, letting the attacker steal VCS/deployment credentials and tamper with builds. No public POC is identified at time of analysis, and the low-complexity network vector means exploitation is straightforward once DSL submission is possible.