TeamCity CVE-2024-27198: EPSS 0.999 two years past patch

CVE-2024-27198 is a pre-authentication bypass in JetBrains TeamCity’s web component. A crafted request reaches an admin action path without going through the authentication layer first, and an unauthenticated attacker gets to do anything a TeamCity admin can — including creating new admin accounts. Rapid7 disclosed the bug on 4 March 2024, JetBrains shipped the fixed 2023.11.4 build the same day, and mass scanning followed within days.

As of the FIRST.org EPSS refresh on 2026-07-07, it still scores 0.99938. That’s the effective ceiling of the scale. Two years and four months after the patch was available, the scanning against unpatched TeamCity instances hasn’t tapered. CISA added the bug to the Known Exploited Vulnerabilities catalog in the same window after ransomware-affiliated actors were observed poisoning builds through the flaw; it has never come off.

Why the tail is this long

TeamCity is a CI/CD server. It builds code, signs artifacts, and pushes them to whatever downstream systems consume — package repositories, container registries, customer-facing installers. Compromise a TeamCity instance and you own the software supply chain of everything that instance ships. That’s why the exploitation was aggressive in 2024. It’s also why the bug was never a candidate for “we’ll get to it next quarter.”

The residual population is TeamCity servers that were reachable in 2024 and never got the update. Some are shadow-IT — a team stood one up for a project, the project ended, the server didn’t. Some are on-prem installs behind a corporate perimeter that was assumed to be enough. Some are on unsupported branches where the maintainer left the company. The scanning measures all three. EPSS doesn’t care why the instance is exposed — only that it is, and that attackers keep trying.

What to actually do

If your organization runs TeamCity anywhere, at any version, do these three this week.

1. Inventory every instance. Not what’s in the CMDB — what’s actually running the TeamCity JAR. Include old test environments, partner-hosted builds, and anything stood up during a migration that outlived the migration. Check both internal networks and public IP space. The public-IP hits are the emergency.

2. If it’s pre-2023.11.4, don’t just patch — assume compromise. A pre-auth admin bypass leaves no reliable forensic difference between a scanned instance and a persisted one. Review the admin-account list for accounts nobody recognizes. Walk build history for unauthorized pipeline edits since February 2024. Rotate every credential the server has ever held — signing keys, deploy tokens, package-registry credentials — and re-issue any artifacts built inside the exposure window if you can’t independently verify the pipeline was clean at the time.

3. If it’s internet-facing, get it off the internet. Put it behind SSO/VPN, ACL it to the source IPs that actually need to build, and turn off inbound HTTP from anywhere else. A TeamCity admin plane is not something that should be reachable from a scanning botnet in 2026.

Priority call

Handle this before you triage any lower-severity 2026 findings against the same asset. A CI/CD server with an unpatched pre-auth admin bypass is more exposed than most of what’s on your queue today, regardless of vintage. Read our earlier asyncapi npm supply-chain writeup if you need the reminder of what a poisoned build pipeline actually costs downstream. The exposure math on TeamCity has not moved.

Full technical detail lives in the /cve/cve-2024-27198/ entry and in the NVD record for CVE-2024-27198.