Yes. CISA added CVE-2024-27199 to its Known Exploited Vulnerabilities catalogue on 20 April 2026, 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 a relative path traversal vulnerability that could allow limited admin actions to be performed. Any organisation running the affected product should treat remediation as urgent.
When a CVE is added to CISA’s Known Exploited Vulnerabilities catalogue, the practical assumption should shift from “theoretical weakness” to “active exposure that needs immediate handling.” For TeamCity, that means treating the issue as an exploitation problem first, then narrowing the response to inventory, exposure, and containment.
Relative path traversal matters because it can let an attacker reach functions or administrative actions that were not meant to be reachable from their starting point. In a build system, that is especially serious because the product often sits close to source code, build secrets, deployment credentials, and privileged automation paths.
The fact that CISA also links the issue to ransomware campaigns raises the priority further. Even if the flaw itself is not a full takeover on its own, exploitation in a CI/CD platform can become an entry point for credential theft, lateral movement, tampering with builds, or follow-on access to other systems.
What “being exploited in the wild” means for TeamCity
For a vulnerability like this, “in the wild” is not a vague reputation label. It means defenders should assume the exploit path has been operationalised, is being used against real targets, and may already be included in opportunistic scanning or targeted intrusion chains. That changes triage from “patch when convenient” to “confirm exposure and reduce attack surface now.”
The key operational question is whether your TeamCity instance is reachable in a way that an attacker can test and abuse, especially if it is internet-facing or accessible from a broad internal network segment. If the platform is exposed, the next question is whether the instance contains sensitive build artefacts, tokens, keys, or administrative functions that would increase blast radius if accessed.
In practice, the most useful interpretation is that TeamCity should be handled like a high-value control plane. Even limited administrative actions can be enough to change projects, alter build steps, leak secrets, or create persistence that is harder to detect than a direct endpoint compromise.
Why build servers become high-value targets
CI/CD systems concentrate trust. They often know how to reach source repositories, package registries, signing services, cloud environments, and deployment targets. A flaw that allows an attacker to move through TeamCity’s trust boundaries can therefore matter more than a typical web application issue, because the downstream permissions are often much more powerful than the user interface suggests.
That concentration effect is what makes exploitation so attractive to attackers. Rather than working through a single workstation, they may be able to reach the software delivery path itself, which can expose secrets, influence what gets built, and create secondary access into other environments. This is why path traversal in a build platform is not just a correctness bug, it is an access-path problem.
For teams running multiple environments, the practical concern is cross-environment reach. If the same platform or credentials are reused broadly, a compromise in one place can become an entry point elsewhere. That makes inventory, segmentation, and secret handling part of the response, not just patch deployment.
How to respond when patching cannot happen immediately
Priority one is to confirm whether any TeamCity instance is present, reachable, and exposed to the trust zone an attacker could realistically access. If you cannot patch immediately, reduce exposure by limiting network reachability, restricting administrative access paths, and reviewing whether the service can be isolated until remediation is complete.
Then check whether the platform could have already been used as a foothold. Look for unusual administrative actions, unexpected project changes, strange build configuration edits, new tokens or credentials, abnormal outbound connections, and evidence that the server touched systems it normally should not reach. In a build environment, compromise often shows up first as integrity drift rather than obvious malware.
If the instance had access to credentials or session material, rotate the material that could have been exposed. The same is true for service accounts or deployment integrations that TeamCity could authenticate as, because an attacker does not need the original flaw to persist once they have stolen the access path it opened.
Risk and Threat Considerations
Active exploitation means the main risk is no longer the flaw itself, but the speed with which an exposed build server can become a launch point for deeper compromise. In CI/CD environments, the most damaging outcomes are often secret exposure, build tampering, and lateral movement into source, release, or cloud systems.
Failure mechanism: Relative path traversal can let an attacker reach administrative or adjacent resources that should have been outside their normal scope, especially when the application exposes high-trust functions behind a web interface.
Impact: If those functions can touch secrets, build configuration, or privileged automation, the result can be credential theft, persistence, malicious build changes, or downstream access to other systems that rely on the same trust chain.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Prioritises rapid remediation of actively exploited software flaws. |
| Recommendation — Patch or isolate exposed TeamCity instances using continuous vulnerability management priorities. | ||
| NIST SP 800-53 Rev 5 | RA-5 — Vulnerability Monitoring and Scanning | Supports locating affected instances and verifying exposure to the CVE path. |
| SI-2 — Flaw Remediation | Covers fixing the vulnerable software and validating remediation. | |
| AC-6 — Least Privilege | Limits blast radius if TeamCity administrative reach is abused. | |
| Recommendation — Scan for TeamCity exposure and confirm vulnerable instances are identified and tracked. Apply flaw remediation procedures and verify the TeamCity fix is deployed. Restrict TeamCity service and admin privileges to the minimum required. | ||
| ISO/IEC 27001:2022 | A.8.8 — Management of technical vulnerabilities | Directly addresses handling known exploitable product flaws. |
| Recommendation — Treat the TeamCity flaw under technical vulnerability management and urgent remediation. | ||
Practitioner Guidance
What to verify: Confirm whether any TeamCity instance is internet-facing, whether it holds sensitive build credentials, and whether the server has access to production-adjacent systems or signing infrastructure. Those three facts determine whether exposure is urgent or critical.
Decision rule: If the server can authenticate to anything beyond its own local build workload, treat compromise as potentially cross-environment and rotate the credentials and tokens that were reachable from it before you assume the host is clean.
What good looks like: A remediated TeamCity deployment should have tightly scoped network access, minimal credential reach, auditable administrative changes, and a documented check for secret rotation and compromise review after patching.
Practitioner takeaway: For exploited CI/CD flaws, the right question is not “was the vulnerability severe enough?”, it is “what trust paths did this server open, and what must now be assumed exposed?”
Related resources from NHI Mgmt Group
- Guide: CI/CD Security Guide
- How do you patch or mitigate CVE-2024-27199 (JetBrains TeamCity Relative Path Traversal)?
- CVE-2024-27199 (JetBrains TeamCity Relative Path Traversal)
- Is CVE-2024-13159 (Ivanti Endpoint Manager (EPM) Absolute Path Traversal) being exploited in the wild?
- Is CVE-2024-13161 (Ivanti Endpoint Manager (EPM) Absolute Path Traversal) being exploited in the wild?