TeamCity CVE-2026-63077: pre-auth RCE on the box that ships your code

On 27 July 2026 JetBrains published an advisory for CVE-2026-63077: an unauthenticated attacker with HTTP(S) access to a TeamCity On-Premises server can bypass authentication through the agent polling protocol and execute operating system commands as the TeamCity server process. CVSS 9.8. Every On-Premises version is affected. At publication JetBrains was not aware of exploitation, and as of this writing there is no public proof-of-concept and no CISA KEV entry.

That last sentence is the reason to write this now rather than in a week. The two previous critical pre-auth bugs in this same product both went from advisory to mass compromise faster than most organisations complete a change-approval cycle. The window you are in right now is the only part of this timeline you control.

What CVE-2026-63077 does to a TeamCity server

The bug is deserialization of untrusted data (CWE-502) reachable through the agent polling protocol. TeamCity's default agent transport is unidirectional: the build agent opens an HTTP(S) connection outbound to the server and polls it for work. That design is a security improvement — it means you do not have to allow the server to reach into agent networks — but it also means the endpoint that accepts agent traffic has to be reachable by anything that runs builds, and it speaks a serialized object protocol.

Rapid7's analysis confirms the shape: network vector, low complexity, no privileges, no user interaction, arbitrary OS command execution with the privileges of the server process. The vulnerability was reported privately to JetBrains on 10 July 2026 by researcher Antoni Tremblay and fixed 17 days later in 2025.11.7 and 2026.1.3. TeamCity Cloud was patched by JetBrains and needs no customer action.

JetBrains' own framing of the impact is unusually direct. Daniel Gallo, the company's Solutions Engineering Lead, told Help Net Security that successful exploitation could expose TeamCity data, configurations and stored credentials, allow modification of server state, and compromise build artifacts and downstream CI/CD pipelines. Read that as three separate incidents stacked into one CVE: a credential breach, an integrity breach, and a supply-chain breach.

The 48-hour precedent: TeamCity has been here twice

This is the third time in three years that a critical pre-auth flaw in TeamCity has been the interesting thing on the internet.

September 2023 — CVE-2023-42793. Russia's SVR, tracked as APT29, exploited it at scale. On 13 December 2023 the FBI, CISA and NSA published advisory AA23-347A with international partners, reporting over 100 compromised TeamCity servers across the US, Europe, Asia and Australia. The advisory's assessment of why an intelligence service bothers is the clearest statement of the threat model anyone has written: access to a TeamCity server gives an actor "access to that software developer's source code, signing certificates, and the ability to subvert software compilation and deployment processes." FortiGuard Labs documented the post-exploitation on victim networks: scheduled-task DLL execution, ntdsutil credential dumping, lateral movement over WMIC/RDP/SMB, hidden local admin accounts, and C2 tunnelled through OneDrive and Dropbox APIs.

March 2024 — CVE-2024-27198. Auth bypass, disclosed 4 March. SecurityWeek reported that GreyNoise saw exploitation attempts from more than a dozen unique IPs the same day, and that LeakIX counted roughly 2,700 unpatched instances on 5 March, dropping to about 1,700 the next day — of which around 1,400 already showed rogue user creation. Attackers were creating between 3 and 300 accounts per server, with eight-character alphanumeric usernames. The payloads that followed were unglamorous: Jasmin ransomware, BianLian activity, XMRig, Spark RAT.

Roughly 80% of the exposed population was compromised inside 48 hours of a public advisory. Not by a nation-state — by whoever ran the PoC first.

The build server is Tier-0 infrastructure nobody governs like Tier-0

Ask a security team to name their Tier-0 assets and you will hear domain controllers, the identity provider, the PAM vault, maybe the hypervisor. You will very rarely hear "the build server", and that gap is the actual finding here. CVE-2026-63077 is just the occasion.

	Domain controller	CI/CD server
Holds credentials for	The directory	Every environment it deploys to, plus VCS, cloud, registries
Can modify	Identity	The code that runs in production
Change window	Emergency patch path exists	"The dev team owns it"
In pentest scope	Always	Rarely — it's "internal tooling"
Monitored by	SOC, tier 1	Whoever gets the build-failure email
Reachable from internet	Never	Often, so remote agents and webhooks work

A CI/CD server is an identity system that authenticates to everything, plus a code-execution service that everything downstream trusts, running on a change cadence set by a development team's release calendar. The reason attackers keep coming back to TeamCity is not that JetBrains writes worse code than Microsoft. It is that this asset class is systematically under-classified.

What the attacker is actually after

The instinctive question after an RCE advisory is "did they get root on the box". On a build server that is the wrong question, because the box itself is nearly worthless and everything it holds pointers to is not.

Defender: We patched TeamCity Wednesday morning, six days after the advisory. Clean.

Attacker, if they had been there Monday: Fine. I read your VCS deploy keys, your AWS access keys, your registry publish tokens and your artifact-signing material out of the server's stored credentials on day one. I added one build step to a library nobody reviews. Your patch closed my way in. It did not revoke anything I took, and it did not rebuild anything I touched.

Patching a CI/CD server after a credential-exposing RCE restores availability, not trust. Trust comes back only after rotation and artifact verification — which is why the runbook below spends more space on step 5 than on step 2.

Remediation

1. Am I affected?

Every On-Premises version prior to 2025.11.7 / 2026.1.3 is vulnerable. TeamCity Cloud is not.

# Version from the REST API (may require auth on hardened installs)
curl -sk -H "Accept: application/json" https://<teamcity-host>/app/rest/server

# Authoritative: Administration → Diagnostics shows the exact build number
# Server logs also carry it on startup:
grep -m1 -iE 'TeamCity server version|build [0-9]{5}' \
  "<TeamCity Server Home>/logs/teamcity-startup.log"

Then answer the exposure question, which matters more than the version:

# Is the server's HTTP(S) port reachable from outside your agent networks?
# Default 8111, or 443 behind a reverse proxy.
curl -sk -m 10 -o /dev/null -w "%{http_code}\n" https://<teamcity-host>/login.html

# What is it bound to?
ss -tlnp | grep -E ':(8111|443)'

If a non-agent network can complete an HTTP request to the server, treat this as P1.

2. Patch — exact fixed versions

Upgrade to 2025.11.7 or 2026.1.3. If you cannot upgrade tonight, JetBrains ships a security patch plugin covering CVE-2026-63077 for TeamCity 2017.1 and later; on 2024.03+ it appears under Administration → Updates → Available security updates. Versions 2017.1–2018.1 need a server restart after install; 2018.2+ do not. The plugin fixes this CVE only — it is a bridge, not a substitute for the upgrade.

3. Can't patch now? Compensating controls

• Restrict the server's HTTP(S) port to the agent subnets and your admin VPN at the firewall or security group. This is JetBrains' own first recommendation and it removes the entire unauthenticated attack surface for internet-based actors.
• Terminate TLS at a reverse proxy and require client certificates (mTLS) on the agent paths, so an unauthenticated request never reaches the deserialization code. This requires reconfiguring agents to present certs — plan the rollout, and use the network ACL as the same-night control.
• Run the TeamCity service under a low-privilege OS account. Command execution "with the privileges of the server process" is only as bad as those privileges.
• Do not expose the login page or REST API to the internet.

4. Hunt for compromise

If the server was reachable from an untrusted network before you patched, assume compromise and prove otherwise. Logs live in <TeamCity Server Home>/logs.

• Rogue accounts and tokens — Administration → Users for accounts you did not create, especially System Administrator. Then per-user tokens via /app/rest/users/id:<id>/tokens. The 2024 campaign's signature was 3–300 new users with random eight-character alphanumeric names; expect a different pattern this time, so review by creation date, not by name.
• Planted build steps — grep the project config tree for the classic download-and-execute shape:

  grep -rEl 'curl |wget |/dev/tcp|powershell -enc|base64 -d' \
    "<TeamCity Data Directory>/config/projects/"
  

  Also check VCS roots for altered URLs and build triggers for schedules nobody added.
• Malicious plugins — plugins run inside the server JVM, so one planted .zip is persistent RCE. List <TeamCity Data Directory>/plugins/ by mtime and reconcile against Administration → Plugins List.
• Rogue agents — the agent protocol is the attack surface; verify every authorized agent against your inventory.
• Deserialization artifacts — in teamcity-server.log, look for InvalidClassException, StreamCorruptedException, ClassNotFoundException and ObjectInputStream stack traces clustered around agent traffic. Failed gadget attempts are noisier than successful ones. Enable teamcity-rest.log (off by default) before you need it.
• ATT&CK mapping — T1190 (exploit public-facing application) → T1136.001 / T1098 (create and manipulate accounts) → T1505 (server software component, the plugin) → T1552.001 (credentials in files) → T1195.002 (compromise software supply chain) → T1567.002 (exfiltration to cloud storage, per the APT29 OneDrive/Dropbox pattern).

5. Eradicate and verify

Order matters: isolate, patch, then rotate. Rotating secrets while the RCE is still reachable just hands the attacker the new ones.

1. Snapshot the disk for forensics before you change anything.
2. Rotate in blast-radius order: artifact-signing keys and certificates first (a stolen signing key outlives every other secret), then cloud IAM keys and STS sessions, package-registry publish tokens, container-registry credentials, VCS deploy keys and SSH keypairs, TeamCity API tokens, all user passwords with session revocation, agent authorization tokens, and the TeamCity database credentials. Do not skip a class because it "wasn't stored on that box" — check the parameter tree for embedded secrets first.
3. Verify artifact provenance: rebuild from the last known-good tag on clean infrastructure and diff the hashes against what you shipped. Re-verify signatures on anything promoted during the exposure window (codesign --verify --deep --strict, signtool verify /pa, gpg --verify). A hash mismatch you cannot explain is an incident, not a build-nondeterminism problem — prove it either way.
4. De-authorize every agent and re-authorize only machines you control.
5. Confirm the fix holds: patched version reported, server port bound only to trusted networks, no unexplained established outbound connections from the host.

For NIS2 and DORA in-scope entities, document the timeline, the rotation log and the verification evidence as you go. Reconstructing this three weeks later for an auditor is significantly worse than capturing it live.

Where Zero Hunt fits

The pattern across 2023, 2024 and now 2026 is not "TeamCity is insecure". It is that internet-reachable internal tooling gets classified as low-risk, excluded from test scope, and patched on a development calendar — and adversaries have noticed which asset class that describes.

Zero Hunt's 10-agent AI swarm — Recon, Exploit, Web, Credential, Post-Exploit, Pivot, Tactic, Report, under an AI Controller — exists to close that scope gap rather than argue about it. Recon finds the build server that isn't in your asset register because it answers on 8111 from a network it shouldn't. The Exploit agent writes a generative exploit for your instance with a local LLM rather than replaying an ExploitDB entry, so validation does not depend on someone publishing a PoC first — which for CVE-2026-63077 has not happened yet. Every attempt runs in an ephemeral Docker container with optional gVisor hardening, so proving exploitability on a production build server does not mean risking one. And because campaigns are scheduled and change-triggered, a newly exposed CI endpoint starts a full campaign within the hour, which is the only cadence that competes with a 48-hour mass-exploitation window. New offensive skills are backtested in the AI Gym — 142+ skills against Vulhub, NYU CTF Bench, Cybench and 314 CVE-based black-box tasks — before they touch a customer environment, and the Knowledge RAG recalls how a TeamCity-class deserialization chain behaved in previous executions instead of rediscovering it.

The post-exploitation half is a traffic problem, not an endpoint problem. When a build server starts opening sustained TLS sessions to an ASN it has never contacted, or an agent fans out to hosts it never builds for, Zero Hunt's AI Traffic Analysis model — four inference heads over billions of PCAP sequences, 2.7+ Gbit/s on the appliance GPU — flags it while it is happening. That matters specifically here because the APT29 TeamCity intrusions used OneDrive and Dropbox for C2: destinations that are allowlisted everywhere and invisible to signature-based inspection, but behaviourally wrong coming from a machine whose job is to compile code.

Everything runs on-prem, with no cloud callbacks and no external LLM APIs — which, for the one server that holds your signing keys, is the only deployment model worth discussing. If you want to see how that scope gap gets closed in practice, get in touch or read the platform overview.