TeamCity CVE-2026-63077: Patch the Build Server, Then Rotate What It Was Holding
On 27 July, JetBrains published an advisory for CVE-2026-63077, an authentication bypass in TeamCity On-Premises that lets an unauthenticated attacker with HTTP(S) access to the server run arbitrary operating system commands. It is rated CVSS 9.8 and affects all On-Premises versions. Fixes landed in 2025.11.7 and 2026.1.3, with a security patch plugin for teams that cannot upgrade immediately. TeamCity Cloud customers need do nothing.
The detail that should shape your response is in the timeline, not the score. The flaw was reported privately on 10 July by Antoni Tremblay under coordinated disclosure, and JetBrains said it was not aware of active exploitation when the advisory went out. You are, for once, ahead of the attackers rather than behind them.
Why a build server is not just another internal app
Ask what a compromised TeamCity server would actually give someone. Not “access to a CI tool” — the honest inventory is usually worse than that: deployment credentials for production, cloud provider keys, container registry tokens, signing keys, database passwords in build parameters, and source for everything it builds. JetBrains' own advisory notes that a successful attack can expose TeamCity data, configuration and stored credentials, or manipulate server state.
Build systems also sit in an awkward trust position. They are frequently reachable from more of the network than a production database, because developers need them. They hold the credentials that production trusts. And they are permitted to change what runs in production, which means a compromise there is not only a data-exposure problem but a supply-chain one.
Work out your exposure first
- Confirm the deployment model. On-Premises is affected; Cloud is not. Do not infer this from a licence — check where the server actually runs.
- Map who can reach the web interface. Internet exposure is the obvious case and the rarest. VPN users, CI runners on shared segments, contractor networks and any compromised internal host all count as HTTP access.
- Enumerate what the server holds. Connections, secure build parameters, SSH keys, tokens for version control and artefact storage. This list is the rotation scope in the next section, and it is nearly always longer than people expect.
- Check version, not vibes. Fixed builds are 2025.11.7 and 2026.1.3. Anything older is affected regardless of how recently it was installed.
What to do this week
- Upgrade, or apply the patch plugin. The plugin exists precisely for teams whose upgrade window is weeks away. Taking it does not remove the need to schedule the upgrade.
- Restrict reachability while you do. Limit the web interface to administrative networks. This narrows the window; it does not close the hole.
- Rotate on a calm schedule, not a panicked one. With no known exploitation, you can rotate deployment credentials, registry tokens and signing keys deliberately, testing each one, rather than during an incident. Teams that skip this step are betting that nobody found the bug independently between 10 and 27 July.
- Review administrative activity and build history. Look for unexpected configuration changes, new administrative users, altered build steps and unfamiliar outbound connections from the server.
- Decide what “clean” means before you declare it. A version bump proves the door is shut. It says nothing about whether anyone walked through it earlier.
The structural question worth asking afterwards
Once the immediate work is done, the useful follow-up is not about TeamCity. It is: which single systems in our estate hold enough credentials that compromising one would compromise most of the others? Build servers, secret managers, identity providers and orchestrators all tend to answer yes. Reducing what any one of them can reach is slower work than patching, but it is the thing that changes the size of the next incident rather than the timing of it.
A related habit is worth forming while credentials are on your mind: when a secret does have to move between people — a rotated database password handed to a colleague, a key sent to a contractor — a chat message or an email leaves a copy in places neither party controls. That is a separate problem from this CVE, but the same week is a reasonable time to notice it.