TeamCity CVE-2026-63077: Unauthenticated RCE in CI/CD

What does CVE-2026-63077 allow?

According to BleepingComputer and NVD, an attacker who can reach the TeamCity server over HTTPS bypasses authentication through the build agent polling protocol and runs system commands with the privileges of the server process. This is remote code execution with no account or interaction. JetBrains describes the possible consequences: exposure of data, configurations and stored credentials, or compromise of build artifacts and CI/CD pipelines depending on privileges.

Who is affected and which versions fix it?

All versions of TeamCity On-Premises. The fixed versions are 2025.11.7 and 2026.1.3. TeamCity Cloud customers have nothing to do: JetBrains applied the necessary measures. For those who cannot update, a security patch plugin exists for TeamCity 2017.1 and later; it is downloaded automatically from 2024.03, and versions 2017.1 to 2018.1 require a server restart after installation.

How is the flaw exploited?

At the time of the advisory, JetBrains reported no exploitation. The KEV listing on August 5 shows it has been exploited since. TeamCity's history points the same way: BleepingComputer recalls earlier flaws exploited to create administrator accounts, by ransomware groups and by state-backed actors. A CI/CD server concentrates what attackers look for: source code, build secrets, signing certificates, access to deployment environments.

How do you know whether you are exposed and how do you test?

1. Inventory TeamCity On-Premises servers, their version and network exposure (login page or REST API reachable from the internet).
2. Check exposure from outside: a publicly reachable CI/CD login page is the main signal.
3. Audit build configurations: new steps, modified scripts, added environment variables, unexpected administrator accounts, unknown registered agents.
4. Review server logs for unusual requests to the agent protocol before the update.

How do you fix it?

Update to 2025.11.7 or 2026.1.3, or install the patch plugin if updating is impossible. JetBrains also recommends a VPN or another protective layer for internet-facing servers. After an exposure, rotate every secret the server could reach (cloud credentials, deploy keys, signing certificates, container registry tokens), verify the integrity of artifacts produced during the exposure window by comparing them with known-good versions or rebuilding from a clean state, and restrict the registration of new agents.

What changes when an AI agent has access to a CI/CD pipeline?

CI/CD is where AI agents receive the most power: coding agents that open merge requests, trigger builds, read failure logs, fix tests, sometimes deploy. They inherit the pipeline's environment variables, tokens and rights. A compromised CI/CD server gives the attacker those secrets and the ability to alter what the agents run.

Three agent-specific effects. Build logs as untrusted input: an agent that reads logs, commit messages or test outputs may find an injected instruction there (OWASP LLM01), and an injection inside a pipeline acts with the pipeline's secrets. Secrets reachable by the agent: a deploy key present in the environment where the agent runs is readable by any code it executes (LLM02). And autonomy: an agent allowed to trigger a deployment without approval turns a pipeline compromise into a production release. Useful controls: secrets in a dedicated vault with short-lived tokens, an agent execution environment with no access to production credentials, human approval before any deployment, and segmentation of the CI/CD server. See AI agent security, the GitLab Oj case and Azure DevOps MCP.

Why is the build agent protocol a sensitive surface?

Build agents connect to the server to receive work, often from varied networks (virtual machines, workstations, containers, contractors). The server therefore exposes an endpoint designed to be called by machines, sometimes from outside, with its own authentication logic. A mistake there bypasses everything else, including user access control. Putting the server behind a VPN or an authenticated tunnel, and allowing registration of approved agents only, reduces that surface.

What signs reveal a pipeline compromise?

Look for build steps added or modified with no associated merge request, new environment variables, artifacts whose hash differs from a clean rebuild, outbound downloads from agents to unknown addresses, and accounts or tokens created outside usual hours. Keep the server logs before any update to make the analysis easier. If artifacts built during the exposure window have already shipped to customers, plan the notification and the rebuild together, because a compromised build can propagate to everyone downstream.

How do you test an agent against TeamCity CVE-2026-63077?

An agent red team places a booby-trapped instruction in what the agent reads in CI (log, comment, configuration file) and measures the secrets it sees, the commands it runs and the deployments it can trigger. In five days for 1,900 euros, the Agent Red Team Express tests what a build agent can do if TeamCity is taken without authentication. The method details the approach.

What is the lesson?

In practice, treat the CI/CD server as the most privileged system you run. A self-hosted CI/CD server belongs behind a VPN, on a short patch cycle, with its secrets in a vault and not in build variables. Add one principle for agents: whatever a pipeline can do, a hijacked agent can do.