Why Is Your Build Server Public?

# Why Is Your Build Server Public? The numbers on the wire this week are skewed. If you look at the targeting table, the Technology sector is sitting at #1, with 323 stories in the last seven days. Today alone added 55 new entries to that pile. When "Technology" is the top target, it doesn't usually mean hackers are trying to steal a few lines of code from a startup. It means they've found a way to turn the tools we use to build software into weapons against the people who buy it. The most urgent example is CVE-2026-63077. It's a critical flaw in JetBrains TeamCity, and CISA has already slapped it onto the Known Exploited Vulnerabilities catalog. For those not spending their weekends reading advisories, "unauthenticated remote code execution" means an attacker doesn't need a password or a fancy phishing lure to get in. They just send a specific packet to your server, and suddenly they own the machine. In a ten-person shop, your CI/CD pipeline, the system that takes your code and pushes it to production, is often the most privileged thing you own. It has the keys to your cloud environment, the credentials for your databases, and the ability to rewrite your application on the fly. If an attacker hits your TeamCity server, they aren't just stealing a database; they're moving into the cockpit. The standard advice from the big security firms is usually something like "simply deploy a robust Zero Trust Architecture." I hate that phrasing. You can't simply deploy a ZTA when you have three developers in different time zones and a budget that barely covers the coffee machine. The difference here is cost and visibility. An enterprise has a Security Operations Center (SOC) paying people six figures to watch for anomalies in their build logs. A small firm usually has one guy who set up the server three years ago and hasn't looked at the config since. For the enterprise, this is a ticket in a queue. For the small shop, it's an existential threat because you probably don't even know if your TeamCity instance is reachable from the public internet. This isn't just about a single server getting popped. The real danger here is the second-order effect. If a criminal gains control of your build pipeline, they can inject a backdoor into your software before it's signed and shipped. Your customers then download an "official" update that contains a payload. You become the delivery mechanism for a breach you didn't even know was happening. Your clients aren't getting hit by a random hacker; they're getting hit because they trusted you. We saw a version of this during the SolarWinds mess, though that was a nation-state operation with resources we can't fathom. The parallel here is the target: the supply chain. Where it differs is the entry point. This isn't some complex, multi-stage chain of zero-days. It's an unauthenticated RCE in a widely used tool. It's the digital equivalent of leaving the vault door open and putting a sign on the sidewalk that says "Free Gold Inside." Some will argue that these tools need to be public-facing to facilitate remote collaboration or integration with third-party webhooks. That is a lazy argument. There is almost no legitimate reason for a build server to be wide open to the entire IPv4 address space. If you need webhooks, you use a proxy or an IP allowlist. If your devs are remote, they use a VPN or a hardened gateway. Convenience is a fine goal until it costs you your company's reputation. Look at what happens when these "conveniences" fail. The Snowflake mess, which we've tracked across several recent columns, exposed over 100 million records because of credential theft. ShinyHunters recently claimed 2.2 million records from Kodak. These aren't just numbers; they're the result of attackers finding the path of least resistance. A public-facing TeamCity server is currently the path of least resistance. The cost to fix this for a small firm is nearly zero dollars, provided you have someone who knows how to touch the firewall. You don't need a new vendor or a monthly subscription to a "threat intelligence platform." You just need to stop exposing your internal tooling to the rest of the world. If you're running TeamCity, you have two immediate moves. First, patch it. Now. Then, look at where that server lives. If you can hit your TeamCity login page from your home laptop without being on a VPN or a corporate network, you are effectively hosting a playground for every botnet on the planet. The uncomfortable question here is: how many other "invisible" pieces of infrastructure are you running? Most small shops have a handful of these tools (Jenkins, GitLab runners, old Jira instances) that were set up during a late-night sprint in 2023 and then forgotten. They're the digital equivalent of an old shed in the backyard that you forgot to lock. You don't think about them until you realize someone has been living in them for six months. We've moved past the era where "security through obscurity" works. Attackers aren't guessing your IP addresses; they're using automated scanners that find every single instance of a specific software version across the entire web in minutes. If you are online and unpatched, you are already on a list. I don't trust the vendors who tell you their latest update "solves" these problems. A patch fixes a bug; it doesn't fix a bad architecture. The only sane default is to assume that any tool with "Admin" in the title should never be visible to the public internet. Check your external-facing IP addresses this week. If you see a build server or a management console staring back at you, pull it behind a firewall before someone else decides to log in for you.