Skip to content

JetBrains TeamCity CVE-2026-63077 active exploitation

Summary

On August 5, 2026, CISA added CVE-2026-63077 to the Known Exploited Vulnerabilities catalog. The flaw is an unauthenticated remote-code-execution path in the agent polling protocol of JetBrains TeamCity On-Premises. CISA's addition establishes exploitation in the wild and sets an accelerated August 8, 2026 federal remediation deadline.

JetBrains says all TeamCity On-Premises versions are affected unless updated to a fixed release. Fixes are available in 2025.11.7 and 2026.1.3. An attacker who can reach the server over HTTP(S) can bypass authentication and execute operating-system commands with the privileges of the TeamCity server process. TeamCity Cloud was patched by JetBrains and requires no customer action.

Tags

Why this matters

  • TeamCity commonly holds source-control credentials, signing or publication authority, deployment secrets, build configuration, and access to downstream environments. Server compromise can therefore become a software-supply-chain incident rather than remaining a single-host event.
  • Exploitation requires no account. Reachability to the TeamCity HTTP(S) service and agent polling protocol is the important exposure boundary.
  • Commands run with the TeamCity server process's operating-system privileges. Impact depends on local privilege, stored credentials, network reachability, and whether the server shares a host or trust boundary with build agents.
  • CISA records known ransomware-campaign use as unknown and has not published an actor, infrastructure, request pattern, payload, or victim count. KEV inclusion confirms exploitation but does not support campaign attribution.
  • JetBrains said it knew of no active exploitation when its original advisory was published. CISA's later KEV decision changes the operational status and should trigger compromise assessment, not patch-only closure.

Affected and fixed versions

Deployment Status Action
TeamCity On-Premises on the 2025.11 release train before 2025.11.7 Affected Upgrade to 2025.11.7 or later
TeamCity On-Premises on the 2026.1 release train before 2026.1.3 Affected Upgrade to 2026.1.3 or later
Older TeamCity On-Premises release trains Affected Upgrade to a fixed release or apply the security patch plugin
TeamCity On-Premises 2017.1+ unable to upgrade immediately Patch available Install JetBrains' CVE-2026-63077 security patch plugin
TeamCity Cloud Vendor-remediated No customer action for this CVE

JetBrains recommends a full upgrade because the security patch plugin addresses only CVE-2026-63077. TeamCity versions 2017.1 through 2018.1 require a server restart after plugin installation; versions from 2018.2 can enable it without a restart.

Exploitation boundary and potential impact

JetBrains describes the vulnerability as unauthenticated command execution through the TeamCity agent polling protocol. CISA classifies it as deserialization of untrusted data (CWE-502). A network attacker with HTTP(S) access to an affected server can bypass authentication checks and execute arbitrary commands as the TeamCity service account.

A successful intrusion may expose or alter:

  • TeamCity projects, build configurations, server settings, and stored credentials;
  • source repositories and release or package-publishing workflows;
  • build artifacts and downstream CI/CD integrity;
  • connected build agents and deployment environments reachable through TeamCity's identities or network position.

Public sources available at capture time do not identify the exploit request, post-exploitation process tree, malware, source IPs, or affected organizations. Do not turn generic TeamCity traffic into an indicator without additional evidence.

Defender priorities

  1. Remove exposure and patch immediately. Upgrade to 2025.11.7 or 2026.1.3. If an emergency upgrade is impossible, install the vendor security patch plugin and schedule the full upgrade. Do not wait for the August 8 federal deadline.
  2. Preserve evidence before rebuilding. Collect TeamCity server and reverse-proxy logs, service and operating-system logs, process execution telemetry, network flows, authentication and token-use records, project configuration, plugin inventory, and source-control/audit logs.
  3. Scope from the server outward. Review commands and child processes launched by the TeamCity service, unexpected files or plugins, new users or tokens, project and build-configuration changes, modified artifacts, unusual agent enrollment or polling, and outbound connections.
  4. Audit connected trust. Investigate source-control, package registry, artifact repository, signing, cloud, deployment, and secrets-management identities available to TeamCity. Rotate credentials only after containing persistence and preserving evidence.
  5. Validate artifacts and releases. Compare builds, tags, packages, container images, and deployment manifests produced during the exposure window against known-good source and independent provenance records.
  6. Reduce the future boundary. Restrict TeamCity to trusted networks or VPN access, apply an additional access-control layer in front of internet-facing servers, run the service with least operating-system privilege, and keep the server on a dedicated host separate from build agents.

Detection limits

  • No public exploit-request signature or confirmed infrastructure was available in the CISA and JetBrains material at capture time.
  • A vulnerable or internet-reachable server is exposure evidence, not proof of exploitation.
  • Absence of a known payload is not exculpatory: arbitrary command execution can use native tools, transient scripts, stolen tokens, or modifications made through TeamCity itself.
  • CISA's KEV addition does not identify whether observed exploitation predates or follows public disclosure.

Open questions

  • Exploit request and deserialization details suitable for server, proxy, or WAF hunting.
  • First observed exploitation date, victim and sector scope, source infrastructure, and actor attribution.
  • Post-exploitation commands, persistence, credential access, build-agent movement, and artifact or release tampering.
  • Whether JetBrains or incident responders will publish log pivots, forensic artifacts, or a retrospective affected-version refinement.

Sources