TeamCity CVE-2026-63077: unauthenticated RCE via agent polling
Every TeamCity On-Premises release is affected by a critical authentication bypass and RCE. Here are the fixes, containment and investigation plan.
- AUTHOR
- Karol Rapacz / CEO of Breachroad · OSCP · PNPT
- PUBLISHED
- 2 August 2026
- READING TIME
- 10 min read
- TOPIC
- Vulnerabilities and CVEs
JetBrains has disclosed CVE-2026-63077, a critical vulnerability in TeamCity On-Premises. An attacker with HTTP(S) access to the server can exploit the agent polling protocol without authentication, bypass access checks and execute operating-system commands with the privileges of the TeamCity server process.
The issue affects every on-premises version. Fixes are available in 2025.11.7 and 2026.1.3, and JetBrains provides a security patch plugin for TeamCity 2017.1 and later. TeamCity Cloud was remediated by JetBrains and does not require customer action.
Why a CI/CD server is a high-value target
RCE on any application server is serious. RCE on a CI/CD controller has an additional dimension: the build system commonly stores repository tokens, container-registry credentials, signing keys, deployment variables and paths into production.
The JetBrains advisory says exploitation may expose TeamCity data and configuration, modify server state, and compromise build artifacts or downstream pipelines. The possible chain is:
internet → TeamCity → secrets → repository/registry → artifact → production
Closing the vulnerable endpoint after a suspected attack is therefore not enough. Responders must assess everything the server could read, sign or deploy.
Conditions and affected scope
Exploitation requires no account and no user interaction. Network reachability to TeamCity over HTTP(S) is sufficient, and the path crosses the agent polling protocol. Commands run as the server process, so practical impact also depends on its OS account, network reach and available secrets.
JetBrains received the private report on 10 July. At advisory publication time, the vendor was not aware of active exploitation. That is not proof that attacks did not occur; it is the vendor’s stated knowledge at a specific time.
What to do now
Preferred option: upgrade
Update to 2025.11.7 or 2026.1.3, according to your release line. Verify the effective version in the running service, not merely the success of an automation job. Ensure a reverse proxy or cluster is not still routing traffic to an old node.
Temporary option: security plugin
If a full upgrade cannot be completed immediately, JetBrains offers a plugin for versions 2017.1 and later. Versions 2017.1–2018.1 require a restart; from 2018.2 the plugin can be enabled without one. The plugin fixes only CVE-2026-63077 and does not replace a release containing other security corrections.
Reduce exposure
- remove public access to the UI and API;
- require a VPN or an additional access layer before TeamCity;
- restrict source addresses for agents and administrators;
- run the server with minimum OS privileges;
- separate the server host from build agents;
- block unnecessary egress into production and secret-management systems.
Segmentation does not replace the fix, but it reduces both reachability and potential blast radius.
How to investigate possible abuse
The public advisory does not include complete exploit artefacts, so investigation should combine behaviour, logs and state change:
- Preserve application, reverse-proxy, operating-system and EDR logs before restarting or cleaning.
- Review requests to agent-communication paths from unusual sources or without expected agent context.
- Hunt for child processes of TeamCity, especially shells, transfer utilities and scripts outside normal build jobs.
- Compare configuration, plugins, accounts, tokens and projects with the last trusted state.
- Verify artifacts built during the risk window, including signatures, provenance and registry publication.
- Rotate secrets reachable by the TeamCity process when compromise cannot be excluded.
- Inspect repositories, registries and deployment targets for use of those credentials.
“No malware file found” is not a sufficient conclusion. An attacker may use legitimate pipeline mechanisms, modify configuration or steal a token and continue from another system.
Long-term architecture
After patching, replace long-lived secrets with short-lived workload identities, minimise privileges per project and add independent artifact signing or verification. Our CI/CD security guide and OIDC workload-identity guide explain the underlying controls.
Primary facts versus Breachroad analysis
The all-version On-Premises scope, unauthenticated agent-polling path, fixed releases and no-known-exploitation statement come directly from JetBrains. The public advisory does not provide enough detail to independently reproduce exploitation.
Breachroad’s conclusion is to treat TeamCity as a software-supply-chain control point and extend investigation to secrets, artifacts and downstream systems. Cybersecurity training for development and operations teams can rehearse the scenario, while an IT security audit can assess exposure, segmentation, secrets and pipeline integrity.


