CISA has added CVE-2026-63077, an unauthenticated remote-code-execution flaw in JetBrains TeamCity On-Premises, to its Known Exploited Vulnerabilities catalog after determining that the vulnerability is being actively exploited. For administrators running TeamCity on Windows Server, Linux, or container hosts, the operational message is immediate: update to TeamCity 2025.11.7 or 2026.1.3, or deploy JetBrains’ interim security patch plugin where an upgrade cannot yet be completed.
The addition changes the status of a vulnerability that JetBrains disclosed on July 27 as critical but, at that time, not known to be exploited. CISA’s August 5 catalog entry is more than a severity upgrade or a generic government warning: it means CISA has evidence of real-world exploitation of a flaw that permits a remote, unauthenticated party to execute operating-system commands as the TeamCity server process.
CISA’s notice identifies the issue as a deserialization-of-untrusted-data vulnerability. The National Vulnerability Database record confirms the underlying weakness as CWE-502 and records the material change made by CISA on August 5: its exploitation assessment moved from “none” to “active,” while the agency’s assessment continues to classify the flaw as automatable and capable of total technical impact.
JetBrains says CVE-2026-63077 affects all TeamCity On-Premises versions. The vulnerable path is TeamCity’s agent polling protocol, and a remote attacker with HTTP or HTTPS access can bypass authentication and run arbitrary OS commands with the privileges assigned to the TeamCity server service.
That distinction is important for Windows administrators because TeamCity frequently holds more than build definitions. A server may have access to source repositories, artifact stores, code-signing tools, package feeds, cloud credentials, deployment service accounts, and secrets provided through build parameters or environment variables. A compromise at the TeamCity server is therefore capable of altering both the build process and the software it produces.
JetBrains explicitly warns that successful exploitation can expose stored credentials and configuration, alter server state, and compromise build artifacts and downstream CI/CD pipelines. Security Affairs independently reported the flaw as allowing unauthenticated command execution and server takeover on affected on-premises deployments.
The vulnerable server process’s permissions determine how far an attacker can go on the host itself. A TeamCity service running under a highly privileged local or domain account creates a far wider Windows compromise path than one running under a constrained dedicated identity. The CVE does not need a privileged TeamCity account or a build agent credential; the authentication bypass occurs before either becomes relevant.
The public record does not say who is exploiting CVE-2026-63077, which targets they selected, whether a proof of concept is public, or whether the activity is broad opportunistic scanning or targeted intrusion. CISA’s alert provides none of those details, and no independent reporting located at publication time identifies an actor, malware family, or victim set.
Administrators should not treat the lack of those specifics as reassurance. CISA’s Known Exploited Vulnerabilities catalog is intended to flag flaws with verified exploitation evidence, not to serve as an attribution bulletin. In practical terms, the catalog addition removes the last reasonable basis for regarding this as a patch-to-schedule issue.
There is also a useful timeline buried in the underlying CVE record. JetBrains received the report privately on July 10, released fixed TeamCity builds on July 27, and initially said exploitation had not been observed. CISA updated the CVE’s SSVC—Stakeholder-Specific Vulnerability Categorization—record at 17:46 UTC on August 5 to flag exploitation as active. That gives defenders a short interval between public patch availability and CISA’s exploitation confirmation, but it does not reveal when attacks actually began.
For servers that cannot be upgraded immediately, JetBrains has issued a security patch plugin covering TeamCity 2017.1 and later. That is a valid short-term mitigation for this one CVE, but it is not a substitute for bringing an old TeamCity deployment onto a supported, current release. JetBrains says the plugin addresses only CVE-2026-63077; it does not carry the more than 20 security fixes included in each of the two July maintenance releases.
There is an operational wrinkle for older installations: JetBrains says TeamCity 2017.1 through 2018.1 requires a server restart after the plugin is installed. TeamCity 2018.2 and newer can enable the plugin without restarting the server. Administrators on TeamCity 2024.03 and later may see the available patch through the product’s Administration > Updates workflow if security-patch notifications are configured, but that should be verified rather than assumed.
TeamCity Cloud customers do not need to apply an update. JetBrains says it has already applied the needed protections to its hosted service and found no evidence that its TeamCity Cloud environments were exploited through this vulnerability. That assurance does not extend to self-hosted TeamCity instances, including installations hosted in a cloud tenant but administered by the customer.
CVE-2026-63077 checks three of those boxes across the board: it is now a KEV entry, CISA rates exploitation as automatable, and CISA rates the technical impact as total. A TeamCity server exposed directly to the public internet meets the fourth condition. Under BOD 26-04, that puts a Federal Civilian Executive Branch deployment into the highest-risk category, requiring remediation within three calendar days and forensic triage to determine whether the asset was compromised before the patch is applied.
CISA’s August 5 alert does not publish an instance-specific remediation date, affected-agency list, or a count of exposed TeamCity servers. Private-sector organizations are not bound by BOD 26-04, but the logic applies cleanly to them: an externally reachable CI server with an exploited pre-authentication RCE should be handled as an incident candidate, not merely as an overdue maintenance task.
For internet-facing or otherwise untrusted-network-reachable servers, restrict access immediately to trusted build-agent networks and administrator paths while the update is staged. JetBrains recommends limiting TeamCity network access and placing public-facing deployments behind a VPN or an additional access-control layer. Network restriction reduces exposure, but it cannot establish that an already-exposed server was not accessed.
A sensible response sequence is:
CISA’s notice identifies the issue as a deserialization-of-untrusted-data vulnerability. The National Vulnerability Database record confirms the underlying weakness as CWE-502 and records the material change made by CISA on August 5: its exploitation assessment moved from “none” to “active,” while the agency’s assessment continues to classify the flaw as automatable and capable of total technical impact.
TeamCity servers need to be treated as potentially exposed
JetBrains says CVE-2026-63077 affects all TeamCity On-Premises versions. The vulnerable path is TeamCity’s agent polling protocol, and a remote attacker with HTTP or HTTPS access can bypass authentication and run arbitrary OS commands with the privileges assigned to the TeamCity server service.That distinction is important for Windows administrators because TeamCity frequently holds more than build definitions. A server may have access to source repositories, artifact stores, code-signing tools, package feeds, cloud credentials, deployment service accounts, and secrets provided through build parameters or environment variables. A compromise at the TeamCity server is therefore capable of altering both the build process and the software it produces.
JetBrains explicitly warns that successful exploitation can expose stored credentials and configuration, alter server state, and compromise build artifacts and downstream CI/CD pipelines. Security Affairs independently reported the flaw as allowing unauthenticated command execution and server takeover on affected on-premises deployments.
The vulnerable server process’s permissions determine how far an attacker can go on the host itself. A TeamCity service running under a highly privileged local or domain account creates a far wider Windows compromise path than one running under a constrained dedicated identity. The CVE does not need a privileged TeamCity account or a build agent credential; the authentication bypass occurs before either becomes relevant.
CISA’s timing exposes the key change since disclosure
JetBrains’ July 27 advisory stated that it was not aware of active exploitation when it published its patch. That statement was accurate at the time it was made, based on the vendor’s knowledge. CISA’s August 5 update establishes that the situation has since changed.The public record does not say who is exploiting CVE-2026-63077, which targets they selected, whether a proof of concept is public, or whether the activity is broad opportunistic scanning or targeted intrusion. CISA’s alert provides none of those details, and no independent reporting located at publication time identifies an actor, malware family, or victim set.
Administrators should not treat the lack of those specifics as reassurance. CISA’s Known Exploited Vulnerabilities catalog is intended to flag flaws with verified exploitation evidence, not to serve as an attribution bulletin. In practical terms, the catalog addition removes the last reasonable basis for regarding this as a patch-to-schedule issue.
There is also a useful timeline buried in the underlying CVE record. JetBrains received the report privately on July 10, released fixed TeamCity builds on July 27, and initially said exploitation had not been observed. CISA updated the CVE’s SSVC—Stakeholder-Specific Vulnerability Categorization—record at 17:46 UTC on August 5 to flag exploitation as active. That gives defenders a short interval between public patch availability and CISA’s exploitation confirmation, but it does not reveal when attacks actually began.
The patched versions and plugin are not interchangeable
JetBrains fixed CVE-2026-63077 in TeamCity 2026.1.3, build 222742, and TeamCity 2025.11.7, build 208264. Both releases were issued on July 27. The vendor’s download history confirms that 2026.1.3 is the current release in the 2026.1 line, while 2025.11.7 is the maintained patch release for the 2025.11 branch.For servers that cannot be upgraded immediately, JetBrains has issued a security patch plugin covering TeamCity 2017.1 and later. That is a valid short-term mitigation for this one CVE, but it is not a substitute for bringing an old TeamCity deployment onto a supported, current release. JetBrains says the plugin addresses only CVE-2026-63077; it does not carry the more than 20 security fixes included in each of the two July maintenance releases.
There is an operational wrinkle for older installations: JetBrains says TeamCity 2017.1 through 2018.1 requires a server restart after the plugin is installed. TeamCity 2018.2 and newer can enable the plugin without restarting the server. Administrators on TeamCity 2024.03 and later may see the available patch through the product’s Administration > Updates workflow if security-patch notifications are configured, but that should be verified rather than assumed.
TeamCity Cloud customers do not need to apply an update. JetBrains says it has already applied the needed protections to its hosted service and found no evidence that its TeamCity Cloud environments were exploited through this vulnerability. That assurance does not extend to self-hosted TeamCity instances, including installations hosted in a cloud tenant but administered by the customer.
Internet exposure determines the federal urgency
CISA’s new Binding Operational Directive 26-04 ties federal remediation deadlines to the exposure and impact of a vulnerability rather than applying a uniform clock to every KEV entry. The policy considers whether an asset is publicly exposed, whether the flaw is in the KEV catalog, whether exploitation can be automated, and whether an attacker obtains total control.CVE-2026-63077 checks three of those boxes across the board: it is now a KEV entry, CISA rates exploitation as automatable, and CISA rates the technical impact as total. A TeamCity server exposed directly to the public internet meets the fourth condition. Under BOD 26-04, that puts a Federal Civilian Executive Branch deployment into the highest-risk category, requiring remediation within three calendar days and forensic triage to determine whether the asset was compromised before the patch is applied.
CISA’s August 5 alert does not publish an instance-specific remediation date, affected-agency list, or a count of exposed TeamCity servers. Private-sector organizations are not bound by BOD 26-04, but the logic applies cleanly to them: an externally reachable CI server with an exploited pre-authentication RCE should be handled as an incident candidate, not merely as an overdue maintenance task.
What to do before normal build activity resumes
The first task is to identify every TeamCity On-Premises server, including old Windows installers, archived deployments, recovery environments, and Docker-based installations that may not appear in ordinary software inventory. The tested safe version targets are 2025.11.7 or 2026.1.3 and later; branch names matter, because simply being on a 2025 or 2026 major release is not sufficient.For internet-facing or otherwise untrusted-network-reachable servers, restrict access immediately to trusted build-agent networks and administrator paths while the update is staged. JetBrains recommends limiting TeamCity network access and placing public-facing deployments behind a VPN or an additional access-control layer. Network restriction reduces exposure, but it cannot establish that an already-exposed server was not accessed.
A sensible response sequence is:
- Preserve relevant TeamCity server, web-proxy, authentication, and Windows Event logs before cleanup or reinstallation changes their retention state.
- Review TeamCity service-account privileges, recently created local accounts, scheduled tasks, service changes, newly installed plugins, and unexpected child processes launched by the TeamCity service.
- Audit recent build configurations, build steps, artifact changes, VCS-root settings, secure parameters, and deployment credentials for unauthorized modifications.
- Rotate secrets that TeamCity could have read or injected into builds, prioritizing repository tokens, cloud credentials, package-feed credentials, signing keys, and deployment service-account passwords.
- Upgrade to a fixed release where possible; use the plugin only as the narrow stopgap JetBrains describes.
References
- Primary source: CISA
Published: 2026-08-05T12:00:00+00:00
Loading…
www.cisa.gov - Related coverage: nvd.nist.gov
Loading…
nvd.nist.gov - Related coverage: securityweek.com
CISA Directs Federal Agencies to Prioritize Security Patches Based on Risk - SecurityWeek
CISA’s new BOD 26-04 requires federal agencies to prioritize the remediation of vulnerabilities in the KEV catalog, based on risk.www.securityweek.com
- Related coverage: nucleussec.com
What is CISA BOD 26-04? Prioritizing Security Updates Based on Risk
CISA BOD 26-04 directs federal agencies to prioritize vulnerability remediation based on exposure, exploitability, system control, and known exploitation. Learn what the directive requires and how it impacts agency vulnerability management.nucleussec.com - Related coverage: crowdstrike.com
Loading…
www.crowdstrike.com - Related coverage: tlctc.net
CISA BOD 26-04: A Step in the Right Direction — But Still Not an Attack-Path Model | TLCTC
CISA's BOD 26-04 moves federal vulnerability management toward risk-based remediation — but it still lacks a cause-side attack-path grammar. TLCTC provides the missing layer.www.tlctc.net - Related coverage: certcc.github.io
Loading…
certcc.github.io - Related coverage: minimus.io
Understanding CISA BOD 26-04 - Minimus
CISA BOD 26-04 shifts vulnerability management toward risk-based prioritization. Here's what changed and what it means in practice.www.minimus.io - Related coverage: legalclarity.org
Loading…
legalclarity.org - Related coverage: tonicsecurity.com
CISA BOD 26-04 & The End of CVSS Severity | Tonic Security
CISA's new BOD 26-04 directive moves federal cybersecurity away from static CVSS severity scores toward risk-based exposure management.www.tonicsecurity.com