JetBrains warns of critical TeamCity remote code execution flaw

**JetBrains** has issued a warning about a **critical authentication bypass** in **TeamCity On-Premises** that can be chained to **remote code execution**. The notice, covered by **BleepingComputer**, centers on self-hosted TeamCity rather than a managed cloud tier, so any organization running its own build server is in the blast radius until patched or mitigated.

**TeamCity On-Premises** sits on the build and release path: agents pick up jobs, credentials and artifact stores are reachable from the server, and admin-level control usually means full pipeline control. An **authentication bypass** removes the normal gate on who can call privileged APIs or admin endpoints; once that gate is gone, an attacker can push configuration or agent-side actions that execute arbitrary code in the CI environment. That is why the vendor frames the issue as **critical** and ties it directly to **remote code execution**, not a low-impact auth glitch.

For engineers and builders, the risk is concrete. Compromised CI is not a cosmetic bug tracker issue—it is a path to source, secrets, signing keys, and deploy targets. Anyone who uses TeamCity as the system of record for builds should treat this as a priority review of server exposure (internet-facing vs. VPN-only), admin account hygiene, and whether agents run with broad cloud or production credentials.

In the wider market, CI/CD platforms are high-value targets precisely because they already hold trusted automation. **JetBrains** competing with other on-prem and hybrid build systems does not change the operational fact: self-hosted products put patch timing and network posture on the customer. Teams that standardized on TeamCity for Windows/Java-heavy shops or multi-agent fleets need the same urgency they would apply to any critical flaw in the identity layer of their pipeline.

**Takeaway:** inventory every **TeamCity On-Premises** instance, apply JetBrains’ published fix or guidance as soon as it is available, and keep the server off the public internet unless access is tightly controlled. Watch for follow-on guidance on indicators of compromise, forced credential rotation for tokens stored in TeamCity, and any confirmation of active exploitation. If you cannot patch immediately, restrict network access to the web UI and API and audit recent admin and agent activity for unexpected jobs or configuration changes.