JetBrains has released security updates for a critical TeamCity code execution vulnerability affecting TeamCity On-Premises. The issue is severe enough to earn a CVSS score of 9.8, and—according to JetBrains—can be exploited remotely without authentication to achieve remote code execution (RCE).
For organizations running TeamCity as part of their CI/CD workflows, this matters quickly: an attacker who gains the right path into the application could potentially reach the underlying system, interfere with builds, and impact downstream pipelines.
What makes the vulnerability so dangerous
JetBrains tracks the flaw as CVE-2026-63077. The core risk is that an attacker can bypass authentication checks by abusing the way TeamCity agents poll the server over HTTP/S.
In its advisory, JetBrains explains that an unauthenticated attacker could exploit the vulnerability through the TeamCity agent polling protocol to execute arbitrary operating system commands. Those commands would run with the privileges of the TeamCity server process, which can vary by deployment.
Depending on what permissions the TeamCity server has, the impact can range from data access to wider CI/CD compromise—potentially including tampering with server state, accessing sensitive TeamCity data such as configurations and credentials, and manipulating build artifacts that later flow into production pipelines.
Affected products and where the issue applies
JetBrains states that the vulnerability affects all TeamCity On-Premises versions. That means there is no “safe” baseline within the On-Premises line as long as you remain on an unpatched release.
The company also notes that it has already rolled out mitigations for TeamCity Cloud instances. Additionally, JetBrains says it has no evidence that the bug has been exploited in the wild.
How attackers may leverage it
The attack path described by JetBrains focuses on authentication bypass combined with remote command execution. In practical terms, an attacker does not need a user account or valid login session; instead, they can use the agent polling behavior exposed by the server.
Once code execution is achieved, the security impact depends heavily on local privileges:
- The attacker could potentially access TeamCity data, configurations, and stored credentials.
- They could tamper with server state.
- They could compromise build artifacts and influence downstream CI/CD pipelines.
Because CI/CD systems are often positioned as trusted automation components, any compromise can cascade—especially if artifacts produced by TeamCity are used directly in later stages without additional verification.
What JetBrains recommends: patch as soon as possible
JetBrains introduced fixes in specific TeamCity versions:
- TeamCity 2025.11.7 and later within that branch
- TeamCity 2026.1.3 and later within that branch
If you cannot upgrade immediately, JetBrains also released a security patch plugin for 2017.1+. The company emphasizes an important detail: the plugin resolves only this CVE, so it is meant to address this specific risk rather than act as a general update.
JetBrains advises users to download and install either the latest TeamCity version or the security patch plugin as soon as possible.
Quick decision guide for teams
If you manage TeamCity and need a practical next step, start by determining where you are on your upgrade path:
Option 1: Upgrade to the fixed TeamCity versions
Upgrade to the versions JetBrains lists as containing the fix. This is typically the best approach if your environment can support an update window.
Option 2: Use the security patch plugin if upgrade is blocked
If operational constraints prevent upgrading right away, apply the security plugin for your supported 2017.1+ releases. JetBrains notes that it only addresses the CVE in question, so plan a fuller upgrade afterward.
Verify you are actually protected
After applying the upgrade or plugin, confirm the deployed environment matches a fixed state. For security teams, that usually means checking the running TeamCity version and ensuring the patch component is installed correctly.
Hardening steps to reduce exposure
Beyond patching, JetBrains provides several recommendations aimed at limiting the chance that attackers can reach the application in the first place.
Consider implementing the following controls:
- Limit access to internet-facing TeamCity servers. Reduce exposure to the public internet and restrict who can connect.
- Use the minimum required operating system privileges. Run TeamCity servers with only the permissions necessary for operation.
- Prefer VPN access or additional protections. JetBrains recommends using VPN connections or adding extra safeguards to prevent unauthorized access.
- Separate servers and agents. Run TeamCity servers on dedicated hosts separate from build agents.
The last point is especially relevant in CI/CD environments, where build agents may process untrusted code from repositories. Separating the core server from agent execution helps contain potential blast radius if an agent is compromised.
Why this matters for CI/CD pipelines
Even though the bug is a TeamCity application issue, the business risk extends to what TeamCity does: automating builds, tests, and artifact creation. When RCE is possible on the TeamCity server, the attacker can potentially affect:
- Build outputs (artifacts produced by jobs)
- Pipeline behavior (what gets built, how steps run, and what credentials are available)
- Downstream systems that consume those artifacts
That is why defenders should treat this as more than a “patch and forget” item. After patching, review pipeline integrity measures—especially where artifacts are promoted to further stages.
Bottom line
JetBrains has patched a critical TeamCity code execution vulnerability, CVE-2026-63077, that can be exploited without authentication to bypass checks and execute operating system commands over HTTP/S. The fix is available in TeamCity 2025.11.7 and 2026.1.3, and there is also a dedicated security patch plugin for 2017.1+ deployments.
If you operate TeamCity On-Premises, prioritize upgrading or applying the plugin immediately, then follow JetBrains’ hardening guidance—especially limiting internet exposure, using least-privilege OS accounts, and separating TeamCity servers from build agents.
Source: https://www.securityweek.com/critical-code-execution-vulnerability-patched-in-teamcity/
