A CVSS score of 9.8 doesn’t leave much room for interpretation. That’s what JetBrains slapped on CVE-2026-63077, a flaw in on-premises TeamCity that lets an attacker with zero credentials run arbitrary OS commands on the server. No phishing email required. No stolen password. Just a crafted request against a build server that’s sitting on the internet, or worse, sitting quietly inside your network where nobody’s watching it closely. JetBrains has patched it in 2025.11.7 and 2026.1.3, and if you run TeamCity On-Premises, that update is not optional homework for next sprint. This is the kind of bug that reframes what cybersecurity actually means for a lot of engineering teams: it’s not just about the app you ship, it’s about the machine that builds it.

Build Server, Full Access

Treat a compromised TeamCity instance like a compromised app server and you’ll underestimate the damage by an order of magnitude. A CI/CD platform typically holds deployment credentials, cloud API keys, signing certificates, and read access to every private repository it builds. It’s the one system in your environment explicitly designed to reach into everything else. That’s the whole point of continuous integration: pull code, run it, push artifacts, deploy them. An attacker who lands OS-level command execution on that box doesn’t need to escalate laterally through your network the slow way. The lateral movement is already built into the product.

This is why unauthenticated RCE in build tooling keeps showing up as a favorite target. It’s a smaller blast radius to find than a zero-day in a widely deployed browser, but the payoff, source code, secrets, a foothold in every downstream system the pipeline touches, is enormous. If your incident response plan treats “the build server got popped” as a routine ticket instead of a full supply chain event, that plan needs a rewrite.

The Payload That Comes Next

Getting command execution is step one. Staying there quietly is the harder problem for attackers, and it’s where a tool like AutoIT keeps earning its keep. AutoIT is a legitimate Windows scripting language built for automating routine tasks, and it’s been a fixture in the malware ecosystem for years precisely because it’s boring. It compiles to a standalone executable, it doesn’t look unusual running on a Windows host, and it’s flexible enough to do the heavy lifting of process injection: allocating memory in a remote process, writing shellcode into it, and hijacking execution to run malicious code under the identity of something your monitoring already trusts.

Recent analysis from the SANS Internet Storm Center walked through exactly this pattern: an AutoIT-based injector performing the full sequence needed to plant a payload inside a legitimate process, using nothing more exotic than API calls the language has supported for years. That’s the practical link between an RCE like the TeamCity flaw and actual damage. The initial exploit gets you a foothold. The injector is what turns that foothold into a persistent, camouflaged presence that blends into normal process activity on the host.

The Cybersecurity Blind Spot in Your Pipeline

Most threat detection tooling is tuned for what happens on laptops and public-facing web apps. Build servers, internal admin panels, and CI runners often get a fraction of that scrutiny, even though they hold more leverage than almost anything else in the environment. Kaspersky’s writeup on the group tracked as Mirage Kitten this week is a useful reminder of where the sophistication in these campaigns actually lives: not in the initial access, which is often mundane, but in the tunneling and backdoor infrastructure built to survive discovery. Their newly documented BridgeHead and ArcBridge tools exist for exactly one purpose, keeping a covert channel open after the noisy part of the intrusion is over.

Put those two threads together and you get the real lesson. Defense in depth isn’t a slogan, it’s the only thing that catches an attacker between the entry point and the objective. A firewall rule that should have blocked external access to TeamCity’s management interface, brute-force protection on any exposed admin login, and endpoint monitoring tuned to flag unusual child processes spawned by build agents are three separate layers. Any one of them catching the activity buys you the time an unauthenticated RCE otherwise erases.

Hardening the Build Server This Week

Security hardening for CI/CD infrastructure isn’t glamorous work, which is exactly why it tends to slip. It’s worth treating as its own category of asset, not an afterthought bolted onto general server patching.

• Patch TeamCity On-Premises to 2025.11.7 or 2026.1.3 immediately, and confirm the version on every instance, not just the ones you remember exist.
• Pull the TeamCity admin interface off the public internet if it’s there now. Put it behind a VPN or bastion host, full stop.
• Audit what secrets and credentials your build agents can reach. Rotate anything a compromised runner could have exfiltrated, and scope service accounts down to only what each pipeline actually needs.
• Enable logging on build agent process creation and outbound network connections, then actually route those logs somewhere a human or a detection rule will see them.
• Run tabletop incident response drills that specifically assume the build server, not the web app, is the compromised asset. Most IR plans have never rehearsed that scenario.

None of this requires a specific vendor or product. It requires treating the pipeline as a first-class target, because attackers already do.

Sources

• Critical TeamCity Flaw Could Let Attackers Run OS Commands Without Logging In
• AutoIT Payload Injector
• Mirage Kitten targets Middle East and Africa region with new malware