Who Actually Trusts Their Build Server?

# Who Actually Trusts Their Build Server? I spend my weekends reading changelogs. Most people find them tedious; I find them honest. A changelog is where a vendor finally admits they left the back door unlocked for six months. This week, the most interesting admission comes from JetBrains regarding TeamCity and CVE-2026-63077. The advisory describes it as a "critical" code execution vulnerability. In my book, 'critical' is a word that has to be earned. To earn it, a flaw shouldn't just allow an attacker to crash a service or leak some environment variables; it should hand over the keys to the kingdom. Since this allows remote code execution (RCE) on a build server—the very place where software is baked and signed—it earns the label. The technical breakdown is simple: a failure in how the server handles certain requests, allowing an unauthenticated attacker to execute arbitrary code. For those running versions prior to 2026.1.5, you're exposed. The fix is version 2026.1.5. There's a disconnect here that I enjoy. JetBrains suggests in their advisory that the attack vector is "complex" and requires specific conditions to be met. Then we have the researcher write-ups. The PoC hitting the wire just under 14 days ago shows that on a default installation, the exploit works with about three curl commands and a bit of patience. When a vendor says 'complex' and a researcher provides a script that takes ten seconds to run, I trust the script. Who actually runs TeamCity? Not your home-office hobbyist. This is enterprise gear. It’s used by the kind of companies that have "Release Engineering" as a formal job title. These are organizations moving thousands of lines of code into production every hour. The problem isn't just that an attacker can get onto the server. The problem is what lives on that server. TeamCity holds the secrets: API keys, SSH keys to production environments, and signing certificates. If I compromise your build server, I don't need to spend three weeks pivoting through your network to find your crown jewels. They're already sitting in the environment variables of a Jenkins or TeamCity project. Patching this isn't as straightforward as hitting 'update' on a Chrome browser. In a CI/CD pipeline, an update to the orchestration server can break every single build script in the company. If you have 40 different projects with custom plugins and legacy configurations, moving from 2026.1.4 to 2026.1.5 might trigger a cascade of failures that brings production to a halt. This is why the patch gap exists. People aren't lazy; they're terrified of breaking the pipeline. But here is the trade-off: you can either spend a weekend fixing broken build scripts or spend a month scrubbing an attacker out of your production environment. Let’s talk about who is exposed two steps downstream. If Company A runs an unpatched TeamCity server, they are the primary victim. But Company A produces software used by Company B and Company C. If an attacker poisons the build process via CVE-2026-63077, they aren't just stealing data from Company A; they are inserting a backdoor into every single update sent to Company B and C. This is the second-order effect that keeps analysts awake. We saw this play out with SolarWinds years ago, though the mechanism there was different. The rhyme here is the target: the build pipeline. When you compromise the factory, you don't have to break into every house to plant a bug; you just put the bug in the product at the factory and let the customer install it for you. Some will argue that TeamCity isn't exposed to the open web, making this a non-issue. They'll say it's tucked away behind a VPN or a strict firewall. That’s a comfortable lie. VPNs are not invisibility cloaks. Look at CVE-2025-68686 in FortiOS; when the perimeter itself is leaking sensitive information, that "internal" build server becomes an easy target for anyone who's already slipped through the front door. Once an attacker has a foothold on a developer's workstation or a jump box, they don't go looking for the HR folder. They go straight for the CI/CD server because it’s the most efficient path to total domain dominance. I’ve seen two stories hit my desk this week regarding active scans for this flaw. The attackers are already knocking. They aren't using complex AI swarms or state-sponsored magic; they're just scanning for a specific version string and sending the payload. If you're managing the server, check your version number now. If it says anything other than 2026.1.5 or newer, you are effectively hosting a public terminal for whoever finds you first. The real question isn't whether you can patch it today. It's why we still build our entire software supply chain on the assumption that the build server is a trusted entity. We spend millions on EDR and XDR at the endpoints, but we leave the actual factory—the place where the code is born—running on software that requires a manual upgrade every time a new RCE drops. I suspect we'll see a surge in "poisoned update" alerts over the next quarter. The lag between a PoC release and enterprise patching is usually where the most damage happens. I’m betting north of 1,000 organizations are still running the vulnerable version simply because they don't want to risk a failed build on a Tuesday morning. It's a bold choice to prioritize uptime over integrity. I hope they enjoy the company.