Listen to this Post
Introduction: When the Software Factory Becomes the Attack Surface
Modern software is built inside highly connected automation environments where code is compiled, tested, packaged, signed, and delivered at extraordinary speed. Continuous integration and continuous delivery platforms have become the engines behind this process, quietly controlling workflows that can affect everything from internal applications to customer-facing services. But when the platform coordinating those operations contains a critical security weakness, the consequences can extend far beyond a single server.
JetBrains has issued an urgent warning about CVE-2026-63077, a critical authentication bypass vulnerability affecting TeamCity On-Premises. The flaw could allow an unauthenticated attacker with network access to a vulnerable TeamCity server to bypass security checks and execute arbitrary operating system commands using the privileges assigned to the TeamCity server process.
The risk is particularly serious because TeamCity environments may contain sensitive source-code information, build configurations, access tokens, deployment credentials, signing materials, and software artifacts. A successful compromise could therefore place an organization’s entire software delivery chain at risk.
JetBrains has released fixes in TeamCity 2025.11.7 and TeamCity 2026.1.3, while organizations unable to upgrade immediately can apply a dedicated security patch plugin. TeamCity Cloud customers do not need to take action because the required protections have already been deployed.
Original Summary: A Critical TeamCity Flaw Demands Immediate Action
The Vulnerability at a Glance
CVE-2026-63077 is a critical unauthenticated remote code execution vulnerability affecting TeamCity On-Premises installations. According to JetBrains, an attacker who can reach a vulnerable TeamCity server over HTTP or HTTPS may exploit the agent polling protocol to bypass authentication controls and execute operating system commands.
The vulnerability affects all TeamCity On-Premises versions before the corrected releases. The National Vulnerability Database lists the issue with a CVSS 3.1 score of 9.8 out of 10, placing it in the critical severity category. The attack requires no authentication, has low attack complexity, and may result in major impacts to confidentiality, integrity, and availability.
The Potential Impact
A successful attack could expose TeamCity configurations, internal project information, stored credentials, and other sensitive data. Depending on the privileges assigned to the TeamCity service, an attacker could also modify server behavior, interfere with build operations, manipulate artifacts, or move deeper into connected development and production environments.
The Available Fixes
JetBrains addressed the vulnerability in TeamCity versions 2025.11.7 and 2026.1.3. The company strongly recommends upgrading to one of these releases because the updates also contain numerous additional security improvements.
For organizations unable to perform a full upgrade immediately, JetBrains has released a security patch plugin compatible with TeamCity 2017.1 and later. TeamCity 2024.03 and newer can automatically download available security patch plugins and notify administrators when updates are ready for installation.
The Cloud Environment Is Already Protected
TeamCity Cloud customers are not required to perform manual remediation. JetBrains stated that the necessary protections have already been applied to its hosted environment and that there was no evidence of TeamCity Cloud exploitation through this vulnerability at the time of publication.
Why CVE-2026-63077 Is More Dangerous Than an Ordinary Server Vulnerability
TeamCity Is More Than a Development Tool
A TeamCity server is not simply another application running inside an organization. It can act as a central automation hub connecting developers, source-code repositories, build agents, artifact storage, package registries, cloud environments, and deployment systems.
That level of connectivity makes a CI/CD server extremely valuable to attackers. Instead of compromising individual developer workstations or searching for separate production entry points, an attacker may attempt to compromise the platform that already has trusted access to many parts of the software ecosystem.
The Authentication Bypass Changes the Threat Model
Authentication is normally the first major security boundary protecting administrative platforms. When a vulnerability allows an attacker to bypass that boundary, the attacker may not need a valid username, password, API token, or stolen session.
This significantly reduces the effort required to launch an attack. If a vulnerable TeamCity instance is reachable from an untrusted network, an attacker may be able to begin probing it immediately without first compromising an employee account.
Remote Code Execution Creates a Direct Path to Server Control
Remote code execution is among the most serious vulnerability categories because it can allow an attacker to instruct a server to run commands. The actual impact depends on the operating-system privileges of the affected service, but even a restricted service account may provide access to sensitive application files, configuration data, internal networks, or connected systems.
The TeamCity server should therefore be treated as a high-value infrastructure asset rather than a routine development service.
CI/CD Compromise Can Become a Software Supply-Chain Incident
The danger does not end with the TeamCity host. Build systems may create trusted software packages that are later distributed internally or externally. If attackers gain control of the build environment, they may attempt to alter source inputs, modify build logic, inject unauthorized components, replace artifacts, or interfere with deployment processes.
This creates a potential supply-chain risk in which a compromise inside the development environment could affect software delivered to many systems.
Stored Credentials May Expand the Attack
CI/CD platforms frequently require credentials to perform automated tasks. These may include repository tokens, cloud credentials, package-registry keys, deployment secrets, or service-account permissions.
If an attacker compromises the TeamCity server and gains access to such information, the attack may expand beyond the original host. The result could be lateral movement into cloud infrastructure, source-code platforms, internal services, or production environments.
Deep Analysis: Understanding the Attack Path
The Likely Attack Sequence
The vulnerability can be understood as a chain of security failures rather than a single isolated event:
An attacker identifies a TeamCity On-Premises server reachable over HTTP or HTTPS.
The attacker interacts with the affected agent polling functionality.
Authentication checks are bypassed.
The attacker triggers arbitrary operating-system command execution.
Commands run with the privileges of the TeamCity server process.
The attacker may inspect configurations, access application data, or search for credentials.
The attacker may attempt to alter builds, compromise artifacts, or move into connected infrastructure.
JetBrains states that exploitation does not require authentication and may allow arbitrary commands to run with the privileges of the TeamCity server process.
Why Internet Exposure Raises the Urgency
A server exposed directly to the internet is easier for attackers to discover and scan. Public exposure does not guarantee compromise, but it increases the number of potential attackers who can reach the vulnerable service.
JetBrains recommends limiting TeamCity access to trusted networks and considering VPN access or additional protective layers for internet-facing deployments. The company also warns that exposing the login page or REST API can create an entry point for exploitation when new vulnerabilities are disclosed.
Why “No Active Exploitation” Is Not a Reason to Delay
At the time JetBrains published its advisory, the company was not aware of active exploitation. That is useful information, but it should not be interpreted as evidence that the vulnerability is harmless.
Public disclosure often begins a race between defenders applying patches and attackers developing reliable exploitation methods. Critical vulnerabilities affecting widely deployed infrastructure can become more attractive after technical details and defensive guidance become public.
The safest operational assumption is that internet-reachable vulnerable systems may soon be scanned and targeted.
Immediate Remediation: What TeamCity Administrators Should Do
Step One: Identify Every TeamCity On-Premises Instance
Security teams should create an accurate inventory of TeamCity servers, including production systems, development environments, disaster-recovery instances, temporary test servers, and older installations that may have been forgotten.
Administrators should verify the installed version from the TeamCity administration interface or through their deployment-management process.
Step Two: Upgrade to a Fixed Release
The preferred remediation is to upgrade to TeamCity 2025.11.7, TeamCity 2026.1.3, or a newer secure release.
Before upgrading, organizations should review their maintenance procedures, confirm backups, test critical integrations where practical, and document the change. However, the critical nature of the vulnerability means that patching should be prioritized rather than postponed through lengthy routine cycles.
Step Three: Use the Security Patch Plugin When an Upgrade Is Delayed
Organizations unable to upgrade immediately should install JetBrains’ security patch plugin for supported TeamCity versions.
The plugin is available for TeamCity 2017.1 and later. TeamCity 2017.1 through 2018.1 requires a server restart after installation, while later supported versions can enable the plugin without the same restart requirement.
Step Four: Restrict Network Exposure
TeamCity should be reachable only from networks and users that require access. Organizations should consider VPN-based access, identity-aware proxies, network segmentation, firewall restrictions, and allowlisting where operationally appropriate.
Removing unnecessary public exposure can reduce the opportunity for unauthenticated attackers to reach vulnerable services.
Step Five: Review Service Privileges
The TeamCity server should run with the minimum operating-system permissions required for normal operation. Excessive privileges can turn an application-level compromise into a broader host-level or infrastructure-level incident.
JetBrains also recommends placing TeamCity servers on dedicated hosts separate from build agents.
Deep Analysis Commands: Defensive Validation and Threat Hunting
Linux Version and Service Checks
Administrators can begin by identifying TeamCity-related processes and services:
ps aux | grep -i teamcity systemctl status teamcity systemctl list-units --type=service | grep -i teamcity
These commands help confirm whether TeamCity is running and identify the service context. They do not determine whether a server is patched by themselves.
Linux Network Exposure Checks
Administrators can inspect listening services:
sudo ss -tulpn | grep -E '8111|teamcity'
They can also review firewall rules:
sudo ufw status verbose sudo iptables -S
The goal is to determine whether TeamCity is exposed beyond trusted networks and whether unnecessary inbound access should be removed.
Docker Deployment Checks
Organizations running TeamCity in containers can inspect active containers:
docker ps --format "table {{.Names}} {{.Image}} {{.Status}}"
To review the image associated with a TeamCity container:
docker inspect <container_name> --format '{{.Config.Image}}'
After updating the deployment configuration, administrators should pull the approved patched image and recreate the service according to their organization’s change-management procedures.
Windows Service Checks
Windows administrators can inspect TeamCity-related services using PowerShell:
Get-Service | Where-Object {
$<em>.DisplayName -match "TeamCity" -or $</em>.Name -match "TeamCity"
}
They can also review TeamCity-related processes:
Get-Process | Where-Object {
$_.ProcessName -match "teamcity|java"
}
Suspicious Child-Process Hunting
Because successful exploitation may cause the TeamCity server process to execute operating-system commands, defenders should investigate unexpected child processes launched by the TeamCity service.
On Linux, examples may include:
sudo journalctl --since "7 days ago" | \ngrep -Ei "teamcity|curl|wget|bash|sh|python|perl"
On Windows, security teams should review process telemetry for unusual command interpreters or scripting engines launched by the TeamCity service account, including:
powershell.exe
cmd.exe
pwsh.exe
wscript.exe
cscript.exe
mshta.exe
The presence of these processes is not automatically proof of compromise. Many build pipelines legitimately execute scripts. Analysts should compare activity with known build jobs, expected automation behavior, service-account usage, timestamps, and approved deployment events.
Credential Review Commands
After patching, administrators should consider reviewing credentials used by TeamCity integrations. For Linux environments, file permissions can be checked with:
sudo find /opt/TeamCity -type f -perm /o+r -ls
The exact installation path may differ. Organizations should avoid exposing secrets in terminal history, logs, screenshots, or support tickets.
Post-Patch Validation
After remediation, teams should confirm:
systemctl status teamcity curl -I https://teamcity.example.com
They should also verify that the installed TeamCity version matches a fixed release and review application logs for startup errors or failed plugin activation.
What Undercode Say:
A Critical CI/CD Vulnerability Is a Business Risk
CVE-2026-63077 should not be treated as a routine application bug.
TeamCity often sits close to the center of an organization’s software-delivery process.
That position can make the platform more valuable than many ordinary servers.
An attacker may view a CI/CD system as a bridge to source code, credentials, artifacts, and deployment infrastructure.
The absence of an authentication requirement makes the vulnerability especially concerning.
Attackers may not need stolen passwords or valid user accounts.
Network reachability may be enough to begin an attack.
That changes the urgency for organizations with publicly accessible TeamCity servers.
Patching should be measured in hours or days, not in the next ordinary maintenance cycle.
The availability of fixed releases provides a direct remediation path.
The security patch plugin gives older environments an important temporary option.
However, a plugin should not become a permanent substitute for a supported upgrade strategy.
Older infrastructure often carries additional vulnerabilities that one targeted patch cannot resolve.
Organizations should therefore patch the immediate flaw and plan a full modernization path.
The TeamCity server should be isolated from unnecessary infrastructure.
Build agents should not automatically share the same host.
Service accounts should receive only the permissions required for their tasks.
Secrets should be rotated when compromise cannot be confidently ruled out.
Build artifacts should be protected with integrity controls.
Signing systems should be separated from ordinary build workloads where possible.
Security teams should review whether TeamCity is directly exposed to the internet.
A VPN or identity-aware access layer can reduce unnecessary attack surface.
Network restrictions are valuable, but they are not replacements for patching.
A firewall cannot be trusted as the only defense against a critical application flaw.
Monitoring must focus on behavior, not only vulnerability status.
Unexpected command execution from the TeamCity service should be investigated.
Unusual outbound connections may indicate post-exploitation activity.
Unexpected changes to build configurations deserve immediate review.
Artifact hashes should be validated when there is concern about build manipulation.
Security teams should examine recent administrative activity.
They should review newly created users, tokens, agents, and integrations.
Logs should be preserved before major cleanup actions occur.
Organizations should also test their ability to recover a compromised CI/CD environment.
Backups must be protected from modification by the systems they are designed to restore.
Incident-response plans should include software supply-chain scenarios.
The most important lesson is that development infrastructure is production infrastructure.
A compromise in the build environment can become a compromise in the delivered product.
Security ownership must therefore include engineering, DevOps, infrastructure, and incident-response teams.
The fastest safe response is to identify exposed systems, patch them, reduce access, and investigate suspicious activity.
CVE-2026-63077 is a reminder that the software factory must be defended as carefully as the software it produces.
✅ Confirmed: All TeamCity On-Premises Versions Are Affected
JetBrains confirmed that all TeamCity On-Premises versions are affected by CVE-2026-63077 before applying the relevant fix or security patch. The vulnerability involves an unauthenticated attacker bypassing authentication through the agent polling protocol.
✅ Confirmed: Fixed Versions Are Available
JetBrains released fixes in TeamCity 2025.11.7 and 2026.1.3. The company also published a security patch plugin for supported older installations that cannot immediately upgrade.
✅ Confirmed: The Vulnerability Is Rated Critical
The CVE record lists a CVSS 3.1 score of 9.8 Critical. The published vector indicates network exploitation, low attack complexity, no required privileges, and no user interaction.
✅ Confirmed: TeamCity Cloud Customers Do Not Need Manual Action
JetBrains stated that the necessary measures were already applied to TeamCity Cloud. The company also reported no evidence that TeamCity Cloud environments had been exploited through this vulnerability at the time of publication.
❌ Not Confirmed: Active Exploitation Was Occurring at Disclosure
JetBrains stated that it was not aware of active exploitation when the advisory was published. This does not guarantee that exploitation will not emerge later, so organizations should continue monitoring trusted threat-intelligence sources.
Prediction
(+1) Faster Patching Will Become a Competitive Security Requirement
The disclosure of CVE-2026-63077 is likely to accelerate security reviews of CI/CD platforms across many organizations. Companies with accurate asset inventories, automated patching, strong network segmentation, and centralized monitoring will be able to reduce exposure faster than organizations relying on manual discovery.
(+1) CI/CD Security Will Receive Greater Executive Attention
As software supply-chain risks become more visible, CI/CD platforms will increasingly be treated as critical business infrastructure. Security budgets may shift toward stronger build isolation, credential protection, artifact verification, and continuous threat detection.
(-1) Publicly Exposed and Unpatched Servers May Attract Rapid Scanning
Because the vulnerability is critical, remotely reachable, and does not require authentication, unpatched TeamCity instances exposed to untrusted networks may become attractive targets for automated scanning and exploitation attempts.
(-1) Delayed Remediation Could Expand a Single Server Incident
If attackers gain access to a TeamCity environment containing powerful credentials or trusted deployment connections, the impact could extend into source-code repositories, cloud infrastructure, production systems, or software artifacts.
Final Security Outlook: Patch the Platform That Builds the Future
TeamCity is designed to help organizations deliver software faster, but the same automation and connectivity that make CI/CD platforms powerful can also increase the consequences of compromise. CVE-2026-63077 demonstrates why build infrastructure must be patched quickly, isolated carefully, monitored continuously, and operated with minimum privileges.
For TeamCity On-Premises administrators, the priority is clear: identify affected systems, upgrade to a fixed release or apply the security plugin, restrict unnecessary access, and investigate suspicious activity. In modern software environments, protecting the build pipeline is no longer only a development responsibility—it is a core part of protecting the entire organization.
▶️ Related Video (76% Match):
https://www.youtube.com/watch?v=cd5SZhHT-Wk
🕵️📝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.bleepingcomputer.com
Extra Source Hub (Possible Sources for article):
https://www.reddit.com/r/AskReddit
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
