No Login Required: TeamCity Agent Polling Bug Grants Remote Code Execution (CVE-2026-63077)

Send one crafted request to an exposed TeamCity On-Premises server and you do not need a password, a session cookie, or a single valid username. CVE-2026-63077, disclosed by JetBrains on July 27, is a CVSS 9.8 deserialization flaw in the agent polling protocol, the channel TeamCity build agents use to ask the server for work. An attacker who can reach that channel over HTTP(S) gets arbitrary command execution as the TeamCity server process.

This is yours to check if you run TeamCity On-Premises anywhere, including a staging or test instance nobody patches on the same cadence as production. TeamCity Cloud is not affected; JetBrains checked its cloud fleet for exploitation attempts and found none. If your build pipeline runs entirely on a SaaS runner, GitHub Actions cloud or CircleCI cloud among them, this specific CVE does not touch you. The pattern behind it still does: a self-hosted CI/CD server is the one machine in most environments holding source code, cloud credentials, signing keys, and deployment access at the same time, which is exactly why it keeps getting targeted.

What the agent polling protocol actually exposes

TeamCity build agents do not sit idle waiting for a webhook. They poll the server on a regular interval, asking for the next job to run, and the server answers with serialized data describing that job. CVE-2026-63077 sits in how the server handles that exchange: an attacker who sends a crafted payload to the polling endpoint gets it deserialized without proving they are a real agent, and the resulting process runs with enough privilege to execute OS commands and reach whatever the TeamCity server can reach. No login form, no API token, no session. IONIX's technical write-up scores the attack path as network-based, low complexity, no privileges, no user interaction (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), the formal way of saying anything that can send the server a packet can own it.

JetBrains fixed the flaw in TeamCity 2025.11.7 and 2026.1.3. Every on-premises version before those two, back through the 2017.1 line, is affected.

TeamCity has been here before

Security teams that have run TeamCity since 2023 will recognize the shape of this immediately. CVE-2023-42793, another unauthenticated RCE in TeamCity On-Premises, was under active exploitation by APT29, the Russian SVR-linked group also known as Cozy Bear or Midnight Blizzard, within weeks of disclosure, according to a joint advisory from CISA, the FBI, and international partners. Ransomware affiliates followed the nation-state actors into the same foothold, reaching source code, build artifacts, and code-signing material. A compromised CI/CD server does not just cost the owner an incident response bill. It hands an attacker a credible path into every downstream user of whatever that pipeline builds and signs, which is what makes this category of bug a supply-chain problem rather than a single-server problem.

JetBrains reports no active exploitation of CVE-2026-63077 as of publication, and no public proof-of-concept exploit is circulating yet. Treat that as a narrow window, not a reason to wait. The 2023 bug went from disclosure to nation-state exploitation in under three weeks, and a reverse-engineered diff against the last vulnerable build is usually enough for a capable attacker to reconstruct a working exploit without ever seeing a public PoC.

Patch, or apply the plugin if you cannot patch tonight

Upgrade to 2025.11.7 on the 2025.11.x branch or 2026.1.3 on the 2026.x branch. If a full upgrade needs a maintenance window you cannot get tonight, JetBrains published a security patch plugin covering every on-premises version back to 2017.1; install it as a stopgap, not a permanent substitute for the version upgrade. Restricting the server to a VPN or an internal-only network while you schedule the real patch closes the immediate exposure but does not fix the underlying deserialization bug, so treat that as a delay tactic, not a resolution.

Three checks worth running tonight, in order

# 1. Confirm your running TeamCity version
curl -s https://<your-teamcity-host>/app/rest/server | grep -oE 'version="[^"]+"'

# 2. Confirm the server is not reachable from outside your intended network
nmap -p 8111 --open <your-teamcity-host>

# 3. If you applied the security patch plugin instead of upgrading, confirm it loaded
curl -s https://<your-teamcity-host>/app/rest/plugins | grep -i "TeamCitySecurityPatch"

If the version check comes back below 2025.11.7 or 2026.1.3 and the network scan shows the server answering from outside where you expect it to, assume exposure since July 27 and start there: review TeamCity server logs for polling requests from agent identifiers you do not recognize, and check whether any build configuration, build step, or stored credential changed in a window you cannot account for.

Patch TeamCity tonight, then check who could reach it before you did

The fix here is not complicated. What takes discipline is treating a CI/CD server with the same urgency as a domain controller, because functionally it is one: the system every other system in your environment implicitly trusts. If TeamCity On-Premises has been running quietly in a corner of your infrastructure since it was first stood up, tonight is the night it gets a version check, a patch, and a look at its access logs, not next sprint.

Primary sources: JetBrains' advisory for CVE-2026-63077, the NVD entry, IONIX's technical exploitability analysis, and the joint CISA/FBI advisory on APT29's exploitation of the 2023 TeamCity flaw.

We review CI/CD and build-pipeline exposure as part of our broader network security assessments, specifically for the internet-facing infrastructure that gets stood up once and never revisited. If you want a second set of eyes on what your build environment exposes, book a session with our team.