CISA’s addition of CVE-2026-63077 to its Known Exploited Vulnerabilities Catalog highlights the serious risk created when attackers gain control of a continuous integration and continuous delivery platform. The vulnerability affects JetBrains TeamCity On-Premises and can allow an unauthenticated remote attacker to bypass security checks and execute arbitrary operating-system commands through the TeamCity agent polling protocol. Because TeamCity frequently stores source-code access, deployment credentials, signing material, cloud secrets and trusted connections to build agents, successful exploitation may provide attackers with considerably more than control of one server. 

The vulnerability has been classified as deserialization of untrusted data and carries a critical severity rating of 9.8. Exploitation does not require a valid TeamCity account or interaction from an administrator. An attacker needs only network access to the vulnerable TeamCity service over HTTP or HTTPS. The ability to execute commands without authentication makes internet-facing TeamCity servers particularly attractive targets because attackers can scan for exposed instances and attempt compromise without first stealing credentials or exploiting a user workstation.

JetBrains states that all TeamCity On-Premises versions are affected unless they have been upgraded to version 2025.11.7 or 2026.1.3. Customers unable to perform a complete upgrade can apply a dedicated security patch plugin to TeamCity 2017.1 and later. TeamCity Cloud customers do not need to take action because JetBrains has already applied the required protections to the hosted service. Organizations operating their own TeamCity infrastructure should verify the precise installed build rather than assuming that a recent major release is safe.

CISA’s decision to place the vulnerability in the KEV Catalog confirms that exploitation is occurring against real systems. JetBrains had initially stated that it was unaware of active exploitation when it published its advisory, but the later CISA addition changes the operational risk significantly. Organizations should therefore treat exposed TeamCity servers as potentially compromised if they were reachable before the correction was installed. Updating the software closes the known vulnerability, but it does not remove malicious accounts, stolen credentials, altered build configurations or persistence established by an attacker before remediation.

TeamCity occupies a privileged position within the software-development environment. It retrieves source code from repositories, executes build instructions, runs tests, packages applications and may deploy software directly into production. To perform these tasks, it often has access to Git credentials, package-registry tokens, cloud access keys, database passwords, deployment certificates and signing keys. A successful attacker may therefore be able to move from the TeamCity server into repositories, build agents, cloud platforms and production systems using credentials that the organization deliberately entrusted to its CI/CD infrastructure.

Compromise of a TeamCity server can also undermine the integrity of software produced by the organization. An attacker may modify build steps, inject malicious code, replace dependencies or alter compiled artifacts while leaving the visible source repository unchanged. Developers reviewing the repository may find no unauthorized commit because the manipulation occurred during the build process rather than in the source itself. The resulting application can still be distributed through the organization’s legitimate release channel and may carry a valid digital signature if the build environment has access to signing credentials.

This creates a serious software supply-chain risk. Customers and internal users generally trust software produced by an organization’s official CI/CD pipeline. If attackers control that pipeline, they can potentially distribute malicious updates under the identity of the legitimate vendor. The compromise may consequently extend beyond the organization operating TeamCity and affect every customer or business unit receiving software generated during the exposure period.

Build agents require particular attention because TeamCity servers communicate with them through trusted management channels. Agents execute build scripts and may run on dedicated servers, developer infrastructure, cloud virtual machines or container platforms. An attacker controlling TeamCity may send commands to connected agents, retrieve files or use them as stepping stones into otherwise separated networks. Build agents may also have access to secrets that are not stored permanently on the central server but are injected during individual jobs.

Organizations should determine which agents communicated with the vulnerable TeamCity server and review their activity throughout the suspected compromise period. Unexpected build jobs, command execution, downloaded tools, new services and unusual outbound network connections should be investigated. Where agents are ephemeral, security teams should examine the underlying images, templates and build definitions to confirm that attackers did not modify them to recreate malicious access each time a new agent starts.

Internet exposure should be removed immediately wherever it is not strictly required. JetBrains recommends restricting TeamCity access to trusted networks, using VPN connectivity or placing an additional authenticated security layer in front of the service. Even exposing the login screen or REST API gives attackers access to code paths that may contain newly disclosed or unknown vulnerabilities. A CI/CD management interface should not be directly reachable from arbitrary internet addresses merely because remote developers occasionally need convenient access.

Network restrictions should complement rather than replace the software update. A firewall or VPN may reduce exposure, but it does not correct vulnerable code or address access from compromised internal systems. Organizations should install TeamCity 2025.11.7 or 2026.1.3 as soon as possible. Where operational constraints prevent immediate upgrading, the official security patch plugin should be deployed while the full update is planned. Administrators using older TeamCity releases should also recognize that the plugin addresses this specific vulnerability and does not provide the broader security fixes included in current releases.

After remediation, administrators should confirm that the corrected version or plugin is actually active. Deployment tools may report that an update was attempted even when the service failed to restart or a clustered node was missed. Each TeamCity server, standby instance, disaster-recovery system and test environment should be checked independently. Container images, virtual-machine templates and infrastructure automation must also be updated so that vulnerable servers are not recreated later during scaling or recovery.

The incident response process should begin with a review of TeamCity user accounts, authentication settings, API tokens and administrative roles. Newly created users, unexplained privilege changes and unfamiliar personal access tokens may indicate attacker activity. Security teams should inspect project configurations, build templates, scheduled builds, server-side plugins and command-line steps for unauthorized modifications. Attackers may alter an existing build rather than creating an obviously suspicious new project, so comparison with trusted configuration history is important.

Repository access should also be examined. GitHub, GitLab, Bitbucket and other source-control logs may reveal unusual cloning, token use, branch modification or access from unfamiliar infrastructure. Credentials stored in TeamCity or available to affected build jobs should be considered potentially exposed. These may include repository tokens, npm or PyPI publishing credentials, container-registry passwords, SSH keys, cloud service accounts and database secrets.

Credential rotation should occur only after the vulnerable server has been isolated and attacker persistence has been addressed. Replacing secrets while an attacker still controls TeamCity may simply provide the new values through the same compromised environment. Active sessions and refresh tokens should also be revoked, because changing a password may not invalidate every existing form of access. Signing certificates and private keys require careful assessment because exposure could allow attackers to create malicious software that appears to originate from the organization.

Organizations should identify every artifact produced during the suspected compromise window and determine whether it can be trusted. Builds should be reproduced from known-clean source code inside a clean pipeline where possible, and the resulting hashes should be compared with previously distributed artifacts. Unexpected differences require investigation, although differences alone may also arise from non-reproducible build processes. Software released during the exposure period may need to be replaced or withdrawn if build integrity cannot be established.

Build logs can provide useful evidence but should not be trusted blindly because an attacker with TeamCity administrative or operating-system access may be able to alter or delete them. Logs should be correlated with repository history, endpoint telemetry, cloud audit records, network connections and package-registry activity. Centralized logging is especially valuable because records stored outside the compromised server are harder for attackers to manipulate.

Endpoint security systems should investigate unusual child processes launched by the TeamCity server. Command shells, PowerShell, scripting interpreters, download utilities and credential-access tools may reveal post-exploitation activity. However, TeamCity legitimately executes many build commands, so detection must consider the project, user, timing and expected build behaviour. Commands running outside approved jobs or originating through unfamiliar agent polling activity deserve immediate attention.

The operating-system privileges assigned to the TeamCity service determine part of the potential impact. If the server process runs as a highly privileged account, arbitrary command execution may provide broad control over the host. JetBrains recommends running TeamCity with only the permissions needed for normal operation and keeping the server on a dedicated host separate from build agents. This separation reduces the number of systems and credentials immediately available after server compromise.

Least privilege should also extend to build credentials. A TeamCity server should not hold one permanent administrative token capable of accessing every repository and production environment. Credentials should be narrowly scoped to individual projects and operations, issued for short periods and injected only when required. Production deployment secrets should not be exposed during ordinary test or dependency-installation stages. Hardware-backed signing and external secrets-management systems can further reduce the value of compromising the CI/CD server.

Organizations using TeamCity through a managed service provider should confirm whether the provider operates TeamCity On-Premises, which versions are deployed and when remediation was completed. Customers should ask whether the instance was internet-accessible and whether the provider reviewed administrative activity and build integrity for signs of exploitation. A statement that the server has now been patched does not establish that software or credentials were not compromised earlier.

Where successful operating-system command execution is confirmed or strongly suspected, rebuilding the TeamCity server from a trusted image may be safer than attempting selective cleanup. Attackers with control of the host may install hidden services, modify binaries or alter plugins in ways that survive an application upgrade. The rebuilt environment should use corrected TeamCity software, newly issued credentials and reviewed project configurations. Restoring the complete server from a backup created after the intrusion began may simply restore the attacker’s modifications alongside the legitimate data.

The broader lesson from CVE-2026-63077 is that CI/CD systems must be treated as critical production infrastructure rather than ordinary developer tools. They sit between source code and deployable software and frequently possess the authority to change both. A vulnerability that provides unauthenticated command execution in TeamCity can therefore threaten source repositories, cloud environments, build agents, signing systems and downstream customers through one central platform.

CISA’s addition of the flaw to the KEV Catalog should trigger immediate asset discovery, remediation and forensic review. Organizations should identify all TeamCity On-Premises instances, remove unnecessary internet exposure, install the corrected release or security plugin and investigate activity that occurred before patching. Credentials accessible to the platform should be rotated after containment, and software artifacts generated during the exposure period should be reviewed for integrity.

The objective should not be limited to making the vulnerability disappear from a scanner. Security teams must establish whether the TeamCity server was exploited, determine what authority it provided and verify that the software-development pipeline remains trustworthy. Closing the vulnerable endpoint is only the first step. The more difficult task is proving that attackers did not use it to alter the software everyone else is expected to trust.

CISA has added one new vulnerability to its Known Exploited Vulnerabilities (KEV) Catalog , based on evidence of active exploitation. CVE-2026-63077 JetBrains TeamCity Deserialization of Untrusted Data Vulnerability This type of vulnerability is a frequent attack vector for malicious cyber actors and poses significant risks to the federal enterprise. Binding Operational Directive (BOD) 26-04: Prioritizing Security Updates Based on Risk establishes vulnerability management requirements for Federal Civilian Executive Branch (FCEB) agencies. BOD 26-04 reinforces the importance of the KEV Catalog and requires federal agencies to prioritize rapid remediation of high-risk vulnerabilities, specifically those identified by Common Vulnerabilities and Exposures (CVEs) listed in CISA’s KEV Catalog on publicly exposed assets that grant total control of the asset post-exploitation, while deferring action for lower-risk vulnerabilities. BOD 26-04 further establishes basic expectations for when agencies must check whether threat actors compromised the system before the patch was applied. While BOD 26-04 applies only to FCEB agencies, CISA encourages all organizations to adopt risk-based vulnerability management and prioritize remediation of KEV Catalog vulnerabilities . CISA will continue to add vulnerabilities to the catalog that meet the specified criteria . Aware of an exploited vulnerability not currently listed in the KEV Catalog? Submit it for potential addition through CISA’s KEV Nom

Source: CISA Adds One Known Exploited Vulnerability to Catalog via CISA Advisories — published 05 Aug 2026.