The critical TeamCity vulnerability highlights why CI/CD platforms must be treated as highly sensitive infrastructure, not just developer tooling.

TeamCity is used to build, test, package, release, and deploy software. It often connects to source-code repositories, build agents, package registries, artifact stores, cloud accounts, deployment systems, signing keys, container registries, test environments, production credentials, and internal automation. That makes a TeamCity server a very attractive target.

The vulnerability, tracked as CVE-2026-63077, affects TeamCity On-Premises. JetBrains has stated that an unauthenticated attacker with HTTP or HTTPS access to a TeamCity server may be able to bypass authentication checks and execute arbitrary operating-system commands with the privileges of the TeamCity server process.

That is extremely serious. The attacker does not need a valid TeamCity account. If the vulnerable server is reachable and the flaw can be exploited, the attacker may be able to run commands directly on the system hosting the CI/CD server.

Remote code execution on a build server is not just a server compromise. It can become a software supply-chain compromise. A build server is where source code becomes deployable software. If attackers control that environment, they may be able to steal code, tamper with builds, modify artifacts, poison releases, access secrets, or influence deployment pipelines.

This is why CI/CD security matters so much. The build platform often holds trust that ordinary servers do not. It may have access to private repositories, deployment keys, package-publishing tokens, container registry credentials, cloud service accounts, SSH keys, API tokens, database credentials, and production automation. In some environments, the build server is basically the factory floor for software. Leaving it exposed is like handing strangers a visitor badge and a soldering iron.

Organizations using TeamCity On-Premises should immediately check whether they are running affected versions and upgrade to the fixed releases. JetBrains has released TeamCity 2025.11.7 and 2026.1.3 to address this issue. Administrators should confirm that the server has actually restarted into the patched version, because a patch sitting politely on disk does not defend anything.

Internet exposure should be reviewed urgently. CI/CD servers should not be broadly reachable from untrusted networks. If TeamCity is exposed to the internet, it should be restricted immediately through VPN, zero-trust access, firewall allowlists, identity-aware proxy, or trusted administrative networks. Public access to a build control plane should require a very strong business justification.

Patching should be followed by compromise assessment. Because the flaw enables unauthenticated command execution, any exposed vulnerable TeamCity server should be treated as potentially compromised until reviewed. “We patched it” is not the same as “nobody exploited it before we patched it.” This painful distinction continues to exist despite everyone’s best efforts to ignore it.

Security teams should review TeamCity server logs, web access logs, operating-system logs, process execution history, build history, plugin activity, administrator activity, agent connections, configuration changes, and outbound network traffic. Suspicious signs may include unusual HTTP requests, unexpected command execution, new files, unfamiliar plugins, abnormal build steps, modified project settings, or strange activity from the TeamCity server process.

Defenders should pay special attention to TeamCity launching unexpected processes such as shell commands, PowerShell, curl, wget, Python, Perl, bash, cmd, or archive utilities outside normal build behavior. Build systems naturally execute many commands, which makes detection harder. That is exactly why attackers like them. The noise is already there, wearing a hard hat.

Credentials and secrets require urgent review. TeamCity may store or access VCS credentials, deployment tokens, cloud keys, SSH keys, package registry tokens, signing credentials, service-account passwords, webhook secrets, and environment variables. If exploitation is suspected, exposed credentials should be rotated from a clean and trusted environment.

Organizations should also review build artifacts. Attackers who compromise a CI/CD system may not only steal secrets; they may modify what the organization ships. Recently built artifacts, containers, installers, packages, scripts, and release binaries should be validated against source control, known-good build records, signatures, and expected hashes.

Build agents should also be investigated. TeamCity servers coordinate build agents, and compromise of the server may allow attackers to influence agents or use them for lateral movement. Agents may have workspace data, cached dependencies, credentials, toolchains, local scripts, and network access to internal systems. A compromised CI server can turn trusted build agents into attacker workstations with better branding.

Organizations should review repository access after a TeamCity compromise. Attackers may use stored credentials to clone private repositories, add malicious commits, create deploy keys, alter webhooks, or harvest source code. GitHub, GitLab, Bitbucket, Azure DevOps, and internal Git servers should be checked for unusual access patterns.

Package registries and artifact repositories should also be reviewed. Attackers may attempt to publish malicious packages, replace artifacts, alter release metadata, or steal tokens used for npm, PyPI, Maven, NuGet, Docker, or internal package repositories. A poisoned package can spread far beyond the original TeamCity server.

Cloud and deployment environments need special attention. If TeamCity has permissions to deploy to AWS, Azure, GCP, Kubernetes, VMware, production servers, or customer environments, those access paths should be reviewed. Cloud audit logs, Kubernetes audit logs, deployment histories, infrastructure changes, and service-account activity should be checked for unusual actions.

Least privilege is essential. TeamCity should not run with broad operating-system privileges or hold global deployment credentials unless absolutely necessary. Build jobs should use narrowly scoped credentials, short-lived tokens where possible, and separate service accounts per project or environment. One compromised build project should not become access to every production system.

Network segmentation also matters. A TeamCity server should not have unrestricted reach into databases, domain controllers, production networks, file shares, backup servers, and cloud control planes. CI/CD platforms need connectivity, but that connectivity should be deliberate, logged, and limited.

Administrators should also review TeamCity plugins. Plugins extend functionality and can introduce risk. Unknown, outdated, or unnecessary plugins should be removed. Plugin installation and updates should be controlled, logged, and reviewed. A build server with random plugins is not flexibility; it is a supply-chain party with no guest list.

Security teams should monitor for persistence. Attackers may create new users, API tokens, SSH keys, build configurations, scheduled builds, malicious templates, service changes, cron jobs, startup scripts, or hidden artifacts. They may also modify legitimate build steps so malicious activity blends into normal pipeline execution.

Backups should be protected and reviewed. TeamCity backups may contain sensitive configuration and credentials. If attackers accessed the server, they may have accessed backups as well. Restoring from backup should be done carefully to avoid reintroducing malicious changes or compromised secrets.

This vulnerability also reinforces the need for CI/CD incident-response playbooks. A compromised build system is not the same as a compromised workstation. The response must include infrastructure, source control, secrets, artifacts, build agents, deployment environments, cloud accounts, and downstream software integrity.

For software vendors, the business impact can be significant. A compromised CI/CD server may create risk for customers if released software, updates, containers, or packages were tampered with. That possibility should be investigated quickly and transparently.

The key lesson is that TeamCity and similar CI/CD systems are part of the software supply chain. They should be protected like critical production systems, because they help create production systems.

Organizations should patch TeamCity On-Premises immediately, restrict network access, hunt for compromise, rotate exposed secrets, review build artifacts, inspect build agents, and validate deployment activity.

A build server is not merely a developer convenience. It is a trusted machine that turns code into software. If attackers gain unauthenticated command execution on that machine, the risk moves beyond one server and into the integrity of everything that server builds, signs, publishes, and deploys.

JetBrains is urging customers of on-premise versions of TeamCity to update to the latest version following the discovery of a critical security issue that could result in arbitrary code execution. The vulnerability, assigned CVE-2026-63077 (CVSS score: 9.8), affects all TeamCity On-Premises versions. It has been addressed in versions 2025.11.7 and 2026.1.3. TeamCity Cloud instances have already

Source: Critical TeamCity Flaw Could Let Attackers Run OS Commands Without Logging In via The Hacker News — published 28 Jul 2026.