JetBrains TeamCity CVE-2026-63077: Unauthenticated Remote Code Execution via the Agent Polling Protocol

TL;DR — 90 seconds

Affected?

Per JetBrains, all TeamCity On-Premises versions; the security patch plugin is offered for installations from version 2017.1 onward. TeamCity Cloud is not affected — JetBrains has already applied the necessary measures there.

Risk?

Unauthenticated remote code execution via the agent polling protocol (CWE-502, deserialization of untrusted data per GHSA-94gx-v738-fx9w) — no credentials, no user interaction required. CVSS 9.8 per GitHub Security Advisory and several trackers, not scored by JetBrains itself.

Immediate action?

Upgrade to 2025.11.7 or 2026.1.3. If you can't upgrade immediately, install the security patch plugin fix_CVE_2026_63077.zip (available from version 2017.1 onward) and restrict access to the agent polling endpoint to trusted networks.

Recommendation?

Never expose a TeamCity server unprotected to the internet, regardless of patch status. Also check whether the conflicting reports on active exploitation have been resolved since this post was published.

Criticality?

critical (hero badge) — unauthenticated RCE with full server compromise, core CI/CD system, CVSS 9.8 per several independent sources, even though not directly scored by JetBrains.

What is the problem?

TeamCity On-Premises is JetBrains' self-hosted CI/CD server: it orchestrates build pipelines, manages credentials for repositories and artifact registries, and coordinates build agents that perform the actual compile and test work. Communication between agent and server runs over what's called the agent polling protocol: the agent establishes an HTTP(S) connection to the server and periodically polls for new commands, build configurations, and jobs — per JetBrains' own documentation, a “unidirectional agent-to-server connection” over the same URL that also serves the web UI and REST API.

CVE-2026-63077 undermines exactly this channel: an attacker can bypass the agent polling protocol's authentication checks and use it to execute arbitrary operating system commands with the privileges of the TeamCity server process — without valid credentials, without a session token, without user interaction. Several independent sources (GitHub Security Advisory GHSA-94gx-v738-fx9w, threat-intel vendor IONIX) classify the flaw as CWE-502, “Deserialization of Untrusted Data” — suggesting the server deserializes and processes insufficiently validated serialized data received as part of agent communication. JetBrains' own advisory does not state a CWE classification; this categorization comes from secondary sources and should be treated as plausible, not as confirmed by JetBrains.

Because the vulnerable channel runs over the same HTTP(S) endpoint as regular server communication, it's practically indistinguishable from legitimate agent traffic without patching the server-side code itself — a firewall rule against “suspicious” requests alone is not a reliable fix here, at best a stopgap until the patch is applied.

Who is affected?

TeamCity On-Premises is typically run by organizations that, for compliance, data-sovereignty, or customization reasons, don't want or can't use a SaaS CI/CD solution — ranging from mid-market companies with a manageable number of build pipelines to enterprises with hundreds of projects and dozens of build agents. In exactly these on-premises environments, the TeamCity server has often grown over years, is rarely rebuilt from scratch, and not infrequently runs an older version because upgrades are seen as risky for running pipelines — precisely the profile a patch plugin for versions from 2017.1 onward addresses. TeamCity Cloud is, per JetBrains, not affected by CVE-2026-63077; the necessary protective measures have already been applied there, and customers don't need to take action themselves.

Impact

Successful exploitation of CVE-2026-63077 gives an unauthenticated attacker code execution with the privileges of the TeamCity server process — in practice, full control over the CI/CD server. That typically includes access to stored credentials (VCS credentials, deployment secrets, artifact signing keys), to the source code of all connected repositories, and to already-built build artifacts. An attacker with server access can tamper with build configurations to inject malicious code into future builds, or swap already-built artifacts before they're rolled out or published downstream.

Because TeamCity acts as a central build and release instance, the blast radius extends beyond the server itself: any system that consumes artifacts or container images from a compromised TeamCity instance potentially inherits the risk — a classic supply-chain scenario. Anyone shipping signed artifacts whose signing keys live on the same server must, in the event of compromise, also reassess the trustworthiness of every artifact already shipped under that signature. Because the vulnerability is exploitable without authentication over a channel build agents contact regularly anyway, mere reachability of an instance from a not-fully-trusted network is enough — no compromised credentials and no insider are required.

Mitigation / immediate steps

Operational decision block

• Act today if … your TeamCity On-Premises instance is reachable from the internet or a not-fully-trusted internal network and hasn't yet been updated to 2025.11.7 or 2026.1.3.
• Check with priority if … an immediate upgrade isn't operationally possible — in that case, install the security patch plugin and restrict network access to the agent polling endpoint.
• Just monitor if … the instance is already patched and demonstrably reachable only from a tightly controlled network segment with no external access.

Step 1 — Upgrade to a fixed version

# Check installed version: Administration -> Server Administration
# or "About" in the web UI

# Recommended target, depending on branch:
# 2025.11.x -> 2025.11.7 or newer
# 2026.1.x  -> 2026.1.3 or newer

# Follow JetBrains' upgrade documentation for the update procedure
# (don't skip the backup before upgrading)

Step 2 — Install the security patch plugin (if an immediate upgrade isn't possible)

# For TeamCity 2024.03+: automatic notice under
# Administration -> Updates -> Available Security Updates

# Manual installation (all versions from 2017.1 onward):
# 1. Download the plugin:
#    download.jetbrains.com/teamcity/plugins/internal/fix_CVE_2026_63077.zip
# 2. Upload and enable it under Administration -> Plugins
#
# Note: TeamCity 2017.1-2018.1 requires a server restart after
# installation; from 2018.2 onward, the plugin can be enabled without one.

Step 3 — Restrict network access to the agent polling endpoint

# The agent polling channel runs over the same HTTP(S) endpoint as the
# TeamCity web UI and REST API (configured via serverUrl).
# Until fully patched/upgraded:
#
# - Restrict server access to known agent IPs and admin networks
#   (firewall rule / reverse-proxy ACL)
# - Don't expose the server directly to the internet;
#   require a VPN or equivalent access control in front of it
# - Run the TeamCity server process with minimal OS privileges on a
#   dedicated host, separate from the build agents

Detection / verification

JetBrains has not published specific log signatures or indicators of compromise for CVE-2026-63077 so far. The following checks are based on general TeamCity administration practices and should be treated as a starting point, not a complete forensic playbook.

Check version and patch status

# Installed version: Administration -> Server Administration -> "About"
# or in the server startup log (teamcity-server.log) during boot

# Check installed plugins for the patch (is it present?):
# Administration -> Plugins -> search for "fix_CVE_2026_63077"

# Check for available security updates (2024.03+ only):
# Administration -> Updates -> Available Security Updates

Check agent and access logs

# Review the list of authorized/unauthorized agents:
# Agents -> Unauthorized -- look for unknown or unexpected agent entries

# Search server and access logs for unusual registration/polling requests
# (exact paths and field names vary by TeamCity version/reverse-proxy setup;
# use this as a starting point, not a definitive signature):
grep -iE "agent|register|xmlrpc" teamcity-server.log | tail -n 200

# Identify access to the TeamCity server port from unexpected external
# IP ranges in firewall/reverse-proxy logs

• Unknown or unexpected entries under "Unauthorized Agents" in the TeamCity web UI
• Agent registration or polling requests from IP ranges that don't belong to known build agents
• Unexpected child processes of the TeamCity server process (java) at the OS level
• New changes to build configurations, stored credentials, or artifact registries that aren't explained by regular pipeline runs
• Unexpected outbound connections from the TeamCity server host that don't match normal build/deployment traffic

Operator guidance

Mid-market

Check immediately whether your TeamCity instance is reachable from the internet or a not-fully-trusted network. If so, prioritize the upgrade to 2025.11.7/2026.1.3; if that's not possible short-term, install the security patch plugin and restrict access to trusted networks. With limited internal resources, a short external reachability check is worthwhile — reverse-proxy misconfigurations or VPN routing errors are a common reason management systems end up unintentionally publicly reachable.

Enterprise

Beyond patching: design network segmentation so that core CI/CD systems like TeamCity are never directly reachable from untrusted networks, regardless of patch status. With multiple TeamCity instances or complex agent farms, set up centralized monitoring for the indicators listed above, and check whether artifact signing keys live on the same server as the TeamCity process — if so, consider rotation after a security incident of this magnitude. Given the conflicting reports on active exploitation (JetBrains: no known exploitation; IONIX: observed exploitation attempts), a conservative risk assessment is advisable until the picture becomes clearer.

Decision block

• Patch immediately: upgrade to 2025.11.7/2026.1.3, or alternatively install the security patch plugin.
• Compensate if the patch is delayed: restrict network access to the agent polling endpoint, require a VPN for server access.
• Monitor: check the agent authorization list and server logs for the indicators listed above, even after patching — as evidence of whether access occurred before the update.

Conclusion

CVE-2026-63077 is a textbook example of what's at stake when the core component of the build pipeline itself can be compromised remotely without authentication: a single exploited server potentially means access to source code, credentials, and signing keys for everything that server has ever built. That JetBrains itself doesn't cite a CVSS score, while third-party sources consistently report 9.8, and that reports on active exploitation conflict, doesn't change the fundamental urgency: unauthenticated RCE in an internet-adjacent CI/CD system is critical by definition, regardless of the exact decimal. Anyone running TeamCity On-Premises should not just patch, but use the occasion to review the network placement and access controls of their own build server from the ground up.

Sources

• JetBrains Blog — Critical Security Issue Affecting TeamCity On-Premises (CVE-2026-63077)
• Help Net Security — JetBrains fixes critical unauthenticated RCE in TeamCity On-Premises (CVE-2026-63077)
• The Hacker News — Critical TeamCity Flaw Could Let Attackers Run OS Commands Without Logging In
• Cyber Security News — JetBrains Urging Customers to Patch Critical TeamCity Flaw that Enables OS Command Execution
• GitHub Security Advisory GHSA-94gx-v738-fx9w — JetBrains TeamCity Unauthenticated Remote Code Execution
• IONIX Threat Center — CVE-2026-63077 Technical Analysis
• NVD — CVE-2026-63077 (record status checked during research)
• JetBrains TeamCity Documentation — Install and Start TeamCity Agents (Agent-Server Communication)