JetBrains Left TeamCity Unpatched and Put Cadence Source Code and Credentials Within Reach
JetBrains disclosed an unauthenticated command-execution flaw in TeamCity On-Premises. CISA later added it to the Known Exploited Vulnerabilities catalogue. A compromised build server is not only one more server to recover. It is a trusted system that can change what the organisation ships.
Cadence Credentials May Still Work After JetBrains Closed the Investigation
Update, 3 September 2026 at 19:00 CEST: JetBrains has concluded its investigation and widened the potential exposure. The company says the attacker obtained access that could have reached storage used by the current Cadence environment. That storage contained data associated with current users, including email addresses, project source code and credentials.
This replaces the narrower 31 August position that JetBrains had found no evidence of extraction from the current environment. The company has not said that every file or credential was definitely copied. It is treating the data as potentially exposed because the attacker had a path to the storage. The affected user group has not expanded, and JetBrains says it found no additional affected users.
The operational guidance does not change: rotate every credential or secret that may have been stored in, synchronised to or made available to Cadence; review repositories, cloud accounts, object storage, registries and deployment systems for activity from 8 August onward; and treat Cadence inputs and outputs as untrusted. The investigation may be closed, but the credentials that crossed this boundary remain usable until customers revoke them.
Update, 31 August 2026: JetBrains says its own Cadence server missed the patch
JetBrains has now confirmed that attackers used CVE-2026-63077 against Cadence, a JetBrains-hosted cloud-compute service connected to PyCharm. The affected Cadence server used TeamCity to orchestrate workloads and remained vulnerable from at least 8 August until JetBrains took it offline on 24 August.
The disclosure turns the supply-chain risk described below into a confirmed incident inside the vendor’s own environment. JetBrains says the server should have been patched as part of its response to the TeamCity vulnerability, but was not.
The threat actor extracted customer personal data, including usernames, real names, email addresses, last-login timestamps and last accessed IP addresses. JetBrains also confirmed that the actor accessed a complete 2024 Cadence server backup. That backup contained multiple JetBrains AWS IAM users and associated credentials or secrets. Files in JetBrains S3 buckets used by Cadence were accessed, and source code synchronized from PyCharm projects may also have been exposed.
JetBrains narrowed one part of its assessment on 31 August, saying at the time that it had found no evidence of extraction from the current Cadence environment. That position was superseded by the 3 September update above: the company now says attacker access could have reached current Cadence storage containing user data, source code and credentials.
The affected period runs from 8 to 24 August. JetBrains says it discovered the exploitation on 23 August and removed api.cadence.jetbrains.com from service the following day.
Anyone who used Cadence should treat every credential available to a Cadence execution as potentially compromised. The response scope includes cloud accounts, source-control tokens, package and container registries, API tokens, Slack webhooks, SSH and deployment keys, service accounts, signing certificates and secrets embedded in synchronized project files. JetBrains also advises users to treat Cadence inputs and outputs as untrusted and to review connected repositories, storage and deployment environments for suspicious activity.
This incident shows why patch ownership matters as much as patch availability. JetBrains had already published fixed TeamCity releases and a security patch plugin. Its own hosted service still missed the remediation window, and a vulnerability in the orchestration layer reached backups, cloud identities and customer development material.
JetBrains’ Cadence incident notice was initially published on 28 August 2026 at 11:50 CEST and last updated on 3 September 2026 at 19:00 CEST.
Update, 29 August 2026: Metasploit now automates the exploit
Rapid7 added a working Metasploit module for CVE-2026-63077 on 27 August. The module turns the public exploit path into a repeatable framework workflow: it registers a TeamCity build agent, abuses unsafe XStream deserialisation, writes a one-shot JSP payload into the TeamCity webroot and executes it with the privileges of the server process.
The module includes a version check for TeamCity 2025.11.7 and 2026.1.3, the releases Rapid7 identifies as fixed. It also notes an important detection limit: the separate security patch plugin available for older TeamCity releases cannot be identified through the HTTP interface used by the module’s check routine.
This is public exploit availability, not a new confirmation that malicious exploitation has begun. CISA had already confirmed active exploitation. The material change is operational friction: an attacker or tester can now reproduce the chain through a widely used framework instead of assembling the exploit manually. Internet-reachable TeamCity servers that have not been upgraded should be isolated and investigated, not merely scheduled for routine patching.
An agent protocol reached the server without authentication
CVE-2026-63077 affects TeamCity On-Premises and was present across supported and older versions at the time of disclosure. JetBrains says an attacker can abuse the build-agent polling protocol without authentication and execute arbitrary operating-system commands with the privileges of the TeamCity server process.
JetBrains fixed the issue in TeamCity 2025.11.7 and 2026.1.3. It also released a security patch plugin for installations running version 2017.1 or later. TeamCity Cloud was not affected and required no customer action.
The initial vendor disclosure said JetBrains was not aware of exploitation. That changed when CISA added the flaw to its Known Exploited Vulnerabilities catalogue on 5 August, confirming that exploitation had been observed and giving US federal civilian agencies a short remediation deadline.
The blast radius follows TeamCity’s trust
Remote command execution on a CI server is dangerous because the server sits at the intersection of source code, credentials and deployment authority.
Depending on configuration, TeamCity may hold repository tokens, package-registry credentials, signing material, cloud keys, deployment secrets and connections to production systems. It may also control build configurations and produce artefacts that other systems automatically trust.
An attacker who reaches the server could therefore do more than install malware on one host. They could inspect stored settings, alter build logic, replace artefacts, steal tokens or use existing integrations to move into repositories and deployment environments.
That does not mean every vulnerable TeamCity server has suffered a supply-chain compromise. It means responders should investigate the systems that trust TeamCity, not stop after applying the update.
Internet exposure makes the path shorter
TeamCity servers are sometimes exposed so remote workers, distributed agents or external integrations can reach them. That convenience turns an unauthenticated server-side flaw into an internet-facing entry point.
The first inventory question should be simple: where are the TeamCity On-Premises servers, and which networks can reach their agent and web services? The second is harder: what credentials and release privileges does each server possess?
A forgotten test installation can be as useful to an attacker as a production server if it retains valid repository credentials or network access. Organisations should include old, standby and migration systems in the search.
Patching is the beginning of the response
JetBrains recommends updating to a fixed release or installing the security patch plugin where a full upgrade is not immediately possible. Because active exploitation is confirmed, exposed systems should also be treated as candidates for compromise.
Defenders should:
- Update to TeamCity 2025.11.7, 2026.1.3 or a later fixed release, or deploy JetBrains’ security patch plugin where supported.
- Remove direct internet access where it is not operationally necessary and restrict agent communications to expected networks.
- Review server, agent and operating-system logs for unexpected commands, processes, accounts and configuration changes.
- Audit build configurations, plugins, hooks and recently produced artefacts for unauthorised modification.
- Rotate repository, registry, cloud and deployment credentials available to the server.
- Validate release artefacts against known-good source and independent signatures before redeployment.
- Rapid7 Metasploit module commit for CVE-2026-63077, published 27 August 2026 at 20:22:36 UTC.
If evidence of compromise appears, rebuilding the TeamCity server from a trusted baseline is safer than assuming that deleting one file has removed persistence.
CI security is release security
The key lesson is not simply that TeamCity needed a patch. It is that build systems often receive broad trust while remaining less isolated than production systems.
Strong segmentation, short-lived credentials, protected signing keys and independent artefact verification reduce the damage a compromised CI server can cause. They also make recovery more credible because the organisation can prove what was built and released.
An unauthenticated command shell on the CI server is urgent. The deeper risk is every automated decision that accepts the server’s output without another check.
