- What: CISA added JetBrains TeamCity CVE-2026-63077, a CVSS 9.8 untrusted-deserialization bug in the agent polling protocol, to the Known Exploited Vulnerabilities catalog on August 6, 2026.
- Impact: An unauthenticated attacker who can reach the server bypasses authentication and runs arbitrary OS commands as the TeamCity server process, exposing stored credentials, configurations, and the integrity of every build artifact downstream.
- Fix / mitigation: Apply JetBrains' patched on-premise TeamCity release immediately and, until then, block untrusted network access to the agent polling endpoint.
- Who's at risk: Any organization running on-premise TeamCity, especially instances exposed to the internet; TeamCity Cloud is not in scope, and FCEB agencies were bound to the August 8, 2026 deadline under BOD 26-04.
CISA added CVE-2026-63077 to the Known Exploited Vulnerabilities catalog on August 6, 2026, confirming that attackers are already exploiting a CVSS 9.8 deserialization flaw in on-premise JetBrains TeamCity. The bug requires no credentials. An attacker who can reach the TeamCity server over the network bypasses authentication checks entirely and executes arbitrary operating system commands with the privileges of the server process.
Federal Civilian Executive Branch agencies had two days. Under Binding Operational Directive 26-04, the remediation deadline for CVE-2026-63077 was August 8, 2026. That is the shortest end of the KEV window and a reasonable signal of how CISA is weighting this one.
What the vulnerability is
CVE-2026-63077 is a deserialization of untrusted data flaw reachable through the TeamCity agent polling protocol. That protocol is the channel build agents use to check in with the server for work. It is, by design, a listening service that accepts input from machines outside the web UI's authentication path, which is exactly why the authentication bypass matters here.
In CISA's wording, TeamCity "contains a deserialization of untrusted data vulnerability that could allow unauthenticated remote code execution via the agent polling protocol." JetBrains describes the same chain: an unauthenticated attacker uses the polling protocol to sidestep authentication checks and execute arbitrary OS commands. There is no user interaction step, no privilege prerequisite, and no second-stage requirement. That combination is what produces the 9.8.
The precise blast radius depends on how the TeamCity server process is running. If it runs as root or as a local administrator, which is common in installations that were stood up quickly and never revisited, code execution as that process is code execution as the host.
Why a build server is the wrong thing to lose
TeamCity is a CI/CD orchestrator. Compromising it is not equivalent to compromising an application server. Per JetBrains, a successful attack can expose TeamCity data, configurations, and stored credentials, modify server state, and compromise the integrity of build artifacts and downstream pipelines.
Unpack the credential exposure specifically. A production TeamCity instance typically holds VCS tokens with write access to source repositories, cloud provider keys used by deployment steps, container registry push credentials, artifact repository tokens, and code signing material. An attacker with server-process code execution reads those out of the configuration store and immediately holds authenticated access to systems that never saw an attack against themselves.
Artifact integrity is the second-order problem. An attacker who can modify build configurations can inject code into artifacts that are then signed, published, and consumed by every downstream system that trusts the pipeline. That is a supply chain compromise that looks like a normal release to everyone consuming it. Detection depends on comparing what the build produced against what the source actually says, which most organizations cannot do retroactively.
If your TeamCity server was internet-reachable and unpatched, patching does not undo the exposure. Every secret stored in or accessible to that instance should be treated as compromised: VCS tokens, cloud keys, registry credentials, signing keys, and service accounts. Rotate them, then review artifacts built during the exposure window against source.
What is not known
Be precise about the gaps, because they change how you prioritize. As of CISA's KEV addition, the exploitation method in the wild has not been published, the threat actors behind the attacks have not been identified, and the scale of the campaign is unknown. JetBrains had not updated its advisory to confirm active exploitation at the time of CISA's listing.
None of that is a reason to wait. Historically, TeamCity authentication bypasses have gone from KEV listing to broad opportunistic scanning fast, and the profile here favors mass exploitation: a single unauthenticated network request against a service that is frequently exposed because remote build agents need to reach it.
Immediate actions
- Patch on-premise TeamCity to the fixed release from JetBrains now. This is the only complete remediation. TeamCity Cloud instances are not affected by the on-premise advisory.
- If you cannot patch within hours, remove the server from internet exposure. The agent polling endpoint should be reachable only from known build agent addresses, enforced at the network layer rather than in application configuration.
- Inventory your exposure honestly. Check for TeamCity listeners on 8111/TCP and any reverse proxy that fronts the server, including instances stood up by individual engineering teams outside the central asset list. Shadow build servers are the common failure here.
- Rotate every credential stored in TeamCity if the instance was exposed and unpatched at any point since disclosure. Prioritize anything with write access to source control, cloud infrastructure, or artifact registries.
- Review server logs for anomalous agent polling requests, unexpected build configuration changes, new or modified build steps, and administrative account creation. Deserialization exploitation often leaves malformed request artifacts before it leaves anything else.
- Compare recently published artifacts against source. Focus on the window between disclosure and patch, and on anything signed or pushed to a registry that downstream consumers trust.
Hardening beyond the patch
This CVE is a reminder that CI/CD servers are usually the least segmented high-value asset in an environment. They need network reachability to source control, cloud accounts, registries, and production deploy targets, so they accumulate the union of everyone's privileges while sitting on a general-purpose network.
Two structural changes reduce the cost of the next TeamCity RCE. First, run the server process as a dedicated unprivileged account, not root or local administrator, so process-level code execution is not host-level code execution. Second, move away from long-lived static secrets in the build server toward short-lived credentials issued per build through OIDC federation, so a credential dump has a usable lifetime measured in minutes.
CISA's KEV listing is public. Attackers read it too, and a KEV entry for an unauthenticated pre-auth RCE reliably precedes an uptick in internet-wide scanning for that service. The window between listing and mass exploitation attempts is typically measured in days, not weeks.
Bottom line
CVE-2026-63077 is a pre-authentication remote code execution flaw in a system that holds the keys to your software supply chain. CVSS 9.8, no credentials, confirmed exploitation, and a two-day federal remediation deadline. If you run on-premise TeamCity, patch today and rotate what that server was holding.
Questions about your exposure?
RedEye Security provides assessments for organizations that need to understand their real risk.
Talk to us