TeamCity CVE-2026-63077: patch the server that ships your code

JetBrains shipped an advisory on July 27 for CVE-2026-63077, an unauthenticated remote code execution bug that affects all versions of TeamCity On-Premises. No credentials, no user interaction — just HTTP access to the server. If you run a build server on your own hardware, this is the CVE that matters this week, because a CI server is the one box that legitimately holds every secret your business has.

What actually happened

Per JetBrains' advisory, an attacker with network access to a TeamCity server can abuse the agent polling protocol to bypass authentication and run arbitrary operating system commands as the TeamCity server process. Rapid7's analysis rates it CVSS 9.8 and classes it as deserialization of untrusted data.

The fixed builds are 2025.11.7 and 2026.1.3. If you can't take the upgrade this week, JetBrains ships a security patch plugin covering TeamCity 2017.1 and later, and it downloads automatically on 2024.03+. TeamCity Cloud is not affected — nothing to do there.

The bug was privately reported on July 10 by researcher Antoni Tremblay through coordinated disclosure, and JetBrains said it was not aware of active exploitation when the advisory went out. Treat that as a head start, not a verdict. TeamCity has been a named target in prior state-actor campaigns, and a published advisory is a map to the vulnerable code path.

Why it matters for your business

Most small businesses don't run TeamCity. Your dev agency or contract engineer does, and that server is where your deploy keys, cloud API tokens, database credentials, code-signing certificates, and full source history all sit in one place by design. Unauthenticated RCE on a build server isn't one compromised machine — it's the ability to push signed, "legitimate" code into your production environment.

Two concrete moves. If you own the server: patch to 2025.11.7 or 2026.1.3 today, then check whether its web interface is reachable from the public internet. A build server has no business being internet-facing; agents and developers can reach it over VPN. If someone else owns it, send them the CVE number and ask in writing what version they're on, when they'll patch, and whether the server is exposed.

Then assume the worst case and price it: if that server were owned, which credentials would you have to rotate, and do you have a list? Most teams don't, and building that inventory is a two-hour job that pays for itself the first time anything goes wrong.

Sources: JetBrains, Rapid7.