Listen to this Post
A New TeamCity Security Crisis Puts CI/CD Infrastructure Under Pressure
A critical security vulnerability in JetBrains TeamCity On-Premises has emerged as one of the most serious developer-infrastructure security issues reported this week. Tracked as CVE-2026-63077, the flaw can allow an unauthenticated remote attacker with HTTP(S) access to a vulnerable TeamCity server to bypass authentication and execute arbitrary operating-system commands.
The danger is not limited to the TeamCity application itself. CI/CD servers frequently sit at the center of software development environments, connecting source-code repositories, build agents, deployment systems, credentials, cloud services and artifact storage. A compromise at this layer can therefore become a gateway into much larger portions of an organization’s infrastructure.
JetBrains has confirmed the vulnerability and released fixes in TeamCity 2025.11.7 and 2026.1.3. The company says TeamCity Cloud customers do not need to take action because the necessary protections have already been applied.
The Vulnerability Was Reported Privately
JetBrains says the vulnerability was privately reported on July 10, 2026, by security researcher Antoni Tremblay under its coordinated disclosure process. The company subsequently assigned the flaw CVE-2026-63077 and prepared fixes before publicly disclosing the issue.
CVE-2026-63077 Carries Critical Severity
The National Vulnerability Database lists CVE-2026-63077 with a CVSS 3.1 score of 9.8, placing it firmly in the critical category. The vulnerability is described as an unauthenticated remote-code-execution issue affecting TeamCity versions before 2026.1.3 and 2025.11.7.
Authentication Can Be Bypassed
The central problem is particularly alarming because an attacker does not need a valid TeamCity account to exploit the vulnerability. According to JetBrains, an attacker with HTTP(S) access can abuse the TeamCity agent polling protocol to bypass authentication checks.
Remote Code Execution Changes the Risk Completely
Authentication bypass alone would already be serious, but CVE-2026-63077 goes further. A successful attacker can execute arbitrary operating-system commands with the privileges of the TeamCity server process.
That effectively transforms a vulnerable TeamCity installation from a software-management problem into a potential server-compromise incident.
Why CI/CD Servers Are Especially Valuable Targets
CI/CD infrastructure is unusually attractive to attackers because it often has legitimate access to other systems. Build servers may interact with source repositories, package registries, cloud platforms, deployment environments, signing systems, artifact stores and internal services.
A compromised CI/CD server can therefore provide attackers with opportunities that are much broader than those available from an ordinary web server.
Credentials Could Become a Major Concern
JetBrains warns that depending on the privileges assigned to the TeamCity server process, successful exploitation could expose TeamCity data, configurations and stored credentials.
That makes credential exposure one of the most important consequences organizations should consider when assessing the incident.
Build Artifacts Could Also Be Put at Risk
The danger extends beyond confidential information. JetBrains notes that exploitation could allow attackers to modify server state and potentially compromise the integrity of build artifacts and downstream CI/CD pipelines.
For organizations that automatically deploy software after successful builds, this creates a particularly dangerous scenario: an attacker could potentially interfere with the software-production chain itself.
The Supply-Chain Dimension Is What Makes This Vulnerability Dangerous
A compromised developer workstation can be contained. A compromised CI/CD platform can be considerably harder to contain because it may have trusted relationships with dozens of other systems.
The deeper concern is therefore not simply, “Can someone compromise TeamCity?” It is, “What does the TeamCity server trust after it has been compromised?”
All TeamCity On-Premises Versions Are Affected
JetBrains states that all TeamCity On-Premises versions are affected by CVE-2026-63077. This significantly expands the population that administrators need to investigate.
The issue does not apply to TeamCity Cloud customers, according to JetBrains, which says the required protections have already been applied to the cloud environment and that it has found no evidence of exploitation there through this vulnerability.
The Correct Fixed Versions Are 2025.11.7 and 2026.1.3
Administrators running affected TeamCity On-Premises installations should upgrade to 2025.11.7 or 2026.1.3.
JetBrains released both versions on July 27, 2026. Its download documentation identifies TeamCity 2026.1.3 as the current release and TeamCity 2025.11.7 as the corresponding updated 2025.11 branch.
The Fixes Contain More Than One Security Improvement
The urgency is not exclusively about CVE-2026-63077. JetBrains says the 2026.1.3 and 2025.11.7 maintenance releases address more than 20 security vulnerabilities each, making the updates substantially more valuable than a single-CVE patch.
This is another reason administrators should favor a complete supported upgrade rather than treating CVE-2026-63077 as an isolated issue.
A Security Patch Plugin Is Also Available
Organizations that cannot immediately upgrade have another option. JetBrains has released a security patch plugin that can address CVE-2026-63077 on TeamCity versions 2017.1 and newer.
However, JetBrains explicitly recommends upgrading to the latest version because the standalone security plugin only addresses this particular vulnerability and does not provide all the security improvements contained in the newer releases.
Older TeamCity Environments Deserve Extra Attention
The existence of a patch plugin for installations dating back to TeamCity 2017.1 highlights an important operational reality: some organizations maintain development infrastructure for years.
Long-lived infrastructure can become difficult to upgrade because of plugins, integrations, build configurations and legacy dependencies. That operational complexity can turn a security patch into a major project.
Internet Exposure Raises the Stakes
JetBrains recommends limiting network access to TeamCity servers to trusted networks whenever possible.
The company specifically warns that internet-facing TeamCity servers can present attackers with potential entry points, even when only the login screen or REST API is exposed.
VPN Access Can Reduce the Attack Surface
For internet-facing TeamCity installations, JetBrains recommends considering VPN access or an additional security layer.
The goal is simple: if the server does not need to be directly reachable from the public internet, removing that exposure can dramatically reduce the number of potential attackers who can attempt exploitation.
Least Privilege Matters After Exploitation
JetBrains also recommends running the TeamCity server with the minimum operating-system privileges required for normal operation.
This does not eliminate the vulnerability, but it can reduce the damage caused if exploitation succeeds.
A vulnerable application running with administrative privileges can potentially produce a far more severe incident than the same application operating under a tightly restricted account.
Keep TeamCity Servers Separate From Build Agents
JetBrains recommends deploying TeamCity servers on dedicated hosts separate from build agents.
This architectural separation matters because CI/CD environments naturally involve execution. Build agents are designed to run code, while the TeamCity server coordinates those activities.
Keeping these roles separated can create an additional security boundary that makes lateral movement more difficult.
TeamCity 2026.1 Already Represents a Major Security Shift
The vulnerability arrives shortly after TeamCity 2026.1 introduced broader changes to the platform, including new CLI and MCP capabilities and other CI/CD improvements.
The same release also established a newer versioning direction for TeamCity On-Premises and introduced a Java 21 requirement for the TeamCity server and build agents.
The Timing Makes Rapid Patching Even More Important
CVE-2026-63077 was publicly disclosed on July 27, while the current date is July 31. That leaves administrators with only a short window between disclosure and widespread security awareness.
Even though JetBrains says it was not aware of active exploitation when its advisory was published, attackers often study newly disclosed vulnerabilities quickly, particularly when the affected software is widely deployed and the vulnerability provides unauthenticated remote code execution.
The Absence of Known Exploitation Is Not a Safety Guarantee
There is an important distinction between “no exploitation is currently known” and “the vulnerability is not being exploited.”
The former describes available evidence at a specific point in time. It does not guarantee that attackers have not discovered the vulnerability independently or that exploitation will not begin after technical details become public.
Security Teams Should Treat This as an Incident-Response Question
Organizations should not simply install the patch and close the ticket.
For internet-accessible TeamCity installations, security teams should also consider reviewing authentication events, server logs, process activity, unexpected configuration changes, new accounts, unusual network connections and suspicious modifications to build configurations or artifacts.
Credentials Should Be Considered Potentially Exposed
If an affected TeamCity server may have been compromised before patching, organizations should assess which credentials were accessible to that server.
Depending on the environment, this could include repository credentials, cloud access keys, deployment secrets, package-registry credentials, API tokens or other sensitive automation credentials.
Where compromise is suspected, rotating relevant secrets should become part of the response rather than relying solely on patching.
CI/CD Integrity Deserves the Same Attention as Confidentiality
Security incidents are often evaluated through the lens of stolen information.
For CI/CD platforms, integrity can be equally important.
If an attacker modifies a build configuration, pipeline definition, artifact or deployment process, the organization could unknowingly distribute compromised software even after the original TeamCity server has been repaired.
What Makes CVE-2026-63077 Different From a Typical Web Vulnerability
A conventional web vulnerability might expose a database record or allow manipulation of a particular application feature.
CVE-2026-63077 reaches deeper into the development environment because the vulnerable system is itself responsible for coordinating software delivery.
The compromise therefore potentially crosses the boundary between application security and supply-chain security.
Deep Analysis
Command 1: Identify Your TeamCity Deployment
Security teams should first determine whether the organization operates TeamCity On-Premises, because TeamCity Cloud is not affected according to JetBrains.
An internal asset inventory should identify every TeamCity server, its version, hostname, network exposure and relationship to build agents.
Command 2: Verify the Installed Version Safely
Administrators can verify their installed TeamCity version through the TeamCity administration interface or their organization’s approved software-inventory system.
The objective is to determine whether the server is running 2025.11.7, 2026.1.3, or another version.
Command 3: Review Internet Exposure
Network teams should identify whether TeamCity servers are directly reachable from the public internet.
Public exposure should be considered a priority because JetBrains specifically identifies HTTP(S) reachability as relevant to exploitation.
Command 4: Review Server Logs
Security teams should examine TeamCity logs for unusual requests, unexpected authentication behavior, abnormal agent activity and unexplained administrative changes.
The investigation should cover the period before the patch was installed, not just activity after remediation.
Command 5: Inspect Pipeline Changes
Organizations should compare recent build and deployment configuration changes against authorized changes.
Unexpected modifications are particularly important because attackers compromising CI/CD infrastructure may attempt to establish persistence or manipulate future builds.
Command 6: Review Stored Secrets
Teams should identify credentials accessible to the affected TeamCity server.
Secrets should be categorized according to privilege and business impact so that the most sensitive credentials can be rotated first if compromise is suspected.
Command 7: Check Downstream Systems
A TeamCity investigation should not stop at the TeamCity host.
Security teams should examine connected repositories, artifact systems, cloud accounts, deployment platforms and build agents for suspicious activity.
Command 8: Isolate Before Investigating When Necessary
If there are credible indicators of compromise, organizations should follow their established incident-response procedures and consider restricting network access to the affected server.
The objective is to preserve evidence while reducing the attacker’s ability to move laterally.
Command 9: Patch, Then Validate
After applying the official TeamCity update or security patch, administrators should verify that the server is actually running the intended fixed version and that normal CI/CD operations continue to function.
A patch that was downloaded but never successfully activated does not constitute remediation.
Command 10: Reduce Future Exposure
Once the immediate issue is resolved, organizations should reconsider whether TeamCity needs public exposure at all.
VPN access, network segmentation, dedicated hosts, least-privilege service accounts and continuous monitoring can substantially strengthen the architecture around CI/CD infrastructure.
What Undercode Say:
CI/CD Has Become Critical Infrastructure
Modern software companies increasingly depend on automated pipelines for everything from testing to production deployment.
That means CI/CD servers should no longer be treated as ordinary developer tools.
They are part of the
One Authentication Bypass Can Become a Much Larger Incident
CVE-2026-63077 demonstrates how quickly an authentication weakness can escalate when it exists inside a privileged automation platform.
An attacker does not necessarily need to compromise every downstream system individually.
The attacker may instead look for one trusted system that already has access to them.
The Build Pipeline Is a Trust Engine
A CI/CD platform effectively says, “This code is trusted enough to build, package or deploy.”
That trust makes the platform extremely valuable.
If attackers gain control of that decision-making layer, the consequences can extend far beyond the original server.
Software Supply Chains Need Infrastructure Security
Supply-chain security discussions often focus on malicious packages, compromised dependencies and third-party vendors.
But the infrastructure that builds and distributes software deserves equal attention.
A compromised build server can potentially influence what software ultimately reaches customers.
Credentials Are Often the Hidden Prize
Attackers do not necessarily need to steal source code immediately.
Credentials can provide a more durable path into an organization.
Cloud tokens, deployment secrets and repository credentials can enable follow-up attacks long after the original vulnerability has been patched.
Patch Management Must Be Fast
The release of fixes alongside public disclosure gives defenders an important advantage.
The organizations that benefit most are those capable of identifying vulnerable assets quickly and applying updates without waiting for a crisis.
Asset Inventory Is a Security Control
If an organization does not know where its TeamCity servers are located, it cannot reliably determine whether it is vulnerable.
This sounds basic, but forgotten development infrastructure remains a recurring problem across enterprise environments.
Legacy Infrastructure Creates Security Debt
JetBrains’ security patch plugin supporting TeamCity 2017.1 and later is a reminder that enterprise software can remain operational for many years.
The longer an environment remains unchanged, the harder emergency upgrades can become.
Network Segmentation Can Limit Damage
A TeamCity server should not have unrestricted access to every internal resource simply because it is convenient.
Segmentation can turn a successful initial compromise into a contained security event rather than an enterprise-wide breach.
Least Privilege Is Still One of the Strongest Defenses
No application should receive more operating-system permissions than it needs.
When remote code execution vulnerabilities appear, least privilege can determine whether the attacker gains limited control or obtains a much more powerful foothold.
Cloud and On-Premises Security Are Not Identical
The fact that TeamCity Cloud does not require customer action in this incident illustrates an important difference between managed and self-managed infrastructure.
Cloud customers benefit from security controls operated by the provider.
On-premises customers inherit more responsibility for patching, exposure management and incident response.
Security Updates Should Be Treated as Operational Events
Applying a security update should not be an isolated technical task.
Teams should understand what changed, what systems depend on the server and whether any suspicious activity occurred before remediation.
The Most Important Question Is What Happened Before the Patch
A patched server is not necessarily a clean server.
If an attacker exploited the vulnerability before remediation, the patch closes the vulnerability but does not automatically remove persistence, stolen credentials or malicious modifications.
CI/CD Monitoring Needs More Attention
Many organizations heavily monitor production systems while giving developer infrastructure comparatively little visibility.
That balance needs to change.
A build server can be just as strategically important as a production server because it may possess trusted pathways into production.
Automated Deployment Magnifies Risk
Organizations using continuous deployment should be especially cautious.
If the TeamCity environment can automatically push software into production, a compromise could potentially turn a security incident into a software-integrity incident.
The Absence of Known Exploitation Should Encourage Action, Not Complacency
JetBrains reported no known active exploitation at disclosure.
That is good news, but it should be interpreted as an opportunity to patch before exploitation becomes widespread—not as a reason to delay.
Security Teams Should Assume Attackers Are Watching
Critical vulnerabilities with a 9.8 CVSS score and unauthenticated RCE capabilities naturally attract attention.
The question for defenders is therefore not whether attackers will eventually become interested.
It is whether vulnerable systems will still be exposed when they do.
The Best Defense Is Architectural
Patching is essential.
But the stronger long-term strategy combines patching with segmentation, restricted access, dedicated infrastructure, least privilege, secret management and monitoring.
CI/CD Security Is Becoming a Board-Level Concern
As companies rely increasingly on automated software delivery, attacks against development infrastructure can create business-level consequences.
Security leaders should therefore include CI/CD platforms in broader risk assessments rather than leaving them solely under developer operations.
Developers and Security Teams Need Shared Visibility
Development teams know how pipelines work.
Security teams understand adversarial behavior.
CVE-2026-63077 shows why both perspectives need to meet in the middle.
A Fast Patch Is Good; A Verified Patch Is Better
Organizations should verify that the update was successfully installed and that vulnerable instances no longer remain.
Automated asset scanning and configuration management can make this process repeatable.
The Attack Surface Should Be Reduced After the Crisis
Once the immediate vulnerability is addressed, teams should ask why the TeamCity server was reachable in the first place.
Reducing unnecessary exposure can protect against the next vulnerability even before a patch becomes available.
Security Debt Eventually Becomes Operational Risk
Legacy TeamCity versions, outdated plugins, excessive privileges and direct internet exposure may appear manageable individually.
Together, they create an environment where a single critical vulnerability can become significantly more damaging.
CVE-2026-63077 Is a Warning for the Entire DevOps Ecosystem
The incident is bigger than TeamCity.
It is another reminder that modern attackers increasingly have reasons to target the systems used to create software rather than only the systems running software.
The Developer Environment Is Part of the Production Environment
When a development platform can build, sign, package or deploy production software, the traditional distinction between “development” and “production” becomes increasingly artificial.
Both environments must be protected according to the level of trust they possess.
What Organizations Should Do Now
Teams running TeamCity On-Premises should identify all installations, determine their versions, prioritize internet-facing systems, upgrade to 2025.11.7 or 2026.1.3, or apply JetBrains’ security patch plugin where an immediate upgrade is not possible.
Organizations should then review logs and credentials for signs of compromise and evaluate connected systems if an affected server was exposed before remediation.
✅ CVE-2026-63077 Is a Real Critical TeamCity Vulnerability
JetBrains officially confirms CVE-2026-63077 as a critical vulnerability affecting TeamCity On-Premises. NVD records the JetBrains-assigned CVSS 3.1 score as 9.8 Critical.
❌ The Claim That It Was Simply “Fixed in 2025” Is Misleading
The original
✅ Unauthenticated Remote Code Execution Is Confirmed
JetBrains confirms that an unauthenticated attacker with HTTP(S) access can bypass authentication through the agent polling protocol and execute arbitrary operating-system commands with the privileges of the TeamCity server process.
Prediction
(-1) Attackers Will Likely Increase Scanning for Exposed TeamCity Servers
The combination of unauthenticated access, remote code execution and a 9.8 severity rating makes CVE-2026-63077 an attractive target for automated scanning.
(-1) Unpatched Internet-Facing Servers Face the Greatest Risk
Organizations that leave vulnerable TeamCity instances publicly accessible could face increasing attack pressure as more security researchers and attackers analyze the vulnerability.
(-1) Credential Theft Could Become a Secondary Consequence
If attackers compromise vulnerable servers, stored credentials and configuration information may become valuable targets, potentially allowing attacks to continue beyond the original TeamCity host.
(+1) Fast Patch Adoption Can Significantly Reduce the Threat
JetBrains has already provided fixes and a security patch plugin, giving defenders concrete remediation options.
(+1) Network Segmentation Will Reduce Future Exposure
Organizations that move TeamCity behind VPNs, restrict access to trusted networks and separate servers from build agents will be better positioned against future CI/CD vulnerabilities.
(-1) CI/CD Platforms Will Remain High-Value Targets
As software delivery becomes increasingly automated, attackers will continue looking for weaknesses in the systems responsible for building and deploying applications.
(+1) Security Awareness Around Developer Infrastructure Should Improve
Incidents such as CVE-2026-63077 reinforce the idea that development infrastructure deserves the same security attention traditionally given to databases, identity systems and production servers.
Final Outlook
CVE-2026-63077 is not merely another vulnerability to add to a patching spreadsheet. It is a reminder that the software-development pipeline itself has become critical infrastructure.
A single unauthenticated vulnerability in a trusted CI/CD server can potentially expose credentials, alter configurations, compromise build artifacts and create pathways toward downstream systems.
For TeamCity On-Premises administrators, the safest strategy is straightforward: identify every deployment, patch immediately, restrict unnecessary network access, review activity before remediation and treat potentially exposed credentials as a serious security concern.
The good news is that defenders have the fixes before confirmed active exploitation has been reported by JetBrains. The window to act is therefore open—but with a critical 9.8 vulnerability now public, organizations should not assume that window will remain open for long.
▶️ Related Video (80% Match):
🕵️📝Let’s dive deep and fact‑check.
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
References:
Reported By: x.com
Extra Source Hub (Possible Sources for article):
https://www.linkedin.com
Wikipedia
OpenAi & Undercode AI
Image Source:
Unsplash
Undercode AI DI v2
🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]
📢 Follow UndercodeNews & Stay Tuned:
𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky | 🐘Mastodon | 📺Youtube
