CISA Flags TeamCity CVE-2026-63077 RCE Flaw Under Active Exploitation
CISA has confirmed active exploitation of a critical TeamCity deserialization vulnerability, CVE-2026-63077. Here is what website owners and DevOps teams running on-premise build servers need to do next.
The U.S. Cybersecurity and Infrastructure Security Agency has confirmed that a newly disclosed flaw in on-premise JetBrains TeamCity servers is now being exploited in the wild. Tracked as CVE-2026-63077, the vulnerability carries a CVSS score of 9.8 and allows an unauthenticated attacker to execute code remotely by abusing a deserialization weakness in the build server. Because TeamCity often sits deep inside development networks and has privileged access to source code, signing keys, and deployment pipelines, the impact of a successful intrusion can extend well beyond the server itself.
If your team operates TeamCity in any capacity, treat this disclosure as urgent. CISA has added the flaw to the Known Exploited Vulnerabilities catalog, which signals confirmed real-world abuse and typically triggers binding remediation timelines for federal agencies. For private organizations, the same catalog serves as the clearest indicator that patching can no longer wait for a normal change window.
This guide explains what the vulnerability is, why a build server compromise is more dangerous than it may first appear, and how to respond in a way that limits both immediate and downstream risk.
Key Takeaways
- CVE-2026-63077 is a critical deserialization flaw in on-premise TeamCity servers with a CVSS score of 9.8 and unauthenticated remote code execution potential.
- CISA has confirmed active exploitation and added the bug to the Known Exploited Vulnerabilities catalog.
- Self-hosted TeamCity deployments should be upgraded immediately to the version provided by JetBrains and treated as potentially compromised if unpatched.
- Compromised build servers can be used to pivot into source repositories, signing infrastructure, and production deployment pipelines.
- Defenders should combine patching with log review, credential rotation, and network-level controls to reduce the blast radius.
What the Vulnerability Looks Like
The TeamCity CVE-2026-63077 RCE stems from insecure deserialization of untrusted data processed by the on-premise build server. In this case, the affected code path can be reached without authentication, which is what gives the bug its 9.8 severity rating and what makes it attractive to opportunistic attackers.
Because the flaw is unauthenticated, exposure is determined almost entirely by network reachability. Cloud-hosted TeamCity services managed by JetBrains are typically not affected by this class of issue, but self-hosted deployments running in corporate data centers, on developer laptops, or inside cloud VMs are squarely in scope.
Why a Compromised Build Server Is a High-Value Event
A TeamCity server is rarely the final target. Attackers who land on a build server can use that position to steal credentials, inject malicious code into compiled binaries, tamper with signing keys, and pivot into production systems.
This is the same pattern seen in past CI/CD compromises, and it is one reason why a high-severity flaw in TeamCity tends to draw more attention than an equivalent bug in a less privileged application. A single successful exploitation can quietly contaminate every downstream consumer of the build pipeline. For organizations that ship software to external customers, the consequences can include supply-chain compromise that is difficult to detect once the poisoned artifacts are deployed.
Quick Reference: What to Check First
| Area to Review | What to Look For |
|---|---|
| TeamCity version | Confirm whether the server is on the latest vendor-recommended release covering the CVE-2026-63077 fix. |
| Network exposure | Check whether the TeamCity web interface or agent ports are reachable from the internet or from low-trust networks. |
| Admin accounts | Inventory administrator and system accounts that could have been used to create new users or modify build configurations. |
| Build logs and agents | Look for unexpected build steps, unfamiliar agents, or commands that touch credentials, source, or deployment targets. |
| Connected systems | Review access from TeamCity to source repositories, package registries, artifact storage, and production environments. |
Immediate Steps for Running Teams
The first action is straightforward: upgrade on-premise TeamCity to the patched build that JetBrains has released for CVE-2026-63077. Apply the upgrade through your normal change process, but do not delay it for routine scheduling. The Known Exploited Vulnerabilities catalog exists precisely because attackers move faster than monthly patch cycles, and a publicly disclosed unauthenticated RCE on a build server meets every reasonable threshold for emergency change handling.
While you are scheduling or executing the upgrade, restrict access to the TeamCity web interface. If the server must remain partially exposed, place it behind an additional authentication layer and rate-limit the management endpoints.
After patching, assume that any instance which was reachable before the fix may have been probed or compromised. Review TeamCity audit logs for new user accounts, modified build configurations, unfamiliar agents, and unusual outbound connections. Pay particular attention to activity that touches source repositories, signing keys, cloud credentials, and deployment targets, because those are the assets an attacker would most want to abuse next.
Hardening Recommendations Beyond the Patch
Once the immediate risk has been addressed, this disclosure is a useful prompt to revisit the broader security posture of your build infrastructure. TeamCity servers should never sit on the public internet without strong justification. Wherever possible, restrict management access to known IP ranges or to authenticated users behind a VPN. Service accounts used by build steps should be scoped to the minimum permissions required, and long-lived secrets stored in build configurations should be replaced with short-lived credentials issued by a secret manager.
It is also worth reviewing how build artifacts are signed and verified downstream. Network segmentation between the build environment and production systems remains one of the most effective controls, because it limits how far an attacker can move from a compromised CI host.
For perspective on how quickly this category of vulnerability can escalate, see how the recent CVE-2026-66066 Rails Active Storage RCE disclosure followed a similar pattern of unauthenticated exploitation and emergency patching. Build and framework flaws tend to cluster in severity for the same reason: unauthenticated code execution on a network-reachable service leaves defenders very little time to react.
What Website Owners and Agencies Should Do
Even if you do not operate TeamCity directly, this disclosure is worth understanding. A short, direct conversation now is far less costly than a forensic investigation later.
Hosting customers running their own build pipelines on a VPS or dedicated server should also check whether TeamCity is installed in a default or forgotten location.
Frequently Asked Questions
What is CVE-2026-63077?
CVE-2026-63077 is a critical deserialization vulnerability in on-premise JetBrains TeamCity servers that allows unauthenticated remote code execution. It carries a CVSS score of 9.8 and is confirmed to be exploited in the wild.
Is my TeamCity instance affected?
Only self-hosted, on-premise TeamCity deployments are in scope for this advisory. If you run a TeamCity server that your organization installs and manages itself, you need to confirm it has been updated to the version that contains the vendor fix.
Has CISA confirmed active exploitation?
Yes. CISA has added CVE-2026-63077 to its Known Exploited Vulnerabilities catalog, which is reserved for vulnerabilities with confirmed real-world exploitation. Inclusion in the catalog signals that defenders should treat patching as urgent.
What should I do if my TeamCity server was exposed before patching?
Treat the instance as potentially compromised. Patch immediately, review audit logs for unfamiliar users or build changes, rotate any credentials accessible to the server, and check connected source repositories and deployment systems for suspicious activity.
Can I just block external access instead of patching?
Network restrictions are a strong compensating control and should be applied right away, but they are not a substitute for patching. Internal exposure, VPN access, and lateral movement risks still leave a vulnerable server reachable, so the vendor update should be applied as soon as your change process allows.
Conclusion and Action Checklist
The TeamCity CVE-2026-63077 RCE is a textbook example of why build infrastructure deserves the same defensive attention as public-facing production systems. A high-severity, unauthenticated flaw on a network-reachable component is exactly the situation where slow, predictable change processes break down. Use the steps below as a short action checklist to guide your response.
- Confirm whether any on-premise TeamCity servers exist in your environment and which versions they run.
- Upgrade affected servers to the JetBrains release that contains the fix for CVE-2026-63077 as an emergency change.
- Restrict network access to the TeamCity web interface while patching is in progress.
- Review audit logs, user accounts, build configurations, and connected systems for signs of compromise.
- Rotate credentials, signing keys, and tokens that were accessible from the build server.
- Apply longer-term hardening, including segmentation, short-lived secrets, and artifact verification, to reduce the impact of future CI flaws.
