Critical TeamCity bug let attackers reset their way to admin access

What’s actually confirmed

A newly published vulnerability, tracked as CVE-2026-100255, affects JetBrains TeamCity, the widely used build and continuous-integration server. According to the NVD listing, versions of TeamCity before 2026.2, 2026.1.4 and 2025.11.8 contained a flaw that allowed “administrator account takeover via password reset”. The bug has been given a CVSS score of 8.1, which lands it in the “critical” bracket.

That’s the hard, checkable bit: a specific weakness in how password resets worked, in specific version ranges, now fixed in later releases. JetBrains lists the fix on its own security issues page.

What the bug actually does

The description is terse, but the shape of the problem is clear enough: the password reset mechanism in affected TeamCity builds could apparently be manipulated in a way that let someone end up with administrator-level access to the server, rather than just their own account. For a tool like TeamCity, that matters a lot, because admin access to a build server typically means the ability to see, modify or inject code into whatever that server is compiling and deploying - which in turn can mean reaching into the software supply chain of whatever organisation runs it.

What we don’t have, from the sources available, is a technical breakdown of exactly how the reset flow was abused, what preconditions an attacker needed (network access? an existing low-privilege account? nothing at all?), or any proof-of-concept detail. Neither the NVD entry nor JetBrains’ page describes active exploitation. So while the mechanism sounds serious, the practical difficulty of pulling it off isn’t spelled out here.

So who is actually at risk

This is squarely an issue for organisations running self-hosted TeamCity instances - development teams, software houses and IT departments using it to build and deploy their own code. It is not a consumer-facing bug; ordinary users of apps or websites aren’t directly exposed by this CVE, except indirectly if a company they rely on runs a vulnerable, unpatched TeamCity server somewhere in its pipeline.

The sources don’t give any indication of how many installations are out there, nor whether JetBrains Cloud-hosted offerings were ever affected or are relevant here at all. That’s worth being upfront about: we know the vulnerable version ranges, but not the scale of exposure.

What to do about it

If you administer a TeamCity server, the action is unambiguous: update to 2026.2, 2026.1.4, 2025.11.8 or later, whichever matches your deployment track. JetBrains has already shipped fixes, per its issues-fixed page, so this isn’t a case of waiting for a patch - it’s a case of actually applying one, which is where plenty of critical vulnerabilities continue to bite organisations long after a fix exists.

For everyone else, this is background noise rather than something to act on personally. There’s no evidence here of mass exploitation, no leaked credentials tied to this specific flaw, and no reason for individual users to change behaviour.

The takeaway

A genuinely serious flaw, now fixed, in a tool that matters a great deal to the people who run it and comparatively little to anyone else. The sensible response is boring and specific: if you run TeamCity, patch it. If you don’t, there’s nothing to do here beyond noting that build servers remain an attractive target worth securing properly.