The critical TeamCity remote code execution flaw highlights why CI/CD platforms must be treated as high-value 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, artifact stores, package registries, cloud accounts, deployment tools, container registries, signing keys, and production environments. That makes a TeamCity server a very attractive target.

The vulnerability, tracked as CVE-2026-63077, affects TeamCity On-Premises before versions 2025.11.7 and 2026.1.3. JetBrains has warned that an unauthenticated attacker with HTTP or HTTPS access to a vulnerable 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, the attacker may be able to run commands directly on the system hosting the CI/CD platform.

Remote code execution on a CI/CD server is not just a normal server compromise. It can become a software supply-chain incident. A build server is where source code turns into deployable software. If attackers control that environment, they may be able to steal source code, modify builds, poison artifacts, access deployment secrets, or compromise downstream systems.

This is why TeamCity and similar tools should be protected like production infrastructure. They often hold credentials that ordinary application servers do not. These may include Git credentials, deployment keys, cloud tokens, package-publishing tokens, SSH keys, API keys, signing certificates, container registry credentials, and environment secrets. In other words, the build server is not “just a build server.” It is a vault with a compiler attached, because apparently software needed a more dramatic attack surface.

Organizations using TeamCity On-Premises should immediately identify all instances. This includes production servers, staging servers, internal engineering systems, test environments, disaster-recovery systems, old build servers, and forgotten instances used by small teams. The forgotten CI server is usually the one still holding a production token from three years ago, because enterprise archaeology is never kind.

All affected TeamCity servers should be upgraded to 2025.11.7, 2026.1.3, or a later fixed version. Administrators should confirm that the running service has actually restarted into the patched version. Installing an update but leaving the vulnerable process running is not remediation. It is paperwork with a progress bar.

Internet exposure should be reviewed immediately. CI/CD servers should not be broadly reachable from untrusted networks. TeamCity access should be restricted through VPN, zero-trust access, firewall allowlists, identity-aware proxies, or trusted management networks. Public access to a build-control platform should require strong justification and strong compensating controls.

Patching should be followed by compromise assessment. Because this flaw allows unauthenticated command execution, any exposed vulnerable server should be treated as potentially compromised until reviewed. “We patched it” does not prove “nobody used it before we patched it.” That distinction is irritating, but it is also reality.

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

Defenders should pay special attention to TeamCity launching unexpected commands, scripts, shells, download tools, archive utilities, or network tools outside normal build behavior. Build systems naturally execute many commands, which makes detection harder. Attackers like noisy environments because their activity can hide inside normal automation.

Credentials and secrets must be reviewed urgently. TeamCity may store or access VCS credentials, cloud keys, SSH keys, deployment tokens, API secrets, package registry credentials, signing keys, webhook secrets, service-account passwords, and environment variables. If exploitation is suspected, any secret accessible to the TeamCity server or build agents should be treated as potentially exposed.

Organizations should rotate exposed secrets from a clean administrative environment. This may include GitHub, GitLab, Bitbucket, Azure DevOps, AWS, Azure, GCP, Kubernetes, Docker registry, npm, Maven, NuGet, PyPI, internal package registry, deployment, and signing credentials. Removing the exploit path while leaving stolen credentials active is basically sending the attacker a polite forwarding address.

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 contain cached source code, workspace files, build tools, credentials, test data, and access to internal services. A compromised CI server can turn trusted build agents into attacker-operated workstations with better branding.

Build artifacts should be reviewed carefully. Attackers who compromise CI/CD may not stop at stealing secrets. They may modify source code, change build scripts, inject backdoors, alter release packages, tamper with containers, replace installers, or poison dependencies. Recently produced artifacts should be validated against source control, signed release records, expected hashes, and known-good baselines.

Repository activity should also be reviewed. Attackers may use stored credentials to clone private repositories, add malicious commits, create deploy keys, modify webhooks, inspect secrets in commit history, or harvest intellectual property. Source-code systems should be checked for unusual access from the TeamCity server, unfamiliar IP addresses, new tokens, and unexpected repository changes.

Package registries and artifact repositories deserve special attention. A compromised TeamCity server may have the ability to publish packages, update container images, modify internal libraries, or change release metadata. If attackers can poison a package or container image, the impact can spread far beyond the original CI server.

Cloud and deployment environments should also be reviewed. If TeamCity has permissions to deploy to production, attackers may have tried to use those permissions. Cloud audit logs, Kubernetes audit logs, deployment histories, infrastructure-as-code changes, and service-account activity should be checked for unusual behavior.

Least privilege is essential. TeamCity should not hold broad production credentials unless absolutely required. Build jobs should use narrowly scoped credentials, separate service accounts, protected environments, approval gates, and short-lived tokens where possible. One compromised project should not become access to the entire estate.

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

Administrators should also review TeamCity plugins. Unknown, outdated, or unnecessary plugins should be removed. Plugins extend functionality and can expand the attack surface. A build server with random plugins is not flexible engineering. It is a supply-chain buffet with no guest list.

Security teams should hunt for persistence. Attackers may create new users, API tokens, SSH keys, build configurations, scheduled builds, malicious templates, startup scripts, cron jobs, services, or hidden files. They may also modify legitimate build steps so malicious activity appears as normal pipeline execution.

Backups should be protected and verified. TeamCity backups may contain sensitive configuration, project data, tokens, and credentials. If attackers accessed the server, they may have accessed backups as well. Recovery should be based on a trusted clean state, not simply the latest available archive.

This incident also reinforces the need for CI/CD incident-response playbooks. A compromised build platform is not the same as an infected laptop. The response must include the CI server, build agents, repositories, secrets, artifacts, package registries, cloud deployments, and downstream software integrity.

For software vendors, the business risk can be significant. If released software, containers, installers, or packages were produced while the CI/CD system was compromised, customers may be affected. That possibility must be investigated quickly and transparently.

The key lesson is that TeamCity is part of the software supply chain. It should be protected like critical infrastructure because it helps create and deploy critical infrastructure.

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

A build server is not just where code gets compiled. It is where trust is assembled. If attackers gain unauthenticated command execution on that system, the risk moves beyond one server and into everything that server can build, sign, publish, and deploy.

JetBrains is warning of a critical authentication bypass vulnerability affecting TeamCity On-Premises that could be exploited to achieve remote code execution. [...]

Source: JetBrains warns of critical TeamCity remote code execution flaw via Bleeping Computer — published 30 Jul 2026.