TeamCity's path traversal took two years to reach KEV. That's a long time to leave a CI server exposed.

CISA added CVE-2024-27199 to the Known Exploited Vulnerabilities catalog on April 20, 2026, with a federal remediation deadline of May 4. The patch shipped March 4, 2024. That’s 25 months between “fix available” and “the government says you have to install it.” If your TeamCity On-Premises instance is still below version 2023.11.4, you are not waiting for a deadline. You are past it.

The vulnerability is a CVSS 7.3 path traversal (CWE-23) in TeamCity’s authentication filter. BianLian ransomware operators were exploiting it within days of disclosure. Metasploit modules appeared in the same week. At the time, roughly 5,700 internet-facing TeamCity instances were vulnerable worldwide. Two years later, CISA apparently still has reason to believe some of those remain unpatched.

What the bug actually does

TeamCity’s auth filter treats three URL prefixes as public: /res/, /update/, and /.well-known/acme-challenge/. If your request starts with one of those paths, no authentication check fires. The filter does not resolve ../ sequences before making that decision. So /res/../admin/diagnostic.jsp passes the prefix check (it starts with /res/) and then, after path resolution, lands on a protected admin endpoint.

The reachable surface is not trivial. Splunk’s analysis identified 15+ endpoints accessible through the traversal, including certificate upload, HTTPS port configuration, server diagnostics, and pipeline metadata. The highest-impact action: an unauthenticated attacker can replace the server’s TLS certificate and change the HTTPS port. That’s either a denial-of-service condition (HTTPS breaks for legitimate users) or a man-in-the-middle position if the replacement cert is trusted by clients.

This is distinct from its sibling, CVE-2024-27198 (CVSS 9.8), which uses a completely different bypass mechanism to gain full unauthenticated admin API access. That one creates users, issues tokens, executes code. CVE-2024-27199 cannot do those things. They share the same affected version range and the same fix, but they are independent bugs exploiting different classes of failure.

How it was used

BianLian moved fast. GuidePoint Security documented a March 2024 intrusion where the group chained both TeamCity authentication bypasses to create admin accounts and run commands under TeamCity’s service account. When their standard Go-language backdoor failed to execute, they pivoted to a PowerShell implementation for command-and-control. Post-access activity was textbook: net user, systeminfo, nltest for reconnaissance, lateral movement via winpty-agent.exe, and attempted SAM credential dumping.

A separate wave tracked by Trend Micro involved multiple unidentified actors deploying Jasmin ransomware, XMRig miners, SparkRAT, and Cobalt Strike beacons through the same entry point. Darktrace observed the first exploitation attempts on March 6, 2024, targeting financial-sector organizations. Two days after disclosure.

In most documented intrusions, CVE-2024-27198 carried the initial access (because it gives you admin). CVE-2024-27199’s role was supporting: certificate manipulation for persistence or MitM, metadata harvesting for reconnaissance. The two bugs work as a package. If you were exposed to one, you were exposed to both.

Why it took two years to reach KEV

This is the strange part. CISA added CVE-2024-27198 to KEV on March 7, 2024, three days after disclosure, citing confirmed exploitation. CVE-2024-27199 didn’t follow until April 2026. No explanation was published.

The most likely reason: ongoing opportunistic exploitation of unpatched internet-facing instances rather than a newly discovered technique. CISA has been adding older CVEs in batches throughout 2026, and the agency may be catching up on vulnerabilities where exploitation evidence was always there but the KEV entry hadn’t been prioritized. Regardless of the reason, the federal deadline was May 4. It’s now past.

The disclosure fight (useful context, not the main story)

The patch arrived with controversy. Rapid7 reported both vulnerabilities to JetBrains on February 20, 2024. JetBrains had a fix in 13 days and wanted to give customers time to patch before technical details went public. Rapid7’s policy requires publishing within 24 hours of learning a vendor has shipped a fix without coordinating the disclosure window. Rapid7 called it “silent patching.” JetBrains called it “giving customers time to patch.”

Rapid7 published the full technical writeup just over an hour after JetBrains posted CVE records. Active exploitation was observed within hours. This is a recurring disagreement in vulnerability disclosure, and neither side is entirely wrong. What matters operationally: the details were public within hours of the patch, and exploits followed immediately. The coordinated disclosure model assumed a deployment window that didn’t exist.

What to check

Version: TeamCity On-Premises below 2023.11.4 is vulnerable. Every version going back to the beginning of the product line. TeamCity Cloud was patched server-side before disclosure and was not affected.

If you can’t immediately upgrade: JetBrains published a security patch plugin compatible with versions 2018.1 through 2023.11.3. It installs through the web UI without a full version upgrade. This was a reasonable stopgap in March 2024. If you’re still relying on it in 2026, plan the upgrade.

Network exposure: If your TeamCity instance is reachable from the internet on port 8111 (the default), and it’s below 2023.11.4, assume compromise until proven otherwise. A WAF or reverse proxy blocking /../ sequences eliminates the traversal path, but that’s a compensating control, not a fix.

Detection: Any HTTP GET containing /../ within /res/, /update/, or /.well-known/acme-challenge/ that returns HTTP 200 is a strong indicator. Splunk published a Suricata rule (ID a1e68dcd-2e24-4434-bd0e-b3d4de139d58) for this pattern. Rapid7 Labs released experimental Sigma rules covering both CVEs.

Forensics: Check teamcity-activities.log for unexpected user creation or plugin installs. Check teamcity-server.log for token changes. On Windows, these live in C:\TeamCity\logs\. Look at the audit log (/admin/admin.html?item=audit) for certificate replacements or HTTPS port changes since March 4, 2024. Any evidence of CVE-2024-27199 activity should trigger a broader hunt for CVE-2024-27198 indicators: new admin accounts, unexpected build agent registrations, outbound connections to unfamiliar IPs.

The window

The federal deadline has passed. If your organization is bound by BOD 22-01, you’re already late. If you’re not bound by it but you’re still running a pre-2023.11.4 TeamCity instance on the internet, the operational reality is the same: this vulnerability has been actively exploited since March 2024, the tooling is public, and the people using it are deploying ransomware.

CI/CD servers are high-value targets because they hold credentials for everything downstream: source control tokens, deployment keys, cloud provider secrets, artifact signing certificates. A compromised TeamCity instance is not one compromised server. It’s potentially every system that server deploys to.

Two years is a long time. If you haven’t patched yet, the reason probably isn’t technical. It’s that the server is running something fragile, or the upgrade path looks expensive, or nobody owns it clearly enough to push the change through. Those are real constraints. But BianLian doesn’t care about your change board schedule, and neither does the next group that scans for port 8111. This is the kind of finding PatchDay Alert exists to surface: not new information, but a forcing function to close the gap between “we know” and “we did.”