Yes. CISA added CVE-2024-27198 to its Known Exploited Vulnerabilities catalogue on 7 March 2024, which it does only when there is reliable evidence of active exploitation. CISA lists it as known to be used in ransomware campaigns. JetBrains TeamCity contains an authentication bypass vulnerability that allows an attacker to perform admin actions. Any organisation running the affected product should treat remediation as urgent.
What makes CVE-2024-27198 urgent to confirm in your environment?
The practical question is not whether the vulnerability is real, it is whether your TeamCity estate is exposed to a known exploitation path that can turn authentication bypass into administrative control. Once an attacker can act as an admin, the next step is usually to inspect build pipelines, secrets, service integrations, and any trust relationships that TeamCity can reach.
For practitioners, the first task is to determine whether any internet-facing or internally reachable TeamCity instance is still running with the vulnerable configuration and whether administrative access could have been exercised before detection. A vulnerability like this is not just a patching issue, it is also a compromise-assessment problem because admin-level access can alter build outputs, credentials, and release trust.
One useful comparator is TeamCity CVE-2023-42793 SVR exploitation 2023, which shows how TeamCity compromise can move quickly from initial access into credential theft and broader infrastructure reach.
Why this vulnerability changes the operational risk profile
Authentication bypass matters here because TeamCity sits close to the software delivery path. If an attacker can obtain admin actions, they can often inspect build definitions, change build steps, access stored secrets, or tamper with artifacts and signing-related workflows. That creates both direct compromise risk and supply-chain risk, especially where the server has visibility into source, deployment automation, or production credentials.
This is why the safest reading is to treat the issue as a possible foothold into CI/CD trust rather than a standalone application bug. The exposure is usually highest where TeamCity is used for privileged automation, where build agents are broadly trusted, or where the server has long-lived credentials for code repositories, artifact stores, cloud platforms, or downstream deployment targets.
For broader CI/CD hardening, CI/CD Security Guide is the most relevant internal guide because it covers the pipeline controls that determine how far a compromised build system can reach.
What a good response looks like before and after remediation
Respond in two tracks at once: remove the vulnerable exposure and check for signs that admin access was already abused. If patching or upgrade must wait, restrict network reachability, isolate the instance, and reduce the blast radius of any credentials or tokens the system can touch. In practice, that means treating TeamCity like a high-value control plane until you know the instance is clean.
After remediation, review whether the server had enough privilege to expose source credentials, signing keys, deployment tokens, or reusable service accounts. If it did, rotate the material the server could access, not just the TeamCity password database. The point is to invalidate any trust the attacker may have inherited through the build system.
Where the flaw has already been exploited in the wild, the most relevant external baseline is the CISA Known Exploited Vulnerabilities Catalog, which is the authoritative source for active exploitation status and required remediation timing.
Risk and Threat Considerations
Authentication bypass on a build server is especially dangerous because the attacker is not just entering an application, they are entering a trust boundary that often has broad visibility into code, secrets, and release workflows. Once that boundary is crossed, the likely failure mode is privilege escalation into administrative actions that can modify pipelines, steal credentials, or plant malicious build output.
Failure mechanism: The attacker bypasses normal login or authorization checks, uses the resulting admin position to enumerate or alter CI/CD assets, and leverages any trusted integrations or stored secrets available to the server.
Impact: The immediate result can be build tampering, secret exposure, or deployment compromise, and the downstream result can be supply-chain contamination, lateral movement, or follow-on ransomware activity.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | TeamCity exploitation demands hardening and restricting exposed server configurations. |
| Recommendation — Harden and restrict TeamCity exposure, then validate the server against secure configuration baselines. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | The question is about urgent remediation of an actively exploited vulnerability. |
| IA-5 — Authenticator Management | Authentication bypass incidents often require rotation of exposed secrets and tokens. | |
| Recommendation — Prioritise rapid flaw remediation for the affected TeamCity deployment. Rotate any credentials, tokens, or keys that TeamCity could access before compromise was contained. | ||
| OWASP ASVS | V8 — Authorization | The vulnerability bypasses authorization boundaries and grants admin actions. |
| Recommendation — Review authorization checks around admin functions and restrict privileged paths. | ||
| MITRE ATT&CK | T1078 — Valid Accounts | If TeamCity was abused, attackers may operate using trusted access paths and credentials. |
| Recommendation — Hunt for misuse of trusted accounts and authentication paths after exposure. | ||
Practitioner Guidance
What to verify: Confirm every TeamCity instance is inventoried, externally reachable instances are prioritized first, and logs cover the period before remediation so you can test whether admin actions, configuration changes, or unusual token use occurred.
Decision rule: If the instance can reach source control, artifact storage, or deployment credentials, treat it as high impact even if there is no obvious customer-facing data exposure.
What to prioritise: Patch or isolate first, then rotate any secrets, tokens, service credentials, or signing material that the server could access, because compromise of the control plane can outlive the vulnerability itself.
Practitioner takeaway: For a build server, exploitation is not only about login bypass, it is about whether the attacker can inherit the system’s trust and use it to affect everything downstream of the pipeline.
Related resources from NHI Mgmt Group
- 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?
- CVE-2024-27198 (JetBrains TeamCity Authentication Bypass)
- Is CVE-2024-0012 (Palo Alto Networks PAN-OS Management Interface Authentication Bypass) 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 October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org