Your CI/CD holds the keys to production. And you treat it as a developer tool

On 27 July JetBrains published a short advisory about TeamCity On-Premises. A 9.8. Unauthenticated. Every version. An attacker with HTTP access to the server runs operating system commands and the conversation is over. The flaw is patched in an afternoon; the harder part is accepting where it landed. On the machine that holds the credentials to write to the rest of your servers and that also signs and ships what your customers end up running. At that point a compromise stops being an access problem and becomes an integrity one: it is not that they got in, it is that from then on you do not know what you shipped. And that machine almost never shows up in anybody's critical systems inventory. We do not have a survey to quantify that. We have the servers we have seen.

CVE-2026-63077, on one screen

Before any opinion, the facts as the vendor published them. No decoration and no use of the word "catastrophic", which adds nothing:

It was reported privately on 10 July by researcher Antoni Tremblay, JetBrains published it on the 27th, and Rapid7 shipped detection content the next day asking customers to prioritise it urgently. Seventeen days between the private report and the public advisory: that is coordinated disclosure done properly, and it is worth saying so when it happens.

The sentence worth reading twice is the vendor's own, on impact: a successful attack could "expose TeamCity data, configurations, and stored credentials, modify server state, and potentially compromise the integrity of build artifacts and downstream CI/CD pipelines". That is this whole article, summarised by JetBrains: stored credentials, artifact integrity, downstream pipelines.

What expires first: "no known exploitation" or your maintenance window

That line in an advisory is what parks a CVE in the "we will do it in September" list. With TeamCity specifically, the record does not allow that luxury, and these are two episodes documented by government agencies and incident responders, not forum rumours.

• CVE-2023-42793 (also a 9.8, also an authentication bypass, fixed in 2023.05.4). On 13 December 2023, CISA, the FBI, the NSA, Poland's military counterintelligence service, CERT.PL and the UK's NCSC co-signed an advisory: actors of Russia's SVR — APT29, Cozy Bear, Midnight Blizzard, the same group with many names — had been using it since September 2023 to get in, escalate privileges, move laterally, drop backdoors and stay. At scale, with technology companies as the preferred target.
• CVE-2024-27198, another 9.8 authentication bypass, published on 4 March 2024 alongside CVE-2024-27199. That same month GuidePoint documented BianLian ransomware operators getting in through TeamCity, creating users in the product itself and running commands under its service account. Their analysts recorded that they could not tell whether entry was via CVE-2024-27198 or the earlier CVE-2023-42793, because the logs they needed were gone: a detail that says a fair amount about how much gets kept of what happens on a build server. The same 2024 hole later carried, according to Trend Micro, Jasmin ransomware, XMRig miners and SparkRAT backdoors.

To be fair to the argument: this does not prove CVE-2026-63077 will be exploited. Perhaps nothing happens. What the record says is something more modest and more useful: when an authentication bypass with remote execution shows up in an exposed build server, the gap between advisory and first incident has previously been measured in weeks, not quarters. Given that precedent, leaving it for September's maintenance window is a decision somebody signs off. Let it be signed off knowing what is being signed off.

Why a build server is such a good target

Think about what is inside your company's CI/CD right now. Not in theory: open the variables screen and look. There is usually an SSH key that logs into production servers, a container registry token with write permission, database credentials for migrations, a cloud provider API token, the artifact signing material and, if you are lucky, some customer secret somebody added "temporarily" two years ago.

Now add the second property, the one that makes it special: a CI/CD server runs arbitrary code as its primary function. A build agent is, literally, authorised remote execution. There is no "safe mode" to switch on, because executing is the product. So whoever gets into the build server does not need to move laterally anywhere: they are already on the one machine in the house with permission to write to all the others, and anything odd they do will look a lot like a deployment.

The third ingredient is not fixed by any version, and it is the one that really hurts: it is governance. The CI/CD belongs to nobody. Development set it up years ago because it was needed yesterday. Ops maintains it when it breaks. Nobody audits it. It lives in the mental inventory of "tools", next to Jira and the wiki, while the domain controller — which has less power over what gets published — does make the short list. The same thing happened to us with exposed BMC and IPMI, except that stopped at the machine's boot; this reaches the binary your customer downloads.

What you cannot restore: the integrity of what you already shipped

This is where this plane parts company with all the others, and it is why we gave it an article. If somebody gets into your firewall, you review rules, rotate keys and move on. If somebody gets into your build server, the damage travels forward in time and outward from your company: every artifact built since then is suspect, and you no longer hold it, your customers do. That is why JetBrains does not only talk about stolen credentials and expressly mentions the integrity of build artifacts and downstream pipelines.

The practical consequence is uncomfortable: restoring a backup of the server does not fix this. The backup gives you the machine back; it does not give you back the version your customer downloaded on 14 July. After an incident like that, the question that decides the cost is not "when did we close the hole?" but "since when have we been shipping, and to whom". And that one is answered by your build records and the hashes you kept — or it is not answered at all. We have not lived through this in a Spanish SME, and we are not going to pretend otherwise; the two documented episodes are the ones above. But the mechanism is the same and it does not depend on company size.

And to be clear: the problem is not TeamCity

It would be very comfortable to close by saying TeamCity is unlucky. That is not it. JetBrains signed this advisory because this time it was JetBrains' turn; the whole category shares the same design and therefore the same risk. Self-hosted build servers, deployment orchestrators, runners inside your network: they all execute code by definition and they all hold the keys to production. If you are thinking "we do not use TeamCity", the question that matters is who can reach the one you do use over HTTP.

What we would do this week

Six things, in order. The first three are what the vendor itself recommends — it also asks you to run the server on a dedicated host, separate from build agents; the other three are our own judgement and take real work, so we are not pretending they happen on Tuesday.

1. Upgrade to 2025.11.7 or 2026.1.3. If you cannot touch the version today, JetBrains ships a patch plugin valid from 2017.1. Careful with this one: on 2024.03 and later branches TeamCity downloads the plugin by itself and notifies administrators if notifications are configured, but you still have to go to Administration | Updates, under "Available security updates", and apply it by hand. Downloading is not installing. Between 2017.1 and 2018.1 the server needs a restart; from 2018.2 onwards it does not.
2. Take it off the internet. The advisory is firm about the first part and careful about the second: limit access to trusted networks wherever you can and, if the server faces the internet, consider requiring VPN or an additional security layer. And it adds a line that deserves a poster on the wall: even exposing the TeamCity login screen or REST API can provide attackers with potential entry points to exploit newly disclosed vulnerabilities. A published login form is already attack surface, however it is painted on the diagram as "restricted access".
3. Check what privileges the process runs with. The flaw executes commands "with the privileges of the TeamCity server process". Translated: if your service starts as root or as SYSTEM because one day that was quickest, the 9.8 turns into a round ten. Dropping it to a dedicated service account is an afternoon's work and it changes how an incident ends.
4. Add it to the inventory, today. Not the tools inventory: the critical systems one, with an owner, a patching window, and monitoring that fires if somebody creates an admin user on a Sunday. If the build server has no name attached to it, the next advisory will slip past you too.
5. Separate what builds from what deploys. The agent that builds third-party code and the one holding the production key should not be the same, and certainly should not share long-lived credentials. Ephemeral agents that are born and die with the job, short-lived secrets, and write access to production in a single auditable place. It is more work, yes. It is also the difference between a scare and a rebuild.
6. Write down what you would do if it had been taken. One page. Which credentials are inside, in what order they get rotated, who tells which customer, and how you verify that the artifacts published in recent weeks are the ones you thought. If that page does not exist, on the day you need it you will improvise at three in the morning.

On the sixth point it is worth being explicit, because it is the one most often skipped: patching is not cleaning. Updating closes the door; it does not undo what came in before it was closed, nor expire credentials that were already read. We wrote about this recently over the symlinks that survived the patch in FortiOS and it applies here too: if your build server has been published on the internet for months, updating the version and calling it done tells half the story.

How we run ours (and what we do not sell)

Time to declare an interest. We run our own container platform in production — Docker Swarm with Portainer and Traefik — and we deploy with GitOps CI/CD on GitLab, so this article is written by people who also have a machine that, if someone takes it, takes the deployment with it. We do not use TeamCity and we are not resellers of any CI/CD or virtualisation platform: we recommend on the merits, not on the commission, and that is precisely what lets us say "do not deploy that" without it costing us money.

The discipline we do defend is boring, and we told it in full when we explained why "latest" is not a version: reproducible, reversible deployments carrying the exact tag that was pushed, so that "what was running on Tuesday at six?" has an answer rather than a guess. That traceability, built with your own mistakes in mind, turns out to be what saves you the day the question comes from a forensic analyst. And the part about who reaches the panel is, underneath, a problem of identity and least privilege: it is Zero Trust applied to a management plane, and it comes before any cybersecurity product you can buy on top.

The question this 9.8 leaves behind

Most security plans we see protect where the data is very well: backups, encryption, permissions, retention. Far fewer protect who can change the code that touches that data, which is a much shorter and considerably quieter route. An attacker does not need to get into your database if they can modify the application that already has permission to read it.

So the question is not "are we patched?". It is this: if somebody takes the machine that deploys, what do they take with it, how long until anyone notices, and who notices? If today that answer is a shrug, you know what this week is for. And if you would rather we looked at it with you — the inventory, who reaches what, and which credentials are inside — drop us a line. No product to place.

Sources (verified on 3 August 2026): the vulnerability details come from JetBrains' security advisory of 27 July 2026 (affected and fixed versions, the patch plugin from 2017.1 and its behaviour per branch, TeamCity Cloud not affected, no known exploitation, the network, least-privilege and dedicated-host recommendations, the warning that even exposing the login screen or REST API can provide potential entry points, and credit to Antoni Tremblay for the 10 July report), from Rapid7's analysis (CVSS 9.8, deserialization of untrusted data over the agent polling protocol, and the call to prioritise it urgently) and from the coverage in The Hacker News and Help Net Security, where we took JetBrains' verbatim impact quote and the warning about the login screen and the REST API. The history: the joint advisory AA23-347A from CISA, the FBI, the NSA, SKW, CERT.PL and the NCSC of 13 December 2023 on CVE-2023-42793 and the attribution to Russia's SVR since September 2023, and GuidePoint Security's research of March 2024 on BianLian, including their own analysts' caveat that they could not tell whether entry was via CVE-2024-27198 or the earlier CVE-2023-42793 because the logs were gone. The later chain on CVE-2024-27198 — Jasmin ransomware, XMRig miners and SparkRAT backdoors — was documented by Trend Micro, not GuidePoint. The CISA advisory is served behind an anti-bot check; the same document sits on the FBI mirror. Ours, not our sources': that the underlying problem is governance rather than product, that a CI/CD server is authorised remote execution by design, the list of six measures and their order, the separation between agents that build and agents that deploy, and the reading that the record does not predict exploitation but does shorten the reasonable window to patch. We have not counted how many TeamCity servers are exposed on the internet, nor how many companies keep their CI/CD out of the inventory, and we are not going to invent it. Cover photo: "Worker assembles metal parts in factory" by Nenad Stojković (Shixart1985), Wikimedia Commons, CC BY 2.0.