TeamCity is a continuous integration and continuous delivery server used to automate builds, tests and deployment pipelines. It runs jobs from source control changes, schedules and build triggers, and manages build agents, artefacts and pipeline variables. Access to projects, credentials and deployment steps is typically controlled through roles and permissions.
What TeamCity Does in the Delivery Pipeline
TeamCity is a build-and-release control point, so the security question is not just whether the server works, but what it can reach and what it can publish. In practice, it sits between source control, build runners, artefacts, deployment targets and the credentials needed to move code through the pipeline.
That makes TeamCity operationally important in both trusted and hostile scenarios. When it is well governed, it automates repeatable delivery. When it is weakly protected, it can become a route from source code into production systems and adjacent identity material.
Why CI/CD Servers Become High-Value Targets
CI/CD servers are attractive because they often hold broad project access, long-lived tokens, signing material and deployment permissions. A compromise can expose code, pipeline definitions, internal environments and the mechanisms used to promote software across stages. The risk is amplified when build infrastructure is reachable from the internet or is allowed to run privileged jobs without tight separation.
TeamCity is therefore best understood as a trusted automation hub rather than a simple developer tool. Its value comes from orchestration and access, which also means attackers can use it to move laterally, steal secrets or tamper with build outputs if the surrounding controls are weak.
Access, Credentials and Pipeline Trust
Because TeamCity manages project permissions, credentials and deployment steps, access design is central to its security model. Role boundaries should reflect the difference between reading build results, changing build configuration, approving releases and administering the server itself. If those boundaries are blurred, a lower-trust user or integration can inherit far more influence than intended.
Build credentials are especially sensitive because they may unlock source repositories, package registries, cloud environments or signing systems. Pipeline variables and stored tokens should be treated as operational secrets, not convenience settings. Their exposure can turn an otherwise ordinary build system into a privileged pivot point.
For a deeper view of the identity and privilege issues that arise in build automation, see TeamCity CVE-2023-42793 SVR exploitation 2023.
Exposure, Monitoring and Recovery
Exposure checks should start with asset inventory and internet reachability: which TeamCity instances exist, who can reach them, and which agents, plugins and integrations connect outward. Visibility also matters after deployment, because a compromised build server may leave altered artefacts, suspicious job definitions or changed credentials that survive the initial intrusion.
Detection should focus on unusual build behaviour, unexpected project changes, new agents, anomalous authentication events and signs that the server has been used to touch code or credentials outside normal release flow. After any suspected compromise, the review should extend beyond the server itself to signing keys, deployment tokens, service accounts and any downstream systems the pipeline could reach.
When organisations need a control baseline for the surrounding access and authentication model, NIST SP 800-53 Rev 5 Security and Privacy Controls provides a useful reference for identity, audit and configuration controls, while NIST Cybersecurity Framework 2.0 helps map govern, protect, detect, respond and recover activities around the platform.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | TeamCity stores and uses credentials that must be managed across the pipeline lifecycle. |
| AC-6 — Least Privilege | TeamCity roles and deployment permissions are a privilege boundary that should be minimized. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | TeamCity needs reviewable activity trails for builds, config changes and access events. | |
| Recommendation — Protect pipeline credentials with managed rotation, storage and revocation. Restrict build, deploy and admin permissions to the minimum required. Monitor and review build-server events for abnormal job, access and configuration changes. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication and Access Control | TeamCity depends on authenticated access and role-based control over projects and deployments. |
| DE.CM-01 — Monitoring for Anomalies and Events | TeamCity compromise is often visible through unusual build and authentication activity. | |
| Recommendation — Enforce authenticated, role-based access for projects, agents and deployment actions. Monitor TeamCity activity for unexpected jobs, logins, agents and release changes. | ||
| MITRE ATT&CK | T1078 — Valid Accounts | Compromise of TeamCity often turns legitimate credentials into an attacker foothold. |
| Recommendation — Hunt for misuse of valid TeamCity, build and deployment accounts after suspicious activity. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | TeamCity commonly manages non-human credentials and permissions that can be too broad. |
| NHI-07 — Long-Lived Secrets | TeamCity pipelines often rely on stored tokens and credentials that persist beyond a job run. | |
| NHI-02 — Secret Leakage | TeamCity can expose build secrets through logs, variables or compromised configuration. | |
| Recommendation — Scope pipeline credentials and service access to the least privilege needed. Shorten secret lifetime and remove static pipeline credentials where possible. Prevent secret exposure in logs, variables and build configuration. | ||
Practitioner Guidance
Why practitioners should care: Treat TeamCity as a privileged production-adjacent system, not as a routine support tool. The right question is not only who can log in, but who can alter jobs, read secrets, approve releases or influence agents and deployment targets.
What to watch for: Review role assignments, stored credentials, agent trust and external integrations together. Weakness in any one of those areas can turn pipeline convenience into release manipulation or credential exposure.
Practitioner takeaway: If the server can build it, it can often reach the systems that consume it, so pipeline access should be designed with the same care as production access.
Related resources from NHI Mgmt Group
- How do you patch or mitigate CVE-2024-27199 (JetBrains TeamCity Relative Path Traversal)?
- How do you patch or mitigate CVE-2024-27198 (JetBrains TeamCity Authentication Bypass)?
- Is CVE-2023-42793 (JetBrains TeamCity Authentication Bypass) being exploited in the wild?
- Is CVE-2024-27199 (JetBrains TeamCity Relative Path Traversal) being exploited in the wild?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org