What 1,817 Exposed TeamCity Servers Say About CI/CD as an Attack Target

A CI/CD server holds credentials for everything it deploys. Source repositories, container registries, cloud accounts, and production environments all trust the pipeline. When an unauthenticated remote code execution flaw lands in that server, the pipeline becomes the path to all of it.

The evidence

ZoomEye searches for the TeamCity product fingerprint returned the following at the time of collection:

Query	Count
`app="JetBrains TeamCity"`	1,817
`app="JetBrains TeamCity" && service="http"`	995
`vul.cve="CVE-2026-63077"`	0

These counts describe product assets matching the fingerprint. They do not confirm a vulnerable version. The affected ranges for CVE-2026-63077 are TeamCity On-Premises versions below 2026.1.3 and below 2025.11.7. A server running a fixed build still matches the product fingerprint.

The vul.cve="CVE-2026-63077" query returned zero, which means ZoomEye had no assets indexed against that CVE identifier at collection time. That is a limitation of CVE-index coverage, not evidence that no affected servers exist. The product fingerprint is the more useful query for this case.

The vulnerability

CVE-2026-63077 is an unauthenticated remote code execution flaw in JetBrains TeamCity On-Premises, rated CVSS 9.8 and classified as CWE-502, deserialization of untrusted data. An unauthenticated attacker can reach the /app/agents/v1/* interface, bypass authentication, and execute arbitrary system commands with the privileges of the TeamCity service process.

Rapid7 published a complete exploitation chain and proof of concept. CISA added the flaw to the KEV catalog.

Why the exposure number matters less than the trust model

The count of 1,817 is modest compared with the NetScaler or RouterOS populations. The number that matters for CI/CD is not how many servers are exposed. It is how much each one is trusted.

A TeamCity server typically holds:

Deployment credentials for production environments.
Access tokens for source control and package registries.
Signing keys and secrets injected into build pipelines.
Network reachability into internal build and test environments.

Compromising one server reaches all of those. The 995 web-facing instances in the second query are the subset that presents an HTTP interface, which is the interface the flaw uses. That is the population to review first.

Scoping a response

Identify TeamCity instances from internal inventory rather than relying on external search alone. Build servers are often internal, and the external count understates the total.
Check the version against the fixed builds: 2026.1.3 or later, or 2025.11.7 or later. All earlier versions are affected.
Treat any instance that was reachable from an untrusted network as potentially compromised. Rotate the credentials it held, including source control tokens, registry credentials, and deployment keys.
Review build logs and agent activity for commands that were not part of a normal pipeline run. The /app/agents/v1/* interface is where the flaw is triggered, so agent-related activity is the place to look.
Restrict network access to the TeamCity server. A build server rarely needs to be reachable from the public internet.

The pattern across CI/CD

CI/CD platforms are attractive because they concentrate trust. A build server is designed to hold credentials and execute code, which is the same capability an attacker wants. The 1,817 exposed instances are a small number in absolute terms and a large number in terms of what each one can reach.

For a flaw like CVE-2026-63077, the exposure count is a starting point for scoping, not a measure of risk. The risk comes from what the server is allowed to do once it is compromised.

Limitations

Product fingerprint counts are snapshots and should be re-run rather than reused. They describe product presence, not vulnerability. The zero result for the CVE-index query reflects the coverage of that index at collection time and should not be read as a statement about affected systems.