TeamCity is a build server: the thing that pulls your code, compiles it, runs your tests and hands the result to whatever ships it. CVE-2026-63077 sits in the protocol TeamCity build agents use to poll the server for work - a deserialization-of-untrusted-data flaw that lets an attacker with plain HTTP or HTTPS access skip authentication entirely and execute arbitrary commands with the server process's own privileges. JetBrains' advisory credits the report to researcher Antoni Tremblay, who disclosed it privately on 10 July under the company's coordinated disclosure process. It affects every version of TeamCity On-Premises; TeamCity Cloud is not affected, and JetBrains says it has seen no evidence of exploitation there either.
A patch that shipped with a clean bill of health
What makes this one worth a second look isn't the CVSS score - 9.8 is a familiar number by now - it's the sequence. JetBrains shipped fixes in TeamCity 2025.11.7 and 2026.1.3 on 27 July, plus a narrower security patch plugin for anyone still running 2017.1 or later who can't upgrade immediately, and its advisory stated plainly that it wasn't aware of active exploitation at time of publication. That's a normal, honest thing for a vendor to say - it reflects what they can see, not a guarantee about what's happening on servers they don't operate. Rapid7's analysis, published two days later, treated the flaw as one to prioritise regardless, recommending network-level restriction of TeamCity server access as a defence-in-depth measure on top of patching.
What changed by 5 August
Nine days after the patch shipped, CISA added CVE-2026-63077 to its Known Exploited Vulnerabilities catalog, meaning it now has direct evidence of exploitation JetBrains didn't have at disclosure. Under Binding Operational Directive 26-04, that starts a clock: federal civilian agencies have until 8 August to patch or mitigate, a three-day window that puts this alongside the run of critical, actively-exploited flaws CISA has pushed through the KEV catalog this summer - the N-able N-central bypass among them. The gap between "no evidence yet" and "confirmed exploitation" was just over a week. For a build server sitting on the internet, that's not a long time to stay exposed on the strength of a vendor's honest but necessarily incomplete visibility.
Why a build server is worth more than it looks
A compromised TeamCity instance isn't just one more box on the network. It holds credentials for every system it deploys to, it can see and modify the artifacts it builds, and it sits upstream of whatever those artifacts become - which is precisely the shape of risk this site has flagged before with the unauthenticated MCP bridge in Ruflo: a single exposed control-plane service that, once popped, gives an attacker a foothold with reach far beyond the box itself. Rapid7's own read on the impact - stolen credentials, tampered build state, malicious code inserted into whatever ships downstream - is the standard playbook for a supply-chain compromise that starts at the build server rather than the code repository.
- Upgrade to TeamCity 2025.11.7 or 2026.1.3 immediately, or apply the security patch plugin if you're on 2017.1+ and can't upgrade today - the plugin covers only this CVE, so plan the full upgrade regardless.
- Confirm no TeamCity On-Premises server is reachable from the open internet; Rapid7's defence-in-depth advice to restrict network access applies whether or not you've patched yet.
- Audit build logs and configuration history for unexplained changes since 27 July, the date the flaw and its fix both became public knowledge.
- Rotate credentials stored in TeamCity if you can't rule out compromise with confidence - a build server holds the keys to everything it deploys.
- Don't wait for a vendor's "no evidence of exploitation" to become the whole story - CISA's KEV addition nine days later shows how quickly that status can change once attackers start actually looking.
None of the individual facts here are unusual - a critical CVE, a vendor patch, a later KEV addition. What's worth remembering is the shape: the honest version of "we haven't seen it exploited" is a snapshot, not a forecast, and the CI/CD layer is exactly the kind of infrastructure that rewards attackers for finding what a vendor's telemetry missed. If you want a second opinion on how exposed your build and deployment pipeline actually is, email sales@halfteck.com.