A second critical bug this cycle deserves attention from every engineering team: CVE-2026-63077, an unauthenticated remote code execution vulnerability in JetBrains TeamCity, rated CVSS 9.8. The flaw lives in the agent polling protocol, and it turns a build server into an attacker’s foothold.
What happened
TeamCity coordinates build agents through a polling protocol. The vulnerability lets an attacker who can reach that endpoint execute code on the server without logging in. Build servers are frequently exposed — to agents, to developers, sometimes to the internet — which makes an unauthenticated RCE here especially dangerous.
Our take: compromising CI/CD is a supply-chain event
We treat build infrastructure as tier-zero, and so should you. A CI/CD server is one of the most privileged systems in any company: it holds source code, signing keys, cloud deployment credentials, container registry tokens and environment secrets, and it has a legitimate, automated path to push artifacts straight into production. An attacker who owns your build server does not need to break into production — they can simply wait for your own pipeline to ship their code for them. That is the mechanism behind some of the most damaging breaches of the last few years.
The lesson is not “patch TeamCity” (though do that immediately). It is that the pipeline you trust to build and deploy everything is itself a high-value target that rarely gets the same testing as the apps it produces.
How an attacker exploits it
The chain is brutally short: reach the exposed agent endpoint, trigger the RCE, and land code execution on the build host. From there the attacker loots secrets, plants a backdoor in the build steps or a shared dependency, and lets the next deployment carry a poisoned artifact downstream to your customers. Because the malicious change rides the normal, signed release process, it often survives code review and passes straight through. Detecting that requires looking at the pipeline itself — the focus of a supply-chain security audit and a rigorous secure code review.
What you should do
- Patch immediately and check for compromise. Update TeamCity now, then review agent logs, admin accounts and recently changed build configurations for tampering.
- Take the build server off the open internet. The management interface and agent endpoints should never be publicly reachable. Segment CI/CD into its own network zone.
- Least-privilege everything. Give build agents short-lived, tightly scoped credentials; store secrets in a vault, not in plaintext config; and add egress controls so a compromised runner cannot phone home.
- Test the pipeline as an attacker would. Our external network penetration testing finds exposed build and management interfaces before someone else does, and API penetration testing hardens the automation endpoints that glue your delivery together.
If your applications get an annual pentest but your build system never has, you are guarding the house and leaving the factory unlocked.