CVE-2026-63077 (CVSS 9.8): JetBrains TeamCity’s Unauthenticated RCE Hits Active Exploitation — CISA Patch Deadline August 8

Your CI/CD pipeline is the circulatory system of modern software delivery. Every credential, every build secret, every deployment key flows through it. Now imagine an attacker strolling in through an unlocked front door — no username, no password, just an HTTP request — and seizing the keys to your entire software factory. That is not a theoretical threat model. It is exactly what CVE-2026-63077 enables, right now, against every unpatched JetBrains TeamCity On-Premises server connected to the internet.

CISA officially confirmed active exploitation of this critical deserialization flaw on August 5, 2026, adding it to the Known Exploited Vulnerabilities (KEV) catalog and issuing a binding directive to all U.S. Federal Civilian Executive Branch agencies: patch by August 8, 2026. That deadline is today. If you are running TeamCity On-Premises in your organization — whether in Gurugram, Bengaluru, Hyderabad, or anywhere else — this article is your action brief.

CVE-2026-63077: What Is This Vulnerability?

JetBrains published its security advisory for CVE-2026-63077 on July 27, 2026, disclosing a critical flaw rooted in the deserialization of untrusted data within TeamCity’s agent communication subsystem. Both the NVD and JetBrains rate the flaw at CVSS 9.8 — a score reserved for vulnerabilities that are remotely exploitable, require no authentication, and carry maximum impact across confidentiality, integrity, and availability.

TeamCity is one of the most widely deployed CI/CD platforms in enterprise environments globally. Organizations use it to automate the full software delivery lifecycle: source-control integration, test execution, artifact generation, and deployment. JetBrains offers both a cloud-hosted and an on-premises edition; it is the on-premises edition, installed and managed by the organization on its own infrastructure, that is exclusively vulnerable to this flaw.

The fact that this vulnerability carries a CVSS 9.8 and enables completely unauthenticated code execution puts it in the same danger tier as the TeamCity authentication bypass flaws of early 2024 (CVE-2024-27198 and CVE-2024-27199) — which were weaponized by North Korean APT actors within days of disclosure.

Inside the Attack: How the Agent Polling Protocol Becomes a Weapon

To understand why this vulnerability is so dangerous, you need to understand how TeamCity agents work. In a standard TeamCity On-Premises deployment, build agents run on separate servers or virtual machines and continuously poll the TeamCity server over HTTP(S) to pick up new build jobs. This polling channel is by design lightweight and accessible: agents need to communicate frequently without complex per-request authentication.

CVE-2026-63077 exploits a flaw in how the TeamCity server processes the data it receives on this agent polling endpoint. When an attacker sends a specially crafted HTTP request to this endpoint, the server deserializes attacker-controlled data without adequate validation. In Java-based applications, deserialization of untrusted objects is notoriously dangerous — it can trigger arbitrary code execution through “gadget chains” embedded in widely-used library classes, all before any authentication check fires.

According to security researchers at Rapid7, the attack requires only HTTP(S) access to the TeamCity server — no valid credentials, no prior foothold. An attacker who can reach the server on the network can execute arbitrary operating system commands with the privileges of the TeamCity server process. On many production deployments, that process runs with elevated or administrative OS privileges.

What makes this particularly dangerous is the attack’s simplicity. No phishing is required. No credential is needed. No multi-step exploit chain to assemble. A single well-formed HTTP request is sufficient to get full command execution on the server.

From One HTTP Request to Full Software Supply-Chain Control

Initial code execution is only the beginning. Once inside, a sophisticated attacker pursuing a supply-chain strategy will move methodically through what TeamCity stores and controls:

Post-Exploitation Target	What Attackers Obtain	Downstream Impact
VCS credentials & SSH keys	Git tokens, deploy keys for source repos	Source code theft, malicious commits
Cloud & deployment secrets	AWS/Azure/GCP API keys, Kubernetes configs	Infrastructure takeover, data exfiltration
Build artifact pipeline	Ability to inject malicious code pre-signing	Trojanized software shipped to customers
TeamCity user database	Admin accounts, API tokens	Persistent access surviving credential resets
Build agent trust relationships	Control over the entire agent farm	Lateral movement across build infrastructure

This is precisely why CISA treats CI/CD platform compromises with the same urgency as perimeter firewall vulnerabilities. A compromised TeamCity server is not just a single breached host — it is a master key to your software factory and everything downstream of it. Think about your clients, your customers, and in the Indian IT context, the global enterprises whose applications your teams build and maintain. A poisoned build artifact can travel all the way to production before anyone notices.

For a vivid illustration of how devastating supply-chain attacks through developer tooling can be, consider the Shai-Hulud npm worm (CVE-2026-45321) covered earlier on this blog — 420 packages and two billion monthly installs compromised through a single poisoned dependency. A deliberate, targeted TeamCity compromise could enable a similar scenario but with surgical precision and full control over which builds are poisoned.

The India Angle: Why DevOps and Engineering Teams Here Must Act Now

India is the world’s largest exporter of software services and products. Engineering teams across Bengaluru, Hyderabad, Pune, Chennai, and the NCR corridor use JetBrains tools extensively — JetBrains’ developer tools (IntelliJ IDEA, PyCharm, GoLand) and TeamCity enjoy strong adoption across Indian IT services giants and fast-growing product startups alike.

Many of these teams run TeamCity On-Premises for compliance reasons, data residency requirements under India’s Digital Personal Data Protection Act, or because they are managing sensitive IP that cannot reside on external cloud infrastructure. That compliance-driven preference for on-premises CI/CD is precisely what places them in the crosshairs of CVE-2026-63077.

Beyond individual organizations, consider the supply-chain dimension: Indian IT services firms build and maintain software for banks, healthcare providers, government agencies, and critical infrastructure operators globally. A compromised build pipeline at an Indian outsourcing firm is a supply-chain attack on every client downstream. The stakes are not merely organizational — they are systemic.

Additionally, TeamCity servers exposed on port 8111 (the default HTTP port) are routinely indexed by internet scanners. Shodan and similar tools already have these servers mapped. After a CVE disclosure of this severity, automated exploitation typically begins within hours.

What You Should Do Right Now: Sanjay’s Defence Blueprint

This is not a vulnerability to schedule at the next maintenance window. The CISA August 8 federal deadline, combined with confirmed active exploitation, demands immediate action. Here is the prioritized response sequence:

1. Inventory all TeamCity On-Premises instances immediately. Shadow IT and legacy build servers are easy to miss. Audit your network for any host listening on TeamCity’s default ports (8111 HTTP, 443 HTTPS). Check on-premises servers, cloud VMs, containers, and co-located infrastructure. If you cannot confidently enumerate your CI/CD footprint, that is itself a zero-trust gap to fix.
2. Prioritize internet-facing instances. Any TeamCity server reachable from an untrusted network is at highest risk and should be treated as potentially compromised until patched and reviewed. Immediately restrict inbound access at the firewall level if you cannot patch instantly.
3. Apply the official patch — update to TeamCity 2025.11.7 or 2026.1.3. Follow the JetBrains security advisory for detailed upgrade instructions. If an immediate upgrade is not feasible, install the security patch plugin, available for TeamCity 2017.1 and later from JetBrains’ download server. This plugin mitigates the specific deserialization attack vector while a full upgrade is planned.
4. Rotate all secrets stored in TeamCity. VCS credentials, cloud API keys, deployment tokens, service account passwords, and signing certificates should all be considered potentially compromised if your instance was unpatched and internet-accessible after July 27. Rotate them at the source systems, not just in TeamCity.
5. Review build agent network segmentation. Build agents should reach the TeamCity server only on required ports, from known IP ranges. The TeamCity server itself should not have unrestricted outbound access or direct connectivity to production systems. Microsegmentation is not optional — it is the difference between a contained incident and a supply-chain catastrophe.
6. Audit TeamCity logs from July 27 onwards. Look for unexpected build configurations, new admin account creation, anomalous artifact uploads, unusual process execution from the TeamCity server process, and unexpected external network connections. Threat actors typically scan and exploit within hours of a public advisory.
7. Brief your SOC. If you have a managed SOC or NOC, brief them on CVE-2026-63077 immediately. Tuned detections should fire on: incoming HTTP requests to TeamCity agent endpoints from unexpected IP ranges; new user account creation in TeamCity; anomalous credential access to VCS systems or cloud platforms originating from the TeamCity server host; and modifications to build configurations or artifact repositories.

Zero-trust architecture principles apply directly here. In a mature zero-trust posture, your CI/CD server is treated as a protected workload with explicit, policy-controlled access — not as a trusted internal host with broad network permissions. Just as you would not allow unauthenticated access to your FortiGate management plane, you should not allow unauthenticated HTTP access to your TeamCity agent endpoint from arbitrary networks. Microsegmentation, least-privilege service accounts, and real-time monitoring of build infrastructure are non-negotiable in a modern security posture. Read more about Sanjay’s zero-trust and network security consulting practice for how these principles apply across your infrastructure.

Frequently Asked Questions

Is my TeamCity Cloud instance affected by CVE-2026-63077?

No. JetBrains confirmed that TeamCity Cloud customers require no action — patches were deployed to the cloud infrastructure ahead of the public advisory. CVE-2026-63077 exclusively affects on-premises deployments where you manage the TeamCity server yourself. If you are uncertain whether your deployment is cloud or on-premises, check whether your TeamCity URL is hosted on a JetBrains-managed domain or on your own domain/IP.

What if I cannot patch immediately? Are there effective workarounds?

JetBrains offers a security patch plugin compatible with TeamCity 2017.1 and later as a temporary measure — this mitigates the specific attack vector while a full upgrade is scheduled. As a defence-in-depth measure, restrict network access to the TeamCity server so that only known, trusted build agents and administrators can reach the agent polling endpoint. This reduces the attack surface but should not replace patching. Full upgrade to 2025.11.7 or 2026.1.3 is the only complete remediation, as JetBrains has stated there are no workarounds for the underlying deserialization issue.

How do I know if my TeamCity server has already been compromised?

Post-exploitation indicators include: unexpected processes spawned by the TeamCity server process; new or modified TeamCity admin accounts; unusual network connections from the TeamCity host to external IPs; newly scheduled build configurations or modifications to existing ones; anomalous credential access patterns in your VCS or cloud platform audit logs; and unexpected artifacts uploaded to your artifact repository. Forensically review TeamCity server logs from July 27 onwards — the day JetBrains published the advisory. Threat actors routinely scan for and exploit new CVEs within hours of public disclosure.

How does this relate to previous TeamCity vulnerabilities like CVE-2024-27198?

CVE-2026-63077 is a newly discovered, distinct vulnerability — not a bypass or variant of the 2024 authentication bypass flaws (CVE-2024-27198 and CVE-2024-27199) that were weaponized by North Korean state actors. However, the pattern is consistent: TeamCity’s agent communication and authentication layers have historically been high-value attack surfaces. The lesson is that CI/CD platforms must be treated like network perimeter devices — patched on emergency timelines, not routine ones. Organizations that patched the 2024 flaws but have not kept pace with subsequent updates may still be exposed. For context on how the FortiGate management plane requires the same perimeter-level urgency, see our recent coverage of CVE-2025-68686 FortiOS SSL-VPN patch bypass.

The Bigger Picture: CI/CD Security Belongs in Your Perimeter Strategy

CVE-2026-63077 is a reminder that modern software supply chains are only as secure as the tooling that builds them. For years, CI/CD platforms lived in a comfortable grey zone — “internal infrastructure,” not quite as exposed as public web servers, not quite as tightly hardened as firewalls. That thinking is obsolete. Attackers have recognized that CI/CD pipelines are extraordinarily high-reward targets: one successful compromise can yield credentials for dozens of downstream systems, persistent access through build configurations, and a stealthy route to poison software that reaches clients and customers worldwide.

At P J Networks, our zero-trust engagements explicitly include the build pipeline as a protected network segment. We apply the same microsegmentation principles to CI/CD infrastructure that we apply to financial systems and OT environments: least-privilege service accounts, explicit policy-based access controls, real-time SOC monitoring, and regular security posture assessments.

If you are unsure whether your CI/CD environment is adequately protected — or whether your organization’s zero-trust architecture covers DevOps infrastructure — now is the moment to find out, before an attacker does it for you.

---

Ready to assess your CI/CD and DevOps security posture? Contact Sanjay Seth for a security assessment. P J Networks works with engineering and operations teams across India to close the gaps that critical vulnerabilities like CVE-2026-63077 expose — from build pipeline hardening to full zero-trust architecture reviews.