CVE-2026-63077 is a deserialization of untrusted data vulnerability in JetBrains TeamCity. CISA added it to the Known Exploited Vulnerabilities catalogue on 5 August 2026, which means attackers have used it in real attacks. JetBrains TeamCity contains a deserialization of untrusted data vulnerability that could allow unauthenticated remote code execution via the agent polling protocol.
How this TeamCity vulnerability works
CVE-2026-63077 is a deserialization flaw, which means TeamCity can be induced to interpret attacker-controlled data as executable object state. In practical terms, that turns a parsing step into a code execution path, and the risk is especially severe when the affected service accepts unauthenticated input.
Because the weakness sits in the agent polling protocol, exposure is not just about the application front end. It is about any reachable TeamCity instance that can process that protocol traffic, especially where build infrastructure is internet-facing or reachable from less trusted networks.
Why unauthenticated deserialization is dangerous
Deserialization bugs are dangerous because the application trusts structure and metadata before it has established that the data is safe. When the input is untrusted and no authentication barrier is required, an attacker may be able to reach the vulnerable code path directly and turn a malformed request into remote code execution.
This pattern is particularly harmful in CI and build systems because successful exploitation can put an attacker near source code, build artifacts, deployment credentials and other high-value development assets. A compromised TeamCity server can therefore become a launch point for broader supply-chain abuse rather than a single isolated server issue. For background on how exploited vulnerabilities are tracked and prioritized, see the CVE Program and the NIST National Vulnerability Database.
How organisations assess exposure and reduce blast radius
The first question is whether any TeamCity instances exist, where they are hosted, and whether the agent polling protocol is reachable from the internet or other untrusted segments. That inventory step matters because exploitable exposure depends on the combination of vulnerable software, reachable service surface and current configuration.
Where patching is delayed, reduce reachability as much as possible, restrict access to management and agent traffic, and treat the TeamCity host as a high-value asset until the vulnerability is removed. The practical goal is to make unauthenticated protocol reachability harder while you validate the vendor fix and confirm that no exposed instance remains in service.
For remediation planning, rely on the vendor advisory for version and fix guidance, and use the NIST Cybersecurity Framework 2.0 to organise identify, protect and recover work around the affected platform.
Detection, compromise review, and identity impact
After patching, review whether the host was already abused before the fix was applied. For a deserialization RCE in a build system, that review should focus on unexpected processes, abnormal agent activity, new files or services, altered build definitions, and outbound connections that do not fit normal TeamCity behaviour.
If exploitation is suspected, assume the attacker may have touched credentials, tokens, signing material or service accounts used by the build platform. That means the response is not limited to the application binary itself, it also includes rotating secrets, invalidating sessions where relevant, and checking for lateral movement from the build server into adjacent systems.
For control mapping, NIST SP 800-53 Rev 5 Security and Privacy Controls gives the most direct control-language for authenticated access, system integrity and audit review, while MITRE ATT&CK Enterprise Matrix is useful for mapping the post-exploitation behaviours that often follow remote code execution.
Risk and Threat Considerations
This vulnerability combines two high-risk properties, unauthenticated reachability and code execution in a system that often holds privileged build data. That makes it attractive for opportunistic exploitation, initial footholds and supply-chain intrusion.
Failure mechanism: The server accepts attacker-influenced serialized data and processes it before trust has been established, allowing the attacker to reach dangerous object construction or execution paths.
Impact: An attacker may execute code on the TeamCity server, steal build credentials or signing material, tamper with pipelines, and use the system as a pivot into development and deployment environments.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | TeamCity exploitation can expose credentials and sessions. |
| AU-6 — Audit Review, Analysis, and Reporting | Post-exploit review depends on logs and event analysis. | |
| SI-3 — Malicious Code Protection | RCE scenarios require hardening against malicious payload execution. | |
| Recommendation — Rotate exposed credentials and invalidate affected authenticators after suspected compromise. Review TeamCity and host logs for exploit traces and lateral movement. Monitor for anomalous process execution and payload staging on the build server. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | This CVE requires asset discovery, exposure checking and remediation prioritisation. |
| CIS-8 — Audit Log Management | Detection and compromise review depend on usable logs. | |
| Recommendation — Inventory TeamCity instances and prioritise remediation using vulnerability and exposure data. Centralise and review TeamCity and host logs for pre- and post-patch compromise evidence. | ||
Practitioner Guidance
Why practitioners should care: Treat TeamCity as part of your production attack surface, not just a developer utility. A build-system compromise can affect release integrity, secret custody and downstream systems at the same time.
What to watch for: Prioritise instances that are internet-facing, agent-exposed, or operationally difficult to take down, because those are the environments where exploitation and persistence tend to be hardest to notice.
Practitioner takeaway: Validate the vendor fix, confirm no exposed instance is left behind, and assume credential rotation and compromise review are required if you cannot prove the system was untouched.
Related resources from NHI Mgmt Group
- CVE-2026-20131 (Cisco Secure Firewall Management Center (FMC) Software and Cisco Security Cloud Control (SCC) Firewall Management Deserialization of Untrusted Data)
- CVE-2021-23758 (Ajax.NET Professional Deserialization of Untrusted Data)
- CVE-2023-21529 (Microsoft Exchange Server Deserialization of Untrusted Data)
- CVE-2025-26399 (SolarWinds Web Help Desk Deserialization of Untrusted Data)