Published: 2026-07-28
Categories: Application Security
Key Takeaways
JetBrains disclosed CVE-2026-63077 on July 27, 2026, a critical unauthenticated remote code execution vulnerability affecting all on-premises versions of TeamCity, its widely deployed continuous integration and continuous delivery server [1][2]. The flaw carries a CVSS 3.1 score of 9.8 and stems from insecure deserialization of untrusted data (CWE-502) in the protocol that TeamCity build agents use to poll the server for jobs and configuration [2][3]. Because the affected endpoint requires no authentication, session token, or user interaction, an attacker with network access to a vulnerable server can send a single malicious payload and execute arbitrary operating system commands with the privileges of the TeamCity server process [1][3]. Security researcher Antoni Tremblay reported the issue to JetBrains privately on July 10, 2026, under coordinated disclosure, and the vendor shipped fixes in versions 2025.11.7 and 2026.1.3, along with a security patch plugin for organizations running older releases back to version 2017.1 [2]. JetBrains states it is not aware of active exploitation as of publication, but the vulnerability’s unauthenticated, zero-interaction profile and TeamCity’s history as a target of nation-state and ransomware operators make rapid patching a priority rather than a routine maintenance item [1][2][4]. TeamCity Cloud customers are not affected and require no action [2].
Background
TeamCity is JetBrains’ continuous integration and continuous delivery platform, used by organizations to automate building, testing, and deploying software across a wide range of ecosystems. Like other CI/CD servers, it occupies a position of outsized trust within the software delivery lifecycle: it holds source code access, build credentials, deployment secrets, and often direct network paths into production environments, which makes it a high-value target whose compromise can cascade far beyond the server itself. This is not a new observation about TeamCity specifically. In September 2023, CVE-2023-42793, an authentication bypass vulnerability in TeamCity On-Premises, was exploited at scale by Russian Foreign Intelligence Service (SVR)-affiliated actors tracked as APT29, prompting a joint advisory from CISA, the FBI, the NSA, and international partners after more than 100 compromised servers were identified across software development environments worldwide [4]. That campaign demonstrated concretely how a single authentication flaw in a CI/CD server can become a foothold for supply chain-scale espionage, since compromising the systems that build software effectively compromises everything those systems produce and touch. A second TeamCity authentication bypass, CVE-2024-23917, was disclosed in February 2024 [7], and threat intelligence teams assessed at the time that attackers were likely to move against it quickly given the pattern set by CVE-2023-42793 months earlier [8], reinforcing that this product category draws sustained attacker attention.
CVE-2026-63077 differs from those earlier flaws in its technical root cause but sits in the same category of risk. Rather than an authentication logic bypass, the new vulnerability arises from how the TeamCity server deserializes data sent by build agents polling for work [2][3]. Deserialization vulnerabilities of this kind are a longstanding and well-documented class of software weakness: when a server reconstructs objects from untrusted network input without adequately validating or restricting what those objects can be, an attacker who controls the serialized payload can often coerce the receiving application into executing arbitrary code. JetBrains’ advisory does not disclose the full technical mechanics of the deserialization chain, consistent with standard practice for actively-patched vulnerabilities, but confirms that the agent polling protocol channel does not require authentication and that a crafted request against it can trigger the vulnerable deserialization path [2].
Security Analysis
The practical exploitation path for CVE-2026-63077 is unusually simple, a combination that this note assesses as materially elevating its risk profile. An attacker needs only HTTP or HTTPS network reachability to a vulnerable TeamCity server, with no valid credentials, no session, and no user interaction required on the victim’s side [1][2]. The vulnerable code path lives in the agent polling protocol, the mechanism by which distributed build agents check in with the central TeamCity server to retrieve job assignments and configuration data. Because that protocol is designed to let many agents, potentially across different network segments, communicate with the server without requiring a full authentication handshake for every poll, it represents exactly the kind of internally trusted but externally reachable interface that deserialization flaws tend to exploit: a channel built for convenience between trusted components that was not hardened against the possibility of untrusted input arriving through it [2][3].
Successful exploitation grants the attacker code execution with the privileges of the TeamCity server process, which in most production deployments has meaningful access to source repositories, build configuration secrets, artifact storage, and deployment credentials used to push builds toward staging or production environments [3]. That access profile mirrors the outcome of the 2023 and 2024 authentication bypass incidents: once an attacker controls the build server, they control what is built, and by extension what downstream systems and customers ultimately receive. Unlike a compromised production application, where a breach might expose a defined dataset or set of endpoints, a compromised CI/CD server offers the attacker an ongoing capability to inject malicious code into every future build. This note’s analysis characterizes this as a shift in the enterprise’s meaningful trust boundary — away from the production perimeter and toward the build pipeline itself.
The absence of any reported active exploitation at the time of JetBrains’ advisory is a meaningfully different starting position than the 2023 incident, where APT29’s exploitation was already underway and detected before the joint advisory was issued [1][2][4]. That gives defenders a narrow but real window to patch ahead of exploitation, rather than responding to an active intrusion. However, that window should not be read as low urgency: proof-of-concept exploitation code for unauthenticated deserialization RCE vulnerabilities in widely deployed developer infrastructure tends to appear quickly once technical details circulate, and internet-exposed TeamCity servers, which internet-wide scanning research has repeatedly found numbering in the low thousands (Wiz Research documented approximately 2,200 internet-facing TeamCity instances via a Shodan search in 2024) [9], represent an attractive and easily enumerable target set for opportunistic scanning once the vulnerability class becomes public knowledge.
The timeline between private disclosure and public advisory is also worth examining for what it says about the exploitation window’s narrowness. Tremblay reported the vulnerability to JetBrains on July 10, 2026, and JetBrains published its advisory and patched versions seventeen days later, on July 27 [2]. That interval reflects a coordinated disclosure process working roughly as intended: enough time for the vendor to develop, test, and stage a fix across multiple supported branches, while short enough to limit the period during which a working exploit chain existed in the hands of a party operating under a defined disclosure agreement. The corresponding risk is that reverse-engineering a patch to recover exploitation detail is now a well-understood exercise for the security research and threat actor communities alike, particularly for deserialization flaws, where diffing the patched and unpatched code paths often reveals the specific classes and validation logic that make exploitation possible. Organizations should not assume that the absence of a public proof-of-concept at the time of this note’s publication will persist, and should treat the current period as the most favorable point at which to patch relative to attacker capability.
It is also worth noting what JetBrains’ advisory does not say. The company has not published a detailed technical breakdown of the specific deserialization gadget chain or the exact request format that triggers it, which is consistent with responsible disclosure norms for an unpatched-at-scale vulnerability but means that defenders evaluating their own exposure are currently working from the vulnerability class and affected component rather than a full proof-of-concept. That asymmetry favors patching over building bespoke detection signatures in the near term, since detection rules written against an incomplete understanding of the exploitation mechanics risk both false negatives against variant payloads and false confidence that a server is adequately monitored when it remains fundamentally unpatched.
Recommendations
Immediate Actions
Organizations running TeamCity On-Premises should identify every instance in their environment, confirm its current version, and upgrade to 2026.1.3 (for the 2026.x branch) or 2025.11.7 (for the 2025.11.x branch) as the primary remediation path [2]. For servers where an immediate full upgrade is not operationally feasible, JetBrains has published a security patch plugin, available for TeamCity 2017.1 and later, that addresses the vulnerability without requiring a full version migration; the plugin auto-downloads for servers on 2024.03 and later, is hot-deployable without a restart from version 2018.2 onward, and requires a server restart on versions between 2017.1 and 2018.1 [2]. Security teams should also treat any internet-facing TeamCity server as a priority asset for this patch cycle, since the vulnerability requires only network reachability and no credentials, meaning exposure to the internet directly determines an organization’s practical attack surface for this issue. TeamCity Cloud customers do not need to take action, as JetBrains manages patching for that offering directly [2].
Short-Term Mitigations
Where patching must be sequenced across a large fleet of servers, organizations should restrict network access to the agent polling protocol endpoint to only the build agents that legitimately need it, using firewall rules, network segmentation, or a VPN requirement, rather than leaving the interface reachable from broader internal networks or the public internet [3]. Security teams should also review TeamCity server logs for anomalous or malformed requests to the agent polling endpoint predating the patch, since retroactive log review may surface earlier reconnaissance or exploitation attempts that were not recognized as significant before the vulnerability’s disclosure. Rotating credentials and secrets accessible to the TeamCity server process is a reasonable precaution for organizations that were running an internet-exposed, unpatched instance for any meaningful period, consistent with the pattern seen in comparable CI/CD compromises, including the 2023 TeamCity campaign discussed above, where credential theft has served as a first-stage objective rather than an end goal in itself.
Incident response teams should also prepare to distinguish exploitation of this specific vulnerability from general TeamCity server misbehavior, since the agent polling protocol is a normal and continuously active part of legitimate TeamCity operation, which makes anomaly detection here inherently noisier than for an endpoint that is rarely used. Establishing a baseline of expected agent check-in patterns, source IP ranges, and payload characteristics before the patch is applied, where feasible, gives defenders a reference point against which to evaluate whether logged activity predating remediation warrants deeper forensic review. Organizations with mature detection engineering capability should also consider whether their existing endpoint detection and response tooling on the TeamCity host itself would surface anomalous child process creation from the TeamCity server process, since that behavior is widely regarded by detection engineers as one of the more reliable generic indicators of successful exploitation for this class of deserialization RCE, independent of the specific payload used.
Strategic Considerations
CVE-2026-63077 is the third significant unauthenticated compromise vector disclosed in JetBrains TeamCity since 2023, following the APT29-exploited CVE-2023-42793 [4] and the subsequent CVE-2024-23917 authentication bypass [7], and that pattern warrants a standing risk posture rather than a series of one-off patch responses. Organizations that depend on TeamCity, or any CI/CD platform occupying a comparable position of trust, should treat build infrastructure as a Tier 0 asset subject to the same network isolation, monitoring, and least-privilege access controls applied to identity infrastructure and domain controllers, rather than managing it as conventional application infrastructure. Practically, that means minimizing direct internet exposure of CI/CD management and agent-communication interfaces, scoping the credentials available to the build server process as tightly as the pipeline’s actual needs allow, and building detection capability specifically for anomalous CI/CD server behavior rather than relying solely on controls designed for general-purpose application servers. CI/CD compromise has repeatedly served as the opening move in supply chain attacks with consequences far beyond the initially compromised organization, including in the 2023 TeamCity campaign discussed above, and this class of infrastructure merits recurring vulnerability management attention commensurate with its outsized blast radius.
CSA Resource Alignment
CVE-2026-63077 sits squarely within the threat and vulnerability management and application and interface security domains addressed by CSA’s AI Controls Matrix (AICM) v1.1. While TeamCity itself is not an AI system, the AICM’s threat and vulnerability management domain establishes control expectations, timely patch management, vulnerability disclosure handling, and secure configuration of build and deployment infrastructure, that map directly onto the remediation obligations this advisory creates. As organizations adopt AI-assisted coding and testing tooling atop CI/CD platforms like TeamCity, this note’s assessment is that the underlying pipeline’s security posture becomes directly relevant to the integrity of AI-generated build artifacts as well. Security and platform engineering teams evaluating their exposure to this vulnerability should use the AICM’s control structure to verify that patch management, network segmentation, and least-privilege access practices for build infrastructure are documented and enforced, not merely assumed.
CSA’s Zero Trust Guiding Principles are also directly applicable to the mitigation path this vulnerability recommends. The core Zero Trust principle that no component of infrastructure, including an internal-facing protocol like TeamCity’s agent polling channel, should be implicitly trusted based on its intended internal-only use case, is precisely the assumption that this vulnerability violates: a channel built for trusted agent-to-server communication proved reachable and exploitable without authentication. Organizations applying Zero Trust segmentation to their build infrastructure, rather than assuming internal network position confers safety, would have already reduced the practical exposure of the vulnerable endpoint regardless of patch timing, underscoring why CSA recommends extending Zero Trust architecture to developer and build tooling rather than reserving it for user-facing identity and access scenarios alone.
References
[1] The Hacker News. “Critical TeamCity Flaw Could Let Attackers Run OS Commands Without Logging In.” The Hacker News, July 2026.
[2] JetBrains. “Critical Security Issue Affecting TeamCity On-Premises (CVE-2026-63077) – Update to 2025.11.7 or 2026.1.3 Now.” The JetBrains Blog, July 27, 2026.
[3] IONIX. “CVE-2026-63077 – Unauthenticated RCE via Agent Polling Protocol – JetBrains TeamCity.” IONIX Threat Center, July 2026.
[4] CISA. “Russian Foreign Intelligence Service (SVR) Exploiting JetBrains TeamCity CVE Globally.” Cybersecurity and Infrastructure Security Agency, December 2023.
[5] Cloud Security Alliance. “AI Controls Matrix (AICM) v1.1.” Cloud Security Alliance, 2026.
[6] Cloud Security Alliance. “Zero Trust Guiding Principles.” Cloud Security Alliance.
[7] JetBrains. “Critical Security Issue Affecting TeamCity On-Premises (CVE-2024-23917) – Update to 2023.11.3 Now.” The JetBrains Blog, February 2024.
[8] Arctic Wolf. “CVE-2024-23917: Critical Vulnerability Affecting On-Premises Servers of TeamCity.” Arctic Wolf, February 2024.
[9] Wiz. “TeamCity Authentication Bypass Vulnerabilities: An Analysis (CVE-2024-27198, CVE-2024-27199).” Wiz Research, March 2024.