Published on gastropod.io - 07-28-2026

No Login Required: TeamCity's Critical RCE and Your Build

Tags: vulnerability intelligence, software supply chain security, ci-cd-security, remote-code-execution, teamcity, jetbrains, deserialization, provenance, blast-radius

JetBrains disclosed a critical vulnerability in TeamCity On-Premises on July 27. CVE-2026-63077 carries a CVSS score of 9.8. An attacker with nothing more than HTTP or HTTPS access to a TeamCity server can bypass authentication and run arbitrary operating system commands as the TeamCity server process. No credentials. No user interaction.

The issue is in the agent polling protocol, the channel build agents use to poll the server for jobs and configuration. IONIX traces the root cause to insecure deserialization of untrusted data (CWE-502): send a crafted payload to the polling endpoint and the server will execute it. Every TeamCity On-Premises version is affected. JetBrains fixed it in 2025.11.7 and 2026.1.3 and shipped a patch plugin for older installs going back to v2017.1. Each maintenance release also, this closes more than 20 other security issues. TeamCity Cloud was already patched, and JetBrains says it found no evidence of exploitation there. Security researcher Antoni Tremblay reported the bug privately on July 10 under coordinated disclosure.

If you run TeamCity on-prem, patch now, or apply the plugin and restrict network access to the server until you can patch.

Why a build server is such a bad place to have this

A build server is not just another application. It holds source code, environment variables, deployment tokens, signing material, and the configuration that decides what your pipeline produces. Whoever controls it controls what ships. JetBrains is blunt about the impact: depending on the privileges of the server process, an attacker can read stored credentials and configuration, change server state, and tamper with the build artifacts and downstream pipelines that TeamCity feeds.

That last part is the one that could cause impact even after you patch. An attacker on your build server does not need to break into your registry. Your build server already has the access to publish, and it publishes with your identity. A poisoned artifact from a compromised pipeline could be inserted looking exactly like a clean one: same package name, same source your teams already trust.

What identity and an audit trail change

Patching TeamCity closes this specific hole. After you have fixed this and your pipeline is secure again 'did anything change that shouldn't have' is the question you have to answer after a pipeline compromise: what did that server publish, when, and who pulled it.

How gastropod.io can help in situations like this

Gastropod identifies every artifact by its sha256 digest and records every pull against a principal: who, what, from where, and when. When a build server is suspect, you query the audit spine for everything it published during the exposure window, and the blast-radius graph for every consumer that pulled it. That is one incident-response query instead of a forensic reconstruction across scattered build logs.

Provenance verification runs at intake, not after the fact. Gastropod checks Go checksums, npm SRI, and Sigstore attestations where they are present, and flags identity- and provenance-mismatches on the record. An artifact published outside a project's normal signed release flow does not carry the provenance you expect, so it enters flagged instead of trusted.

A critical RCE in your build server is a bad day. Not being able to say what came out of it afterward is a worse one. You can see how Gastropod handles artifact identity, provenance, and the audit spine, and run it against your own pipelines when you get started.