The short answer
JetBrains has patched CVE-2026-63077, a critical unauthenticated remote code execution flaw in TeamCity On-Premises with a CVSS score of 9.8. An attacker who can reach the server over HTTP(S) can bypass authentication through the agent polling protocol and execute arbitrary operating system commands with the privileges of the TeamCity server process — no login, no user interaction. Every on-premises version before the fix is affected; the patched builds are 2025.11.7 and 2026.1.3.
JetBrains says it is not aware of active exploitation yet, and TeamCity Cloud is unaffected. But this is your build server — the machine that holds your source code, signing keys and deployment credentials — so the correct response is to patch on an emergency timeline, not the next maintenance window.
What did JetBrains disclose?
On its TeamCity security blog, JetBrains disclosed CVE-2026-63077, a flaw that lets an unauthenticated attacker “bypass authentication checks and execute arbitrary operating system commands” against a TeamCity On-Premises server. The root cause is insecure deserialization of untrusted data (CWE-502) in the agent polling protocol — the channel build agents use to check in with the server. Because the flaw sits in that protocol rather than the login flow, an attacker never needs a valid account: HTTP(S) reachability to the server is enough to run code as the TeamCity server process.
The issue was reported by security researcher Antoni Tremblay on 10 July 2026 and fixed in TeamCity 2025.11.7 and 2026.1.3. JetBrains also shipped its established security patch plugin for installations on 2017.1 and later that cannot upgrade the whole server right away, and confirmed that TeamCity Cloud was already patched and needs no customer action. In the same release cycle the company resolved a high-severity post-authentication TeamCity vulnerability (CVE-2026-44413) and a separate critical code-execution flaw in IntelliJ IDEA — a reminder to patch the developer tooling on engineers' laptops, not only the server. Locking down an internet-facing CI/CD platform and confirming your real exposure is exactly what penetration testing and security audits are meant to surface before an attacker does.
How bad is it, really?
The severity is not marketing. A 9.8 CVSS reflects the worst combination for a defender: exploitable over the network, no authentication, no user interaction, and full impact on confidentiality, integrity and availability. JetBrains' own advisory notes that a successful compromise can expose TeamCity data, configurations and stored credentials, or let an attacker modify server state. In plainer terms, the person running the exploit ends up with the same power over your build server that your own DevOps team has.
Two things temper the panic without removing the urgency. First, this affects On-Premises only — if you run TeamCity Cloud, JetBrains handled it for you. Second, there is no confirmed in-the-wild exploitation as of disclosure. But history is not on the side of waiting: in 2024 an authentication-bypass flaw in TeamCity (CVE-2024-27198) was exploited in the wild shortly after disclosure, including by state-linked groups, and CI/CD servers are prized targets precisely because of what they contain. Treat “no exploitation yet” as a countdown, not an all-clear.
Why an RCE on the build server is worse than it sounds
It is tempting to file this under “another critical CVE” and move on. The reason not to is what the affected system is. A CI/CD server is not a normal application host; it is tier-0 infrastructure that sits at the centre of your software supply chain. On a typical TeamCity install you will find, in one place:
- Source code for every project it builds, including private repositories.
- Signing keys and certificates used to sign releases and container images.
- Deployment credentials — cloud tokens, registry logins, SSH keys — with standing permission to push to production.
- Environment secrets and API keys injected into builds.
Code execution there is not the compromise of one machine; it is a master key. An attacker can exfiltrate those secrets, then pivot into your cloud accounts and production systems using credentials that are supposed to be there. Worse, they can quietly tamper with the build itself — injecting a backdoor into an artifact that your pipeline then signs and ships to your own customers. That is the anatomy of a supply-chain attack, and it is why an unauthenticated RCE on a build server belongs in the same mental bucket as a domain-controller compromise, not a routine patch Tuesday item.
What it means for US & EU software teams
The immediate implication is operational: patch on an emergency change ticket, not the next window. For a self-hosted TeamCity that is reachable from the internet, the window between public advisory and working exploit for a flaw this clean is measured in days. Upgrade to 2025.11.7 or 2026.1.3, or apply the security patch plugin, today.
The second implication is architectural, and it outlasts this one CVE. Ask why the build server was reachable from the open internet in the first place. Tier-0 systems should sit behind a VPN or a zero-trust access layer, on a dedicated host, running under a least-privilege service account, with their secrets held in a managed vault rather than pasted into build configurations. If patching this flaw is a scramble because nobody is sure which secrets the server holds or who can reach it, that uncertainty — not the CVE — is the thing to fix. For teams in regulated sectors such as FinTech or healthcare, an unlogged compromise of the system that ships your code is also a compliance problem: SOC 2, DORA and the NIS2 Directive all expect demonstrable control over the software supply chain and a clean audit trail of what ran where.
The third is cultural. The teams that shrug off advisories like this are usually the ones treating CI/CD as plumbing that “just works.” The teams that stay safe treat the build pipeline as production infrastructure with an owner, a threat model and a patch SLA. This CVE is a cheap reminder to move from the first camp to the second before an incident makes the argument for you.
What to do this week
Work the list in order — the first item is the emergency, the rest close the door behind it.
- Patch now. Upgrade every TeamCity On-Premises instance to 2025.11.7 or 2026.1.3, or apply JetBrains' security patch plugin if you are on 2017.1+ and cannot upgrade yet.
- Get it off the open internet. Put the server behind a VPN or zero-trust gateway and restrict the agent polling endpoint and REST API to trusted networks only.
- Assume the secrets are burned. If the instance was internet-facing before patching, rotate stored credentials, signing keys, deployment tokens and API keys as a precaution.
- Hunt before you relax. Review server and access logs for anomalous agent connections, unexpected processes and unfamiliar admin or build-config changes around and before the disclosure date.
- Least-privilege the service account. Run TeamCity on a dedicated host under an account with the minimum OS permissions it needs, so a future RCE is contained rather than total.
- Patch the IDEs too. Push the IntelliJ IDEA fix from the same JetBrains batch to developer machines; laptops are part of the supply chain.
None of this is legal or security advice, and your exact obligations depend on your data, sector and jurisdiction. But the direction is clear: the build server is one of the most valuable machines you own, and the teams that treat it that way — patched, isolated, least-privileged and logged — are the ones that read advisories like this as routine rather than as emergencies.
Frequently asked questions
What is CVE-2026-63077?
It is a critical unauthenticated remote code execution vulnerability in JetBrains TeamCity On-Premises, rated CVSS 9.8. It stems from insecure deserialization of untrusted data in the TeamCity agent polling protocol. An attacker with network access to the server can bypass authentication and execute arbitrary operating system commands with the privileges of the TeamCity server process, without any credentials or user interaction. It was reported by researcher Antoni Tremblay on 10 July 2026 and disclosed by JetBrains in late July 2026.
Which TeamCity versions are affected and where is the fix?
All TeamCity On-Premises versions prior to the fixes are affected. JetBrains resolved the flaw in versions 2025.11.7 and 2026.1.3; upgrade to one of these or later. If you cannot upgrade immediately, JetBrains provides a security patch plugin for TeamCity 2017.1 and newer. TeamCity Cloud is not affected and requires no action from customers.
Is CVE-2026-63077 being exploited in the wild?
At the time of disclosure, JetBrains said it was not aware of any active exploitation. That is not a reason to wait. TeamCity has a documented history of critical flaws being weaponised quickly after disclosure, including CVE-2024-27198 in 2024, which was exploited in the wild. Public proof-of-concept work typically follows a high-profile CI/CD advisory within days, so patch before a working exploit circulates.
Why is an RCE on a CI/CD server so dangerous?
A CI/CD build server is tier-0 infrastructure: it holds source code, signing keys, deployment credentials and cloud tokens, and it has standing permission to push artifacts to production. Code execution on that server is not one compromised host; it is a foothold to steal every secret it stores, tamper with build outputs, and reach downstream systems and customers through a supply-chain path. That is why an unauthenticated RCE on a build server is treated as a top-tier incident rather than a routine patch.
Sources
JetBrains — Critical Security Issue Affecting TeamCity On-Premises (CVE-2026-63077)
The Hacker News — Critical TeamCity Flaw Could Let Attackers Run OS Commands Without Logging In