Does your organisation run JetBrains TeamCity to build and deploy its own software? This week’s news deserves more than a glance. A critical TeamCity remote code execution flaw is now being actively exploited. CISA has told US federal agencies to fix it within three days. Here is what UK businesses running TeamCity should check, in order, today.
Table of Contents
What the TeamCity remote code execution flaw actually does
The flaw is tracked as CVE-2026-63077. It sits in TeamCity’s agent polling protocol, the channel build agents use to check in with the central server. It carries a CVSS score of 9.8, the top severity score you can get. That’s because an attacker needs no username or password at all. Anyone who can reach an unpatched server over HTTP or HTTPS can skip those checks. From there, they can run system commands with the server’s own rights.
Security researcher Antoni Tremblay reported the issue privately to JetBrains on 10 July 2026. JetBrains patched it in versions 2025.11.7 and 2026.1.3. The company published its advisory around 27 July. Within days, CISA added the flaw to its Known Exploited Vulnerabilities catalog, having seen it used in real attacks. Federal agencies now have until 8 August to act. That’s a fast jump from private report to real attacks. It’s why this TeamCity remote code execution flaw deserves a same-day check, not a slot in next sprint’s backlog.
Step 1: Confirm your version
Every on-premises release of TeamCity before versions 2025.11.7 and 2026.1.3 is affected. TeamCity Cloud is not affected. So if you use the hosted service, this particular issue does not apply to you.
Log into your TeamCity admin panel. Check the version number against those two fixed releases. If you are running anything older, treat this as urgent, whatever your server setup looks like.
Step 2: Patch or apply the plugin
JetBrains has already shipped the fix. Teams on a current release should upgrade straight to 2025.11.7 or 2026.1.3. Those on older installations, back to version 2017.1, can install the security patch plugin JetBrains released with its advisory instead of a full upgrade.
If your server already runs version 2024.03 or later, the patch may have downloaded on its own. Check your dashboard for an admin alert before you assume you are still exposed. If patch management for internal build tooling isn’t already on a fixed schedule, put it on one now.
Step 3: Check your exposure, not just your version
The flaw needs no login, so the real question is who can reach your TeamCity server over HTTP or HTTPS. Does it sit on the open internet with no IP allowlisting or VPN requirement? If so, treat this as an emergency, not routine patching. Anyone scanning for exposed TeamCity instances can find it within minutes.
Review your firewall rules even after you patch. JetBrains itself says to limit network access to TeamCity servers as a standing rule, not a one-off fix for this bug. A server that only accepts connections from your office network or VPN removes most of the risk here, even before a patch lands.
Don’t forget agents that connect back to the server, either. Some build agents run outside your own network, on a contractor’s laptop or a third-party runner. Confirm each one points at a patched TeamCity server before it checks in again.
Step 4: Look for signs the TeamCity remote code execution flaw already hit you
The flaw lets an attacker run commands with the server’s own privileges. So a break-in could touch build logs, stored passwords and artifact stores. Review recent build history for jobs you don’t recognise. Look for odd setup changes, too, or credentials used outside their normal pattern.
Does TeamCity store secrets for other systems, such as cloud deployment keys or source control tokens? Rotate them once the server is patched. A quiet hack on a build server can last far longer than one on a customer-facing app, simply because fewer people watch it closely.
Check for build steps that were added, edited or reordered with no change request behind them. An attacker with server-level access can insert a step that runs once, steals a secret, and removes itself straight after. A quick check against your last known-good setup is worth the ten minutes it takes.
Step 5: Harden the server for next time
This TeamCity remote code execution flaw won’t be the last serious bug found in build automation software. Run the TeamCity process with the fewest OS rights it needs, not a full admin account. Keep the server off the public internet wherever your workflow allows. Put monitoring on it that matches what you already apply to production systems.
Set a reminder to check for TeamCity updates monthly, rather than waiting for the next headline. Most teams patch customer-facing software far faster than internal build tools. That’s usually because no one owns the decision. Assign someone the job now, while this incident is still fresh in mind.
Why this matters beyond TeamCity
Build tools sit closer to your code and secrets than almost anything else you run. Yet they rarely get the same patch discipline as a public website or an email server. A build server that trusts every request from inside the network, with no further checks, is the soft target attackers want most.
Treat this TeamCity remote code execution incident as a prompt to check patch speed across your whole CI/CD toolchain, not just the one tool in this week’s news. Has your build setup ever had an internal network penetration test? If not, book one now, alongside your usual app tests, not instead of them.
Subscribe to our newsletter
Honest updates, straight to your inbox. Unsubscribe any time.
