An authentication bypass in the tool that builds your software
JetBrains disclosed CVE-2026-63077, a critical vulnerability in TeamCity On-Premises, its widely used continuous integration and delivery server. The company's advisory describes a flaw that lets an unauthenticated attacker with network access to a TeamCity server bypass its authentication checks entirely and execute arbitrary operating system commands with the privileges of the TeamCity server process. That is about as severe an outcome as a single vulnerability can produce, since it skips credential theft altogether and goes straight to command execution. There is no phishing step, no password to guess, and no second factor to defeat, just a crafted request against a server that many enterprises expose to their internal network far more broadly than they realize.
The advisory affects every version of TeamCity On-Premises, which covers the self-hosted deployments that most enterprises run behind their own firewalls precisely because they want direct control over their build infrastructure. JetBrains has shipped fixed versions, 2025.11.7 and 2026.1.3, along with a security patch plugin that extends protection back to version 2017.1 for teams that cannot immediately move to a current release. TeamCity Cloud customers are not affected, since JetBrains manages authentication for the hosted product directly and the exposure is specific to the on-premises deployment model that gives customers their own network perimeter to defend.
What an attacker actually gains
The practical consequence of this flaw is not abstract. Command execution at the TeamCity server process level gives an attacker a foothold with visibility into everything the build server touches: stored credentials for source repositories, deployment targets, artifact registries, and any secrets management integration the pipeline relies on. JetBrains' own advisory notes that exploitation could expose data, configurations, and credentials, and could compromise build artifacts and the CI/CD pipeline itself.
That last point is the one worth sitting with. A CI/CD server builds code and is also trusted to push the output of that build into staging and production environments, which makes it a rare piece of infrastructure with both the access and the credibility to move malicious output straight into a live release. An attacker who can tamper with build artifacts at the source has a path to inserting malicious code into software before it ever reaches a customer, a threat model that traditional endpoint detection tools were never designed to catch, since the compromised object looks exactly like a legitimate build.
No active exploitation yet, but the clock is not in your favor
JetBrains states that no active exploitation had been detected as of publication, which is a meaningfully different situation than the N-central and SonicWall vulnerabilities that were already under attack before disclosure this year. That gives defenders a real window to patch ahead of exploitation rather than racing to catch up with an ongoing intrusion, an increasingly rare position to be in given how many 2026 disclosures have arrived only after attackers were already inside. Security teams should treat that head start as the exception rather than the rule and move accordingly.
That window will not stay open long. Public disclosure of a critical, unauthenticated remote code execution flaw in a widely deployed product is historically followed by proof of concept code within days, and TeamCity On-Premises instances that are reachable from the internet or from a broad internal network are the most likely first targets. Teams that treat this as a routine patch cycle item rather than an emergency change are betting against a well established pattern in how quickly these flaws get weaponized.
Why CI/CD infrastructure keeps drawing this kind of attention
Build and deployment servers occupy a privileged position that many security programs still underprotect relative to production systems. They are internal tools, often managed by a platform or DevOps team rather than the security organization, and they are frequently granted broad credentials across source control, cloud infrastructure, and artifact storage because that access is what makes automated pipelines work in the first place. That arrangement gets built for convenience during a team's early growth and rarely gets revisited once the pipeline is running smoothly.
That combination, broad privilege plus comparatively light security scrutiny, is exactly what makes CI/CD servers attractive to attackers pursuing software supply chain compromise. The SolarWinds incident made this risk concrete for the entire industry several years ago, and the recurrence of critical vulnerabilities in mainstream build tools like TeamCity suggests the lesson has not fully translated into how these systems get hardened, segmented, and monitored on a day to day basis across most enterprise environments.
The patching math for enterprise DevOps teams
For organizations running TeamCity On-Premises, the immediate action is straightforward: upgrade to 2025.11.7 or 2026.1.3, or apply the security patch plugin if an immediate upgrade is not feasible. What is less straightforward, and more important, is auditing what the TeamCity server had access to during the exposure window, since a patch closes the vulnerability but does nothing to reverse anything an attacker may have already done with stolen credentials before the fix went in. That audit needs to happen even if the server has already been updated.
That audit should extend to rotating any credentials the TeamCity instance held for source repositories, deployment targets, and artifact registries, and reviewing build logs for anomalous activity around the disclosure date. Given that no active exploitation has been confirmed, most organizations likely have time to do this properly rather than in a rushed incident response mode, but that window narrows every day the patch is not applied, and the same window closes for any organization that assumes patching alone is sufficient without a credential and log review to match.
The broader pattern in 2026 disclosures
TeamCity joins a growing list of enterprise infrastructure tools, RMM platforms, VPN appliances, and now CI/CD servers, that have surfaced critical authentication bypass vulnerabilities this year. The common thread is that each of these categories sits in a privileged position relative to the rest of the environment, trusted precisely because it needs broad reach to do its job, which is exactly what makes a flaw in any one of them disproportionately damaging compared with an equivalent bug in a customer facing application. Attackers appear to have noticed the pattern well ahead of most enterprise security programs.
For CTOs building out a vulnerability management program, this argues for treating the infrastructure layer, the tools that build, deploy, monitor, and remotely manage everything else, as a distinct risk tier with faster patch SLAs and tighter network exposure limits than general enterprise software. TeamCity's advisory is a useful prompt to check this one server today, and equally useful as a reason to inventory every other tool in the stack that occupies a similarly privileged role, since the next disclosure is unlikely to wait for a convenient time.
