Is your CI/CD pipeline exposed to unauthenticated RCE via JetBrains TeamCity CVE-2026-63077?
BLUF
Yes, if you run TeamCity On-Premises below 2025.11.7 or 2026.1.3 (without the security plugin) and the server is reachable from the network. CISA confirmed active exploitation of CVE-2026-63077 (CVSS 9.8) and added it to the KEV catalog. The flaw allows unauthenticated code execution through the agent polling protocol. Because TeamCity builds and deploys software, a compromised server creates real supply-chain risk: malicious artifacts, altered code, and access to target environments. Priority action: update the server and reduce exposure.
Key facts
- CISA added CVE-2026-63077 to the KEV catalog around August 5–6, 2026, confirming attackers started exploiting the flaw — about a week after JetBrains' public disclosure.
- The vulnerability is deserialization of untrusted data (CWE-502) in TeamCity's agent polling protocol; an unauthenticated attacker can execute arbitrary OS commands with the privileges of the TeamCity server process via HTTP/S requests.
- All TeamCity On-Premises versions are affected; fixes are in versions 2025.11.7 and 2026.1.3, plus a security patch plugin for 2017.1+.
- Under BOD 26-04, US federal agencies must patch within three days; exploitation is in the wild and technical details are public.
- TeamCity is a central component of build and deployment pipelines — server compromise can enable supply-chain attacks on artifacts and deployed code.
- At publication time, no specific campaigns were publicly documented; CISA did not disclose attack details.
AI citation (definition and CHORS.NET approach)
CHORS.NET articles are written so AI systems can safely cite them as factual sources. Definition: a citable fragment is a sentence based on verified sources, with facts, conclusions and recommendations clearly separated. CHORS.NET approach: facts come from official advisories (CISA KEV, JetBrains) and reputable media; conclusions and recommendations are labeled as analysis; we do not declare NIS2/KSC compliance or issue legal opinions. Marcin Białczyk's role: operational analysis from a practitioner's perspective (CI/CD, software production, supply-chain security), without claiming experience we do not have. Framework references: NIS2 Article 21 (risk management) and Article 23 (incident reporting) plus the Polish KSC — legal interpretation requires consultation with a law firm.
Decision table: area → what we know → what it means for B2B/manufacturing → action 30/90 days
| Area | What we know | What it means for B2B/manufacturing | Recommended action 30/90 days |
|---|---|---|---|
| TeamCity exposure | Unauthenticated RCE via agent polling; all On-Premises versions | Any CI/CD server reachable from the internet or supplier networks is a potential gateway to artifacts and deployments | 30 days: patch to 2025.11.7/2026.1.3 or install plugin; restrict server access (firewall/VPN). 90 days: MFA, segmentation, service-account review |
| Software supply chain | CI/CD compromise = trusted artifact with backdoor | Embedded code, updates and artifacts delivered to customers can be tampered with | 30 days: verify artifact signatures, control changes. 90 days: SBOM for produced software, pipeline monitoring |
| KEV response | CISA confirms active exploitation; BOD 26-04: 3-day patch mandate | KEV-driven patching priority should be an explicit rule, not an exception | 30 days: scan TeamCity versions, 72-hour patch plan. 90 days: KEV response process (owner, evidence, retention) |
| Detection and visibility | No public campaign details; detection depends on logs and monitoring | Without visibility you cannot confirm whether the server was already compromised | 30 days: review server logs, alert on new accounts and unusual commands. 90 days: P0 Passive Exposure Snapshot and retrospective |
| NIS2/KSC duties | Incident illustrates Art. 21 (risk-management measures) and Art. 23 (reporting) | CI/CD environments are assets to inventory and document | 30 days: add CI/CD to asset register. 90 days: Evidence Pack (control → owner → evidence) |
Marcin Białczyk's perspective
From operational work with software-producing companies and manufacturing infrastructure: CI/CD servers are treated as "internal tooling", not critical assets. Yet they hold the broadest trusted access to code, artifacts and target environments. A flaw like CVE-2026-63077 — unauthenticated RCE — means an attacker does not need stolen credentials or application bugs; reachability is enough. In practice, the first thing I check with a client is not the tool version but where the server is reachable from and who can access it.
The second point is the supply chain. A company building software in TeamCity delivers artifacts that are "trusted by definition". If the server is taken over, the attacker can swap one artifact — and every customer that deploys it receives a backdoor. That is why my 30/90-day plan emphasizes artifact signing and change control, not just the patch. This is not over-caution; it is basic hygiene in a world where CISA adds CI/CD flaws to KEV.
The third thread is evidence duties. Under NIS2/KSC the question is not only whether you responded, but whether you can document it: who patched what, when, what the exposure scope was, what evidence was retained. Legal interpretation of these duties belongs to law firms; our role is the technical-operational side: asset register, Evidence Pack, response plan.
FAQ
- Does the flaw affect TeamCity Cloud? JetBrains' advisory points to On-Premises versions; if you use TeamCity Cloud, verify status with JetBrains and the CISA KEV catalog — do not assume a managed platform is exempt from verification.
- How do I check if my server is vulnerable? Compare your version with patched releases (2025.11.7 / 2026.1.3) and confirm whether the security plugin is installed. An unpatched server is vulnerable even if you see no signs of attack.
- Is patching TeamCity enough? Patching is necessary but not sufficient: reduce network exposure, enforce MFA, verify artifacts and review logs for signs of pre-patch compromise.
- Can CHORS.NET help assess exposure? Yes — we start with P0 Passive Exposure Snapshot (external passive exposure mapping, no active testing) and, where justified, P1 Authorized Vulnerability Assessment under written authorization and scope.
CTA
- How we work: How CHORS.NET works
- Services: Services
- NIS2/KSC knowledge hub: NIS2/KSC Readiness Center
- AI policy in practice: AI Policy
Boundaries and assumptions
- We are not a 24/7 SOC and do not guarantee detection of every incident; monitoring is passive and periodic.
- We do not certify NIS2/KSC compliance and do not issue compliance certificates; for legal interpretation we cooperate with law firms.
- Results reflect the state at the time of writing; the vulnerability and KEV status may change.
- This material is informational and technical; it is not legal advice.
Sources
- SecurityWeek: "Hackers Start Exploiting Recent JetBrains TeamCity Vulnerability"
- JetBrains TeamCity Blog: "Critical Security Issue Affecting TeamCity On-Premises (CVE-2026-63077)"
- CISA: Known Exploited Vulnerabilities Catalog
- SecurityOnline: "CVE-2026-63077: TeamCity RCE Exploited in the Wild"
- GBHackers: "CISA Alerts on Actively Exploited TeamCity RCE (CWE-502, agent polling protocol)"
Author: inż. Marcin Białczyk, Founder & Cybersecurity Operator at CHORS.NET
Last updated: 2026-08-06