On July 10, 2025, security researcher Antoni Tremblay reported a vulnerability to JetBrains through their coordinated disclosure program. The flaw, tracked as CVE-2026-63077, allows unauthenticated remote code execution on all TeamCity On-Premises deployments. JetBrains assigned it a CVSS score of 9.8 out of 10 and released patches in versions 2025.11.7 and 2026.1.3.
The attack requires nothing more than a crafted HTTP request. No credentials, no social engineering, no insider access. If your TeamCity server accepts requests from an attacker, your build environment is compromised.
Timeline
July 10, 2025: Antoni Tremblay submits vulnerability report to JetBrains
[Date unknown]: JetBrains validates the issue and begins patch development
[Date unknown]: Patches released in versions 2025.11.7 and 2026.1.3
[Date unknown]: Public disclosure and advisory published
The gap between discovery and public disclosure isn't specified, but coordinated disclosure typically runs 60-90 days. What matters now: if you're running an earlier version, assume attackers have the details.
Which Controls Failed or Were Missing
This incident exposes three control failures that apply to most CI/CD environments:
Network segmentation was insufficient or absent. TeamCity servers shouldn't accept HTTP requests from the internet or untrusted internal networks. If an unauthenticated attacker can reach your build server, you've already lost the first battle.
Authentication wasn't enforced at the network layer. The vulnerability bypasses application-level authentication entirely. Without defense in depth, a single application flaw becomes a complete breach.
Patch deployment processes weren't fast enough. CI/CD systems change your production code. They deserve the same patch SLA as your perimeter firewall, but most organizations treat them like internal tools that can wait for the next maintenance window.
What the Standards Require
NIST 800-53 Rev 5 addresses these failures directly:
- AC-3 (Access Enforcement) requires you to enforce approved authorizations for logical access. An unauthenticated HTTP request shouldn't reach a system that can execute arbitrary code.
- SC-7 (Boundary Protection) mandates network segmentation and monitoring of communications at managed interfaces. Your build server shouldn't be one HTTP request away from any developer laptop.
- SI-2 (Flaw Remediation) requires you to install security-relevant software updates within organization-defined time periods. For a CVSS 9.8 RCE in your build pipeline, that period should be measured in hours, not weeks.
PCI DSS v4.0.1 applies if your build pipeline touches cardholder data environments:
- Requirement 1.2.1 demands network segmentation to isolate systems. Your CI/CD infrastructure should sit behind multiple network boundaries.
- Requirement 6.3.3 requires security patches for critical vulnerabilities within one month of release. A 9.8 CVSS score qualifies.
ISO/IEC 27001:2022 Control 8.8 (Management of technical vulnerabilities) requires you to obtain timely information about technical vulnerabilities and evaluate exposure. You need a process that flags "unauthenticated RCE in build system" and escalates it above normal patch cycles.
Lessons and Action Items for Your Team
Treat CI/CD infrastructure as Tier 0 assets. Your build server can inject code into production. It deserves the same security posture as your domain controllers. That means:
- Isolated network segments with strict firewall rules
- Jump boxes or VPN requirements for administrative access
- Monitoring and alerting on all authentication attempts
- Patch windows measured in hours for critical vulnerabilities
Implement defense in depth for build systems. Application-level authentication isn't enough. Add:
- Network-level access controls (IP allowlisting, VPN requirements)
- Web application firewalls that can block malformed requests
- Intrusion detection monitoring HTTP traffic to build servers
- File integrity monitoring on build agents
Create a critical patch fast-track process. Standard patch cycles don't work for CVSS 9+ vulnerabilities in your build pipeline. You need:
- Automated alerts when vendors publish critical patches for CI/CD tools
- A decision tree: Can we patch in the next maintenance window? If not, what's the emergency change process?
- Pre-approved downtime windows for security patches (get this in writing from leadership now)
- Rollback procedures tested in advance
Verify your network segmentation today. Run this test: Can a developer laptop send an HTTP request directly to your TeamCity server? If yes, you're vulnerable to the next CVE-2026-63077. Your build infrastructure should require:
- Connection through a bastion host or jump box
- VPN access with multi-factor authentication
- Network policies that block direct HTTP from workstations
Audit your CI/CD tool inventory. Most teams run more build and deployment tools than they realize: Jenkins, GitLab CI, CircleCI, TeamCity, Azure DevOps, GitHub Actions. Each one is a potential entry point. Map them, segment them, and assign patch responsibility.
For TeamCity specifically: If you can't upgrade immediately, JetBrains has published mitigation steps. But understand that mitigation is temporary. A crafted HTTP request is trivial to automate. You're in a race between your patch deployment and attackers scanning for vulnerable instances.
The fix for CVE-2026-63077 is straightforward: upgrade to 2025.11.7 or 2026.1.3. The harder fix is building an organization that can deploy that upgrade within 24 hours of disclosure. Start there.
