Listen to this Post
A Dangerous Weakness Inside the CI/CD Pipeline
Modern software development depends on automation. Developers push code, continuous integration systems compile it, tests run automatically, artifacts are created, and deployment pipelines can move those artifacts directly into production. That efficiency is exactly what makes CI/CD infrastructure such an attractive target for attackers.
A newly disclosed vulnerability in JetBrains TeamCity On-Premises demonstrates how dangerous a compromise of the build system can become. Tracked as CVE-2026-63077, the vulnerability allows an unauthenticated attacker with HTTP(S) access to a vulnerable TeamCity server to bypass authentication and execute arbitrary operating-system commands with the privileges of the TeamCity server process. JetBrains rates the flaw 9.8 out of 10, Critical, while the National Vulnerability Database records the same CVSS 3.1 score and vector.
The Vulnerability at a Glance
The core issue affects JetBrains TeamCity On-Premises installations that have not been updated to the fixed releases. According to the CVE record, unauthenticated remote code execution was possible through the agent polling protocol before TeamCity 2026.1.3 and 2025.11.7.
The CVSS 3.1 rating is:
9.8 — CRITICAL
Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
This combination is particularly concerning because exploitation is network-accessible, requires low complexity, requires no privileges, and requires no user interaction.
What CVSS 9.8 Really Means
The 9.8 score is not simply a dramatic number attached to the vulnerability. It reflects a combination of characteristics that make the flaw exceptionally dangerous for exposed servers.
An attacker does not need an existing TeamCity account. They do not need an administrator to click a malicious link. They do not need complicated local access to the server. If the vulnerable TeamCity service is reachable over HTTP(S), the attack surface can potentially be reached remotely.
The impact ratings are equally serious. The CVSS vector assigns high impact to confidentiality, integrity, and availability, meaning successful exploitation could potentially allow an attacker to access sensitive information, alter systems or data, and disrupt services.
The Agent Polling Protocol Is at the Center
TeamCity build agents communicate with the TeamCity server through a polling architecture. JetBrains documentation explains that agents initiate connections to the server and periodically poll it for commands, including information related to queued builds.
That architecture is designed to simplify communication between the server and build machines. However, CVE-2026-63077 demonstrates how a security weakness in a trusted communication mechanism can become a route into the central CI/CD server.
JetBrains states that the vulnerability can be exploited through the agent polling protocol to bypass authentication checks and execute arbitrary operating-system commands with the privileges of the TeamCity server process.
Why CI/CD Servers Are Especially Valuable
A normal application server may contain customer information or business data. A CI/CD server can contain something even more powerful: the machinery used to build and distribute software.
TeamCity environments may interact with source-code repositories, deployment systems, artifact repositories, cloud infrastructure, signing systems, credentials, secrets, and build agents. A successful compromise could therefore become more than an isolated server breach.
It could potentially become a stepping stone into an organization’s entire software supply chain.
The Risk of Stored Credentials
JetBrains specifically warns that successful exploitation could expose TeamCity data, configurations, and stored credentials. Depending on the privileges assigned to the TeamCity server process, attackers could also modify server state and compromise build artifacts and downstream CI/CD pipelines.
This is an important distinction. Remote code execution is already severe, but the consequences can become much broader when the compromised system has legitimate credentials for other infrastructure.
A TeamCity server that can authenticate against cloud storage, source repositories, container registries, deployment platforms, or internal services may provide an attacker with additional opportunities after the initial compromise.
The Supply-Chain Implications Are Bigger Than One Server
The most concerning scenario is not necessarily an attacker simply taking control of a TeamCity host.
The bigger danger is manipulation of the development process itself.
If an attacker gains control of a build server, they may attempt to tamper with build configurations, alter scripts, manipulate artifacts, access secrets, or interfere with deployment workflows. Such activity could potentially transform a single vulnerability into a software supply-chain incident.
That is why CI/CD infrastructure deserves the same security attention traditionally given to identity systems, domain controllers, production databases, and externally exposed applications.
TeamCity Cloud Customers Are Not Required to Act
There is an important distinction between TeamCity On-Premises and TeamCity Cloud.
JetBrains states that TeamCity Cloud customers do not need to take action because the necessary measures have already been applied. JetBrains also said it had verified that it had no evidence of TeamCity Cloud environments being exploited through this vulnerability.
The immediate concern is therefore for organizations operating their own TeamCity On-Premises infrastructure.
The Fixed Versions Are Available
JetBrains released fixes in TeamCity 2025.11.7 and TeamCity 2026.1.3. Both releases became available on July 27, 2026.
The official release information describes the updates as security-focused maintenance releases, with more than 20 security vulnerabilities addressed in each of the corresponding branches. JetBrains strongly recommends upgrading as soon as possible.
A Security Patch Plugin Is Also Available
Organizations that cannot immediately upgrade have another option.
JetBrains released a security patch plugin covering CVE-2026-63077 for TeamCity versions going back to 2017.1+. For TeamCity 2024.03 and newer, JetBrains says security patch plugins can be automatically downloaded and made available to administrators through the update interface when notifications are configured.
However, the patch plugin should be viewed as a temporary solution rather than a substitute for normal lifecycle management.
JetBrains explicitly recommends upgrading because the plugin addresses this specific vulnerability while newer TeamCity releases contain additional security fixes and improvements.
The Vulnerability Was Privately Reported
According to JetBrains, the vulnerability was privately reported on July 10, 2026, by security researcher Antoni Tremblay, following JetBrains’ coordinated disclosure process.
The coordinated disclosure process provided time for JetBrains to investigate the problem, develop fixes, and release protected versions before publishing the technical details.
No Active Exploitation Was Confirmed at Disclosure
JetBrains stated that, at the time of publishing its advisory, it was not aware of active exploitation of CVE-2026-63077.
That statement is reassuring, but it should not be interpreted as evidence that the risk is low.
Once a critical unauthenticated RCE becomes publicly documented, defenders have to assume that attackers will study the vulnerability, reverse-engineer the patches, and search for exposed installations.
Why Public Disclosure Changes the Equation
Before disclosure, attackers may have had to discover the weakness independently.
After disclosure, defenders and attackers have access to the same basic information.
Security researchers can use that information to develop detection rules and validation tools. Threat actors can use it to identify vulnerable installations and investigate possible exploitation paths.
This creates a race between patching and exploitation.
For internet-facing TeamCity servers, the safest strategy is therefore not to wait for evidence of attacks. It is to remove the vulnerable condition as quickly as practical.
The Network Exposure Problem
JetBrains specifically recommends limiting network access to TeamCity servers to trusted networks wherever possible. For internet-facing installations, the company recommends considering VPN access or an additional security layer.
This is particularly important because CVE-2026-63077 is remotely reachable through HTTP(S).
A TeamCity server does not necessarily need to be directly accessible from the public internet for developers and build infrastructure to function.
Restricting exposure can substantially reduce the number of systems that can even attempt to interact with the vulnerable service.
Minimum Privileges Can Reduce the Blast Radius
Another important recommendation from JetBrains is to run the TeamCity server with the minimum operating-system privileges required for normal operation.
This principle cannot eliminate remote code execution, but it can reduce what an attacker can accomplish after obtaining execution.
If a compromised service operates with excessive privileges, exploitation can become a gateway to much more of the underlying operating system and infrastructure.
Least privilege therefore acts as a damage-control mechanism.
Keep TeamCity Servers Separate From Build Agents
JetBrains also recommends running TeamCity servers on dedicated hosts separate from build agents.
This architectural separation matters because build agents routinely execute code as part of normal development workflows.
Keeping the central orchestration server isolated from build execution environments can make lateral movement more difficult and create additional security boundaries.
The Hidden Danger of Build Credentials
Build systems frequently require credentials to perform legitimate tasks.
They may need tokens to retrieve dependencies, publish packages, access repositories, upload artifacts, communicate with cloud platforms, or trigger deployments.
Those credentials can become extremely valuable following a server compromise.
Even if an attacker cannot immediately reach production, stolen secrets may provide a second route into the organization.
Artifact Integrity Becomes a Major Concern
Software artifacts produced by a compromised CI/CD system cannot automatically be considered trustworthy.
If an attacker modifies the build process, the resulting binaries, packages, containers, or deployment artifacts could potentially be altered before reaching downstream environments.
This is why organizations should treat a compromised CI/CD server as a potential software-integrity incident rather than merely an infrastructure vulnerability.
Why Monitoring Matters After Patching
Patching closes the known vulnerability, but it does not erase what might have happened before the patch.
Organizations should review TeamCity logs, authentication activity, server processes, network connections, configuration changes, unusual build activity, and access to sensitive credentials.
The goal is to determine whether exploitation occurred before remediation.
A clean patch with no investigation can leave an organization unaware that an attacker may already have established persistence elsewhere.
Deep Analysis: What Security Teams Should Do Now
Command 1 — Identify the Running TeamCity Version
Start by determining exactly which TeamCity version is operating in the environment.
Example: locate the TeamCity installation directory
ls -la /opt/TeamCity
The exact installation path varies between environments, so administrators should use their organization’s actual TeamCity deployment structure.
Command 2 — Check the TeamCity Process
Administrators can inspect running processes to identify the active TeamCity server.
ps aux | grep -i teamcity
This is a basic validation step and should be combined with TeamCity’s own administration interface and deployment documentation.
Command 3 — Inspect Network Exposure
A TeamCity installation that is accessible from untrusted networks deserves immediate attention.
ss -lntp
The purpose is to identify listening services and determine whether TeamCity is exposed beyond the networks that genuinely require access.
Command 4 — Check the Installed Release
Administrators should confirm whether the server is running a release newer than or equal to the fixed versions.
2026.1.3
2025.11.7
Versions below the applicable fixed release should be treated as vulnerable unless the official security patch has been applied.
Command 5 — Restrict External Access
Where possible, place TeamCity behind a VPN, trusted network boundary, reverse proxy, firewall policy, or equivalent access-control layer.
Internet
|
Firewall / VPN
|
Reverse Proxy
|
TeamCity Server
|
Build Agents
The objective is straightforward: minimize the number of systems capable of reaching the TeamCity service.
Command 6 — Review Authentication and Server Logs
Security teams should search logs for unexpected requests, authentication anomalies, unusual administrative activity, unexplained configuration changes, and processes that appeared unexpectedly.
grep -Ri "authentication" /path/to/teamcity/logs/
The exact log location depends on the TeamCity deployment.
Command 7 — Investigate Unexpected Processes
Because the vulnerability can lead to operating-system command execution, administrators should review processes that do not belong on the TeamCity server.
ps aux --sort=-%cpu | head -30
Unexpected shells, download utilities, scripting interpreters, persistence mechanisms, or unusual outbound connections deserve investigation.
Command 8 — Rotate Potentially Exposed Secrets
If there is credible evidence that a vulnerable TeamCity server was exploited, organizations should consider credentials stored or accessible through the server potentially compromised.
That can include repository tokens, cloud credentials, deployment keys, API tokens, package registry credentials, signing keys, and service-account secrets.
Rotation should be performed carefully to avoid breaking legitimate production systems.
Command 9 — Audit Build Configuration Changes
Security teams should compare current build configurations against known-good versions.
Unexpected changes to build scripts, deployment steps, plugins, credentials, agents, project settings, or artifact destinations may provide evidence of unauthorized access.
Command 10 — Examine Downstream Systems
A TeamCity compromise should not automatically be treated as isolated.
Investigators should determine whether the server communicated with source-code repositories, cloud accounts, artifact repositories, production systems, container registries, or other privileged infrastructure.
The investigation boundary should follow the trust relationships of the CI/CD environment.
Command 11 — Upgrade to the Official Fix
The preferred remediation is to upgrade to TeamCity 2026.1.3 or 2025.11.7, depending on the supported release branch. JetBrains provides official upgrade documentation and recommends keeping installations current with security fixes.
Administrators should back up important TeamCity data and follow the official upgrade procedure before making changes to production CI/CD infrastructure.
Command 12 — Use the Security Patch Only When Necessary
If an immediate upgrade is not practical,
However, organizations should create a plan to complete the full upgrade rather than allowing a temporary mitigation to become permanent.
Command 13 — Verify Agents After Server Remediation
Because the vulnerability involves the agent polling protocol, teams should also verify that build agents reconnect normally after remediation.
A successful server upgrade should be followed by operational testing to ensure builds, authentication, artifact handling, and agent communication continue working as expected.
Command 14 — Separate Build Execution From Server Administration
Longer term, organizations should maintain clear security boundaries between the TeamCity server, build agents, source repositories, artifact stores, and production infrastructure.
Every connection should be treated as a trust relationship that needs authentication, authorization, monitoring, and appropriate network controls.
What Undercode Say:
The Real Target Is the Software Factory
CVE-2026-63077 is more important than a typical web-server vulnerability because TeamCity sits inside the software production process.
An attacker who compromises the build system may gain access not only to a machine, but to the mechanisms that transform source code into deployable software.
That makes CI/CD infrastructure an increasingly strategic target.
A 9.8 Score Deserves Immediate Attention
The CVSS 9.8 rating accurately reflects the combination of remote reachability, low attack complexity, lack of authentication requirements, and potentially complete impact across confidentiality, integrity, and availability.
Security teams should not wait for exploitation reports before taking action.
Authentication Bypass Changes Everything
The absence of an authentication requirement is one of the most dangerous characteristics of this vulnerability.
Attackers do not have to compromise an employee account first.
They can potentially begin with network access to the vulnerable service itself.
CI/CD Credentials Can Become the Next Objective
A compromised TeamCity server may expose credentials and configurations that were never intended to be publicly accessible.
Those credentials could become stepping stones toward other infrastructure.
This is why secret management and credential rotation are essential components of incident response.
Build Agents Create Additional Risk
TeamCity agents execute build workloads and interact with the server as part of normal operations.
The compromise of the central server therefore deserves investigation across the wider agent ecosystem.
Software Integrity Should Be Investigated
Organizations should ask a difficult question after a suspected compromise: Can we still trust the software produced during the affected period?
If the answer is uncertain, artifact verification and rebuild procedures may be necessary.
Internet Exposure Is a Strategic Weakness
A CI/CD server rarely benefits from unrestricted internet exposure.
Putting administrative and build infrastructure behind VPNs, private networks, firewalls, or controlled access gateways reduces unnecessary attack surface.
Patching Is Only Step One
Installing 2026.1.3 or 2025.11.7 addresses the known vulnerability, but remediation should not end there.
Security teams should investigate logs, credentials, configuration changes, processes, and downstream activity.
The Absence of Known Exploitation Is Not a Safety Guarantee
JetBrains reported no known active exploitation when the advisory was published.
That status can change rapidly once technical information becomes public.
Threat actors increasingly automate vulnerability discovery and scanning, meaning the window between disclosure and exploitation can be extremely short.
Attackers Are Interested in Automation
Modern attackers do not necessarily need to manually compromise every exposed server.
Automated scanning can identify internet-facing services, fingerprint software versions, and prioritize vulnerable targets.
A critical unauthenticated RCE is therefore exactly the type of vulnerability that can attract automated exploitation.
The Agent Protocol Deserves Security Scrutiny
Protocols created for trusted internal communication can become dangerous when network boundaries change.
The lesson from CVE-2026-63077 is that internal automation channels should never be assumed to be harmless simply because they were designed for server-agent communication.
Least Privilege Remains Powerful
Running TeamCity with minimal operating-system privileges will not prevent exploitation.
It can, however, limit what exploitation can accomplish.
Security architecture should always assume that individual defenses may fail.
Segmentation Can Prevent Catastrophic Escalation
A TeamCity server should not automatically have unrestricted access to production infrastructure.
Network segmentation can create barriers that force attackers to overcome additional controls after compromising the CI/CD layer.
Secret Rotation Is Often Overlooked
Organizations sometimes patch vulnerabilities without rotating credentials that may have been exposed.
That creates a dangerous situation where the original vulnerability is fixed but stolen credentials remain valid.
Artifact Signing Can Add Another Layer
Cryptographic signing and verification of important artifacts can help organizations detect unauthorized modifications.
It is not a complete defense against a compromised build pipeline, but it strengthens software-integrity controls.
Reproducible Builds Are Increasingly Valuable
Reproducible build processes can provide another mechanism for checking whether generated artifacts correspond to expected source code and build inputs.
The more transparent the build process becomes, the harder it is to quietly manipulate.
Monitoring Should Cover the Entire Pipeline
Monitoring only the TeamCity server is insufficient.
Security telemetry should ideally extend to source repositories, agents, artifact repositories, cloud accounts, deployment systems, and production environments.
The Server Is a High-Value Identity
TeamCity should be treated as a privileged identity within the organization.
It is not simply another application.
It may possess permissions that allow it to perform highly consequential operations automatically.
CI/CD Security Is Now Supply-Chain Security
The distinction between application security and build-system security is becoming increasingly blurred.
If an attacker can control how software is built, they may not need to compromise every application individually.
Organizations Should Review Trust Relationships
Every TeamCity integration should be documented.
Teams should know which credentials TeamCity possesses, which systems it can reach, which repositories it can modify, and which deployment actions it can trigger.
Old Installations Are Particularly Concerning
Organizations running older TeamCity branches should not assume that a vulnerability affects only modern deployments.
JetBrains released a security patch plugin supporting TeamCity 2017.1 and later, demonstrating the broad remediation scope required for this issue.
Security Updates Should Become Routine
JetBrains’ release documentation emphasizes regular upgrades and keeping TeamCity installations current with security patches.
Security maintenance should therefore be incorporated into normal CI/CD operations rather than treated as an emergency activity.
A Vulnerable Build Server Can Become a Business Crisis
If a development pipeline is compromised, the consequences can extend into production.
That means the potential business impact includes not only downtime but also unauthorized software changes, stolen intellectual property, credential exposure, regulatory concerns, and reputational damage.
Defenders Have an Advantage Right Now
The vulnerability has been publicly identified, the affected versions are known, and official fixes are available.
Organizations that act quickly have an opportunity to eliminate the vulnerability before attackers successfully exploit it.
The Most Dangerous Response Is Waiting
The worst possible strategy is to acknowledge the vulnerability and postpone remediation indefinitely.
Critical vulnerabilities become dangerous when organizations know about them but leave vulnerable systems exposed.
Security Teams Should Assume Attackers Will Look
Even without confirmed exploitation, defenders should operate under the assumption that exposed vulnerable systems will eventually be scanned.
That assumption leads to faster patching, better monitoring, and more realistic incident-response planning.
TeamCity Administrators Should Act Today
For On-Premises deployments, the practical priority is straightforward: identify affected servers, restrict unnecessary network access, upgrade to a fixed release or apply the official security patch, investigate suspicious activity, and rotate potentially exposed secrets where appropriate.
The Bigger Lesson Is Architectural
CVE-2026-63077 is not only a warning about TeamCity.
It is a warning about the concentration of power inside modern development environments.
The systems that build our software increasingly have access to everything required to deliver that software.
The Software Factory Must Be Protected
Organizations spend enormous resources protecting applications after deployment.
The build infrastructure that creates those applications deserves the same level of protection.
If the factory is compromised, protecting the finished product may no longer be enough.
✅ CVE-2026-63077 Is Rated Critical
The CVE is officially listed with a CVSS 3.1 score of 9.8 (Critical) and the vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.
✅ Unauthenticated Remote Code Execution Is Confirmed
JetBrains confirms that an unauthenticated attacker with HTTP(S) access could bypass authentication checks and execute arbitrary operating-system commands through the TeamCity agent polling protocol.
✅ The Fixed Versions Are 2025.11.7 and 2026.1.3
JetBrains released fixes in TeamCity 2025.11.7 and 2026.1.3, both released on July 27, 2026.
Prediction
(+1) Rapid Patching Will Prevent Many Exploits
Organizations that quickly upgrade vulnerable TeamCity On-Premises servers or apply the official security patch are likely to eliminate the primary attack path before it becomes an incident.
(-1) Internet-Facing Unpatched Servers Will Become Attractive Targets
Once attackers have enough technical understanding of the vulnerability, exposed and unpatched TeamCity servers are likely to receive increased scanning and exploitation attempts.
(-1) Compromised CI/CD Systems Could Trigger Supply-Chain Incidents
If attackers successfully compromise build infrastructure and gain access to credentials or build configurations, some incidents could extend beyond TeamCity into source repositories, artifacts, cloud infrastructure, or production deployment systems.
(+1) Network Segmentation Can Significantly Reduce Damage
Organizations that isolate CI/CD infrastructure, restrict administrative access, enforce least privilege, and separate build agents from central servers will generally have stronger defenses against post-exploitation movement.
(-1) Delayed Credential Rotation Could Prolong an Incident
If a vulnerable TeamCity server was compromised before patching, fixing the vulnerability alone may not invalidate credentials that an attacker already accessed.
(+1) Security Monitoring Will Improve Detection
Organizations that actively monitor TeamCity logs, agent activity, configuration changes, authentication events, and downstream infrastructure should have a better chance of identifying suspicious activity before it becomes a larger compromise.
(+1) The Long-Term Lesson Will Be Stronger CI/CD Security
CVE-2026-63077 is likely to reinforce a broader industry trend: CI/CD platforms are becoming high-value security assets, and protecting the software factory is now an essential part of protecting the software itself.
Final Assessment
A Critical Vulnerability With a Clear Remediation Path
CVE-2026-63077 deserves immediate attention from every organization running TeamCity On-Premises. Its 9.8 Critical rating, unauthenticated attack requirements, remote reachability, and arbitrary command-execution potential combine into a particularly serious security risk.
The Good News Is That Defenders Have the Fix
Unlike situations where organizations must wait for a patch, JetBrains has already released corrected versions and a security patch plugin for environments that cannot immediately upgrade.
The priority should therefore be clear: identify vulnerable TeamCity servers, remove unnecessary internet exposure, upgrade to 2025.11.7 or 2026.1.3, investigate signs of compromise, and review credentials and downstream systems if exploitation is suspected.
The Bigger Warning Goes Beyond TeamCity
The most important lesson from this vulnerability is not simply that one CI/CD platform contained a critical flaw.
It is that the software development pipeline has become one of the most valuable assets inside modern organizations.
A compromised build system can potentially influence code, credentials, artifacts, infrastructure, and deployments. Protecting that environment is no longer optional. It is a fundamental part of cybersecurity.
For organizations operating TeamCity On-Premises, CVE-2026-63077 should be treated as an urgent security issue—not a routine software update.
▶️ 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: www.cve.org
Extra Source Hub (Possible Sources for article):
https://www.reddit.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
