CISA has added CVE-2026-63077 to its Known Exploited Vulnerabilities catalog, confirming that attackers are exploiting the TeamCity flaw in the wild. Organizations running TeamCity On-Premises are affected if their server is older than 2025.11.7 or 2026.1.3. TeamCity Cloud customers do not need to act on this issue.
The new exploitation record changes the job for defenders. Updating or applying JetBrains’ patch plugin closes the vulnerability, but it does not establish that a previously reachable server stayed clean. Internet-exposed or broadly reachable TeamCity servers should move through compromise assessment because the flaw gives an unauthenticated attacker operating-system command execution as the TeamCity server process.
One HTTP path reaches the server process
JetBrains says the flaw sits in the TeamCity agent polling protocol. An attacker needs HTTP or HTTPS access to the server but does not need an account. Successful exploitation bypasses authentication checks and runs commands with whatever operating-system privileges the TeamCity service holds.
That boundary matters. TeamCity coordinates source access, build configuration, agents, artifacts, and deployments. JetBrains says a successful attack could expose TeamCity data, configuration, and stored credentials; modify server state; and compromise build artifacts or downstream CI/CD pipelines. The advisory does not say those outcomes occurred in every attack. It describes what the resulting server-process access makes possible.
Figure details
An attacker who can reach TeamCity over HTTP or HTTPS sends an unauthenticated request through the agent polling protocol. The flaw bypasses authentication and allows operating-system command execution with the privileges of the TeamCity server process. That process may reach TeamCity data, configuration, stored credentials, build state, artifacts, and downstream deployment connections. Defenders must both remediate the flaw and assess the earlier exposure window.
Fixed releases define the remediation boundary
JetBrains fixed CVE-2026-63077 in TeamCity 2025.11.7 and 2026.1.3. Administrators should inventory every on-premises server, including development, disaster-recovery, and test instances, then verify the installed build rather than relying on an upgrade ticket or maintenance record.
For TeamCity 2017.1 and later, JetBrains also provides a security patch plugin when a full upgrade cannot happen immediately. The plugin fixes this vulnerability only. TeamCity versions from 2017.1 through 2018.1 require a server restart after the plugin is installed; newer versions can enable it without a restart. A full current-version update remains the stronger endpoint because it includes other security fixes.
Reduce reachability while remediation is underway. JetBrains recommends limiting servers to trusted networks and placing an additional access layer, such as a VPN, in front of internet-facing instances. Run the server service with minimum required operating-system privileges and keep the server on a host separate from build agents.
Treat prior exposure as an evidence question
Neither cited primary record publishes an exploit-request signature or campaign-specific indicators. Do not turn the absence of one convenient string into clearance. Establish the earliest time each vulnerable server was reachable, preserve relevant evidence, and review the server’s HTTP access logs and teamcity-server.log across that window for unusual agent-polling traffic, unexpected errors, unfamiliar source addresses, and command or child-process activity that does not match normal administration.
Correlate server events with endpoint telemetry. Look for the TeamCity service account spawning shells, scripting engines, download tools, or other processes outside known build workflows. Review new or changed administrator accounts, authentication tokens, plugins, projects, build configurations, VCS roots, agent authorizations, scheduled activity, and service settings. Compare recent release artifacts and checksums with trusted provenance, and inspect downstream deployments for changes that cannot be tied to an approved commit and build.
Those checks are defensive inferences from the access described by JetBrains, not vendor-published indicators for this CVE. CISA and JetBrains have not named the exploiting actor in the cited records, and CISA lists ransomware use as unknown.
Rotate what the server could read
If exploitation is suspected or the exposure window cannot be bounded, isolate the server while preserving evidence. Rotate secrets from a clean administrative system: VCS credentials, personal and project access tokens, cloud keys, registry credentials, signing material, deployment keys, webhooks, SSH keys, and any secrets available to build configurations or the TeamCity service account.
Rotation must include use-history review. Check source-control, artifact registry, package registry, cloud control plane, signing, and deployment logs from the earliest plausible compromise time. Rebuild release artifacts from reviewed source on trusted infrastructure when provenance is uncertain. Restoring the same TeamCity data to a clean host can reintroduce malicious accounts, tokens, plugins, or configuration, so inspect state before migration.
Close the vulnerability and the incident separately
Close the vulnerability only after every TeamCity On-Premises server is verified at 2025.11.7, 2026.1.3, or a later fixed release, or has the CVE-2026-63077 patch plugin installed and active. Verify restarts where older releases require them, remove unnecessary network reachability, and document any instance that cannot be remediated.
Resolve the incident assessment after the vulnerable exposure window is known; server, HTTP, and endpoint evidence has been reviewed; administrator, token, plugin, project, build, agent, and service changes are accounted for; and recent artifacts and downstream deployments match approved provenance. Rotate every credential the server could read from a clean system and review its use history.
If logs are missing, service-account process activity cannot be reconstructed, or build provenance cannot be proved, record that uncertainty. Rebuild the server and affected releases on trusted infrastructure rather than treating a green version check as evidence that earlier exploitation did not occur.