Your Build Pipeline Is the Crown Jewel Attackers Actually Want

The Infrastructure You Trust Most Is the Infrastructure They Target First

Organizations spend enormous resources protecting endpoints and production servers while their CI/CD infrastructure sits in a privileged position with minimal scrutiny. Build systems have access to source code, secrets, signing certificates, and deployment credentials. They can push code to production. They authenticate to everything. When adversaries compromise a build server, they don't just get a foothold; they get the keys to the kingdom and a mechanism to distribute malicious code to every system in your environment.

This pattern has played out repeatedly: SolarWinds, Codecov, and countless smaller incidents that never made headlines. Attackers understand that one compromised build server can yield access that would otherwise require dozens of separate intrusions. The systems that compile and deploy your software are high-value targets precisely because they are trusted.

Now there is another data point confirming this pattern, and it requires immediate action if you run JetBrains TeamCity.

TeamCity's Agent Protocol Becomes an Entry Point

CVE-2026-63077 is a critical deserialization vulnerability in JetBrains TeamCity that allows unauthenticated remote code execution via the agent polling protocol. An attacker who can reach the TeamCity server over the network can execute arbitrary code without any credentials, achieving SYSTEM-level access on Windows installations or root-equivalent on Linux deployments.

CISA added this vulnerability to the Known Exploited Vulnerabilities catalog on August 5, 2026, confirming active exploitation in the wild. The vulnerability carries a CVSS score of 9.8, with network-accessible attack vector, low complexity, no privileges required, and no user interaction needed. This is about as severe as vulnerabilities get.

The flaw exists in how TeamCity handles serialized data within its agent communication protocol. Build agents poll the server for work; the protocol that handles these requests deserializes attacker-controlled data without proper validation. This is not a theoretical concern: it is being exploited now against internet-exposed TeamCity servers.

Affected Versions

Patched versions:

• TeamCity 2025.11.7 for the 2025.11.x branch
• TeamCity 2026.1.3 for the 2026.1.x branch

Patches are available from the JetBrains download portal. Refer to the official security advisory at https://www.jetbrains.com/privacy-security/issues-fixed/ for additional details.

What This Actually Means If You're Exposed

An attacker exploiting this vulnerability gains code execution with the privileges of the TeamCity server process. On default Windows installations, this is typically SYSTEM. From this position, the attacker has immediate access to all build configurations, including embedded secrets, environment variables containing API keys, and any credentials stored in TeamCity's credential store. They can read source code for every project, access deployment keys, and examine signing certificates.

The attack path extends well beyond the TeamCity server itself. Build agents that connect to the compromised server can be commandeered. Deployment pipelines can be modified to inject backdoors into artifacts. If your TeamCity server pushes builds to production, an attacker can poison those deployments. Lateral movement into source control systems, artifact repositories, and cloud infrastructure becomes trivial when the attacker inherits the permissions your CI/CD system already holds. This is not just a server compromise; it is a supply chain compromise waiting to happen.

What To Do About It

1. Update immediately to TeamCity 2026.1.3 or 2025.11.7, depending on your current branch. Download from the official JetBrains site and follow their upgrade documentation.

1. Restrict network access to the TeamCity server. The agent polling protocol should not be exposed to the internet. If your TeamCity server is reachable from untrusted networks, place it behind a VPN or firewall that limits access to known build agent IPs and administrator workstations.

1. If immediate patching is not possible, block external access to the TeamCity server entirely and monitor for unusual process execution. This is a temporary measure, not a substitute for patching.

1. Review TeamCity logs for anomalous agent registration or connection attempts from unexpected IP addresses. Look for unusual child processes spawned by the TeamCity server process. On Windows, monitor for unexpected PowerShell, cmd.exe, or certutil.exe execution under the TeamCity service account. On Linux, check for shells or download utilities spawned by the Java process running TeamCity.

1. Audit secrets and credentials stored in TeamCity. If you cannot confirm the server was not compromised before patching, rotate any credentials the system had access to, including deployment keys, cloud provider tokens, and repository access tokens.

Build Systems Deserve Production-Grade Security

The same logic that puts your databases behind multiple layers of access control should apply to your CI/CD infrastructure. TeamCity servers are not internal tools that can be secured with obscurity; they are privileged systems that compile and deploy your software. This vulnerability is a reminder that build infrastructure is critical infrastructure, and treating it otherwise creates exactly the kind of gap adversaries exploit.

Patch today; exploitation is already underway.