CISA’s decision to add CVE-2026-63077 to its Known Exploited Vulnerabilities Catalog highlights the substantial security consequences of vulnerabilities affecting continuous integration and continuous delivery infrastructure. The critical flaw 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 exploitation requires neither valid credentials nor user interaction, any vulnerable TeamCity server reachable through HTTP or HTTPS may provide attackers with a direct route into one of the most trusted components of the software-development environment. 

The vulnerability has received a CVSS severity score of 9.8 and is classified as deserialization of untrusted data. Deserialization vulnerabilities occur when an application accepts structured data from an untrusted source and reconstructs it into executable program objects without adequately restricting what those objects can do. A specially crafted payload can manipulate this process and cause the application to perform actions never intended by its developers. In the case of CVE-2026-63077, the unsafe processing occurs through the protocol used by TeamCity build agents to poll the central server for tasks and configuration information, allowing an attacker to execute commands with the permissions assigned to the TeamCity server process.

The vulnerability affects all TeamCity On-Premises releases before versions 2025.11.7 and 2026.1.3. JetBrains has released both corrected versions and a security patch plugin for TeamCity 2017.1 and later, allowing organizations that cannot immediately complete a full platform upgrade to close this specific vulnerability. TeamCity Cloud customers do not need to take action because JetBrains has already deployed the required protections to the hosted platform. Organizations operating TeamCity themselves must verify the exact installed build and should not assume that a relatively recent release is protected merely because it was updated earlier in 2026.

CISA’s inclusion of the flaw in the KEV Catalog confirms that attackers are exploiting it against real systems. This changes the appropriate response from precautionary patching to urgent remediation and investigation. When JetBrains initially disclosed the issue, it stated that it had not observed evidence of active exploitation. The later CISA warning establishes that threat actors have since weaponised the vulnerability or that exploitation evidence became available after the vendor’s original announcement. Organizations that operated exposed TeamCity systems before applying the correction must therefore consider the possibility that attackers entered the environment before the vulnerability became widely recognised.

TeamCity is an exceptionally valuable target because it occupies the central point between source code and deployable software. The platform retrieves code from repositories, executes build scripts, downloads dependencies, runs tests, creates packages and may deploy completed applications directly into development, testing or production environments. To perform these functions, TeamCity frequently holds or can access source-control tokens, package-registry credentials, cloud access keys, database passwords, SSH keys, deployment secrets and software-signing material. A remote code execution vulnerability in TeamCity can consequently expose far more than the files stored on the server itself.

Successful attackers may use the TeamCity process to inspect configuration files, environment variables, build histories and stored credentials. They may steal tokens that provide access to GitHub, GitLab, Bitbucket, container registries, cloud platforms or internal artifact repositories. If the server process runs with excessive operating-system privileges, attackers may also modify local security controls, install persistent remote access, create accounts or access sensitive files elsewhere on the host. The technical impact therefore depends partly on the privileges granted to TeamCity, but even a restricted process may possess highly valuable application and deployment credentials.

The most serious consequence may be loss of confidence in the software produced through the affected CI/CD pipeline. Attackers controlling TeamCity can potentially change build steps, replace dependencies, modify environment variables or inject code while the application is being compiled. These changes may not appear in the visible source repository because the attacker can manipulate the build process after the approved code has already been retrieved. Developers inspecting Git history may therefore find no malicious commit even though the final application contains unauthorized functionality.

A compromised build pipeline may also sign and publish the altered software using the organization’s legitimate release infrastructure. Customers and internal users commonly trust applications distributed through official update channels, especially when the files carry a valid digital signature. If the attacker gains access to signing keys or controls the stage at which signing occurs, malicious artifacts may appear indistinguishable from genuine releases. The incident can then become a wider software supply-chain compromise affecting every user or customer who receives software generated during the period in which TeamCity was under attacker control.

Build agents create another pathway for expansion. TeamCity agents execute compilation, testing, packaging and deployment tasks on behalf of the central server. They may operate on dedicated physical systems, virtual machines, cloud instances or container platforms and may have access to environments unavailable directly from the TeamCity server. An attacker controlling the server can potentially send malicious build instructions to connected agents and use their existing permissions to access additional networks, repositories and production resources.

Organizations should identify every build agent that communicated with the affected TeamCity server during the suspected compromise window. Security teams should review unexpected builds, command execution, downloaded files, newly created services and outbound connections on those agents. Ephemeral agents should not automatically be considered safe, because attackers may have modified the templates, container images or build definitions used to create them. A malicious change to the underlying image could cause every newly launched agent to recreate the attacker’s persistence.

Internet exposure substantially increases the risk. JetBrains recommends operating TeamCity inside a trusted environment and restricting access through VPNs or an additional authenticated security layer. Even exposing the login page or application programming interfaces allows unauthenticated users to reach application code that may contain known or undisclosed vulnerabilities. CI/CD administration systems should not be directly accessible from arbitrary internet addresses merely because developers occasionally need remote access.

Removing public exposure is an important immediate containment measure, but it does not replace installation of the corrected version. Internal attackers, compromised employee devices or breached VPN accounts may still reach the vulnerable service. Organizations should upgrade to TeamCity 2025.11.7 or 2026.1.3 as soon as possible. Where a full upgrade cannot be completed immediately, the official security patch plugin should be installed and external access should remain restricted until the permanent update has been deployed.

Administrators should understand that the plugin corrects CVE-2026-63077 specifically and does not contain every security and reliability improvement included in the latest TeamCity release. JetBrains states that the maintenance updates contain fixes for more than 20 security vulnerabilities, making a full upgrade preferable when operationally possible. The plugin is an emergency bridge, not an invitation to preserve an elderly TeamCity installation indefinitely because nobody remembers which build script will become offended by modernization.

Patch deployment must be verified independently. Administrators should confirm the full running build number on every TeamCity server rather than relying only on a change-management ticket or automated deployment status. Clustered installations, standby systems, test environments and disaster-recovery servers should all be examined. Container images, virtual-machine templates and infrastructure automation must also be corrected so that vulnerable instances are not recreated during scaling, restoration or future deployment.

Because CISA has confirmed active exploitation, the response should include threat hunting in addition to version verification. Security teams should review TeamCity administrator accounts, users, roles, API tokens, access keys, authentication settings and active sessions. Unexpected accounts, unexplained role changes and recently created tokens should be investigated. Attackers may create an alternative administrative identity or token that continues working after the original vulnerability has been patched.

Project configurations, build templates, plugins, scheduled jobs and command-line build steps should be compared with trusted historical versions. Attackers may alter an existing build definition rather than create an obviously malicious new project. Small changes to scripts or dependency sources can produce major effects while blending into complex configuration. Security teams should pay particular attention to newly added shell commands, PowerShell activity, external downloads and scripts that access credentials or modify release artifacts.

Operating-system telemetry from the TeamCity server should be reviewed for unusual child processes launched by the TeamCity service. Command shells, PowerShell, scripting interpreters, archive utilities and network download tools may indicate post-exploitation activity. TeamCity legitimately executes many commands as part of builds, so defenders must correlate the process with the responsible project, build job, user and agent. Commands appearing outside approved jobs or initiated through unusual polling requests deserve immediate investigation.

Repository logs can help determine whether attackers used stolen credentials to access or modify source code. GitHub, GitLab and Bitbucket audit records should be searched for unfamiliar logins, bulk cloning, token creation, changes to protected branches, altered workflows and access from hosting providers or unexpected regions. Package registries and container repositories should also be reviewed for unauthorized releases or modified tags. Attackers may publish poisoned dependencies or images even when the primary application repository appears unchanged.

Credentials accessible to TeamCity should be considered potentially exposed when successful exploitation cannot be ruled out. Repository tokens, cloud keys, package-publishing credentials, SSH keys, deployment passwords, database secrets and webhook tokens may all require rotation. This should occur after the vulnerable system has been isolated and attacker persistence has been addressed. Rotating credentials while attackers still control TeamCity may simply provide them with the replacement values.

Active sessions and refresh tokens must also be revoked because changing a password does not necessarily terminate every existing form of access. Signing keys require especially careful assessment. If private signing material was stored on the server or made available to build jobs, attackers may be able to produce malicious artifacts carrying the organization’s trusted identity. Such keys may need to be revoked and replaced, and software signed during the suspected compromise window may require additional validation.

Organizations should determine which software artifacts were produced while the TeamCity environment may have been compromised. Builds should be reproduced from known-clean source code in a trusted pipeline where possible, and the results should be compared against previously distributed packages. Reproducible builds provide the strongest evidence, but many real-world pipelines produce legitimate differences because of timestamps, dynamically retrieved dependencies or environment-specific data. Unexpected differences should be investigated rather than automatically treated as proof of malicious modification.

Build logs provide useful evidence but should not be trusted in isolation. An attacker with administrative or operating-system access may alter or delete local records. TeamCity logs should therefore be correlated with repository audit data, endpoint telemetry, network activity, cloud logs, artifact-registry records and signing-system events. Logs collected centrally before the compromise are generally more reliable than records remaining on the affected server.

The TeamCity service should operate with the minimum operating-system permissions required for its function and should be placed on a dedicated host separate from build agents. Running the server as root, `SYSTEM` or another broadly privileged identity magnifies the consequences of remote command execution. Separating the central server from agents also reduces the number of development tools, credentials and network paths immediately available after compromise.

Least privilege should extend throughout the CI/CD environment. TeamCity should not hold one permanent administrative credential providing access to every repository, cloud account and production system. Secrets should be scoped to individual projects and tasks, issued for short periods and injected only during the stages that require them. Dependency installation and untrusted testing should occur before production deployment credentials become available. External secrets-management systems and hardware-backed signing services can further reduce the amount of valuable material stored directly within TeamCity.

Managed service providers operating TeamCity on behalf of customers must also assess their exposure. Customers should confirm whether the provider uses TeamCity On-Premises, which versions were deployed, whether the interface was internet-accessible and when remediation was completed. They should also ask whether the provider reviewed account activity, build configurations and generated artifacts for evidence of exploitation. A statement that the platform is now patched answers only the easiest part of the incident.

Where unauthorized command execution is confirmed or system integrity cannot be established, rebuilding the TeamCity server from a trusted image is safer than attempting selective cleanup. Attackers may have modified plugins, operating-system services or binaries in ways that survive an application upgrade. The rebuilt environment should use corrected TeamCity software, newly issued credentials and project configurations validated against trusted history. Backups created after the initial compromise may contain attacker modifications and should not be restored blindly.

The broader cybersecurity lesson from CVE-2026-63077 is that CI/CD systems must be treated as critical production and supply-chain infrastructure rather than ordinary developer conveniences. These systems control how approved source code becomes software trusted by customers, employees and production environments. A vulnerability providing unauthenticated command execution threatens not only the TeamCity host but also the integrity of every build, credential and connected system that depends upon it.

CISA’s warning should therefore trigger immediate asset discovery, exposure reduction, patching and forensic review. Organizations should locate every TeamCity On-Premises instance, install version 2025.11.7 or 2026.1.3, apply the official plugin when an immediate upgrade is impossible and remove unnecessary internet access. They should investigate administrative activity, rotate potentially exposed secrets and verify the integrity of software produced during the exposure period.

The objective is not simply to make CVE-2026-63077 disappear from a vulnerability scanner. Security teams must determine whether attackers reached the server, what credentials and systems became available to them and whether the organization can still trust the software produced by the affected pipeline. Patching closes the vulnerable protocol. Proving that nobody used it to alter the build process is the far more important task.

A newly patched security flaw impacting on-premise versions of JetBrains TeamCity has come under active exploitation in the wild, according to the U.S. Cybersecurity and Infrastructure Security Agency (CISA). The vulnerability in question is CVE-2026-63077 (CVSS score: 9.8), a case of deserialization of untrusted data that could allow an unauthenticated attacker with access to a TeamCity server

Source: CISA Flags TeamCity CVE-2026-63077 RCE Flaw Under Active Exploitation in the Wild via The Hacker News — published 06 Aug 2026.