The build server is part of the supply chain

What happened

CISA added CVE-2026-63077 to its Known Exploited Vulnerabilities catalogue on 5 August, saying there is evidence of active exploitation. The vulnerability affects JetBrains TeamCity, a platform used to build, test and release software. CISA describes the issue as deserialisation of untrusted data and urges organisations to prioritise remediation of catalogue vulnerabilities according to risk.

JetBrains says an unauthenticated attacker with HTTP or HTTPS access to an affected TeamCity server could bypass authentication and execute operating-system commands with the privileges of the TeamCity server process. The vendor was not aware of active exploitation when it published its advisory on 27 July; CISA's later catalogue entry changes the current position. Neither source describes the scale of exploitation, identifies victims or links the activity to ransomware, so those points remain unknown.

Who is affected

JetBrains says all versions of TeamCity On-Premises are affected. The issue is fixed in versions 2025.11.7 and 2026.1.3. TeamCity Cloud customers do not need to act on this vulnerability because JetBrains says the necessary measures have already been applied, and it found no evidence that TeamCity Cloud environments had been exploited through this flaw.

For operators unable to upgrade immediately, JetBrains provides a security patch plugin for TeamCity 2017.1 and later. The vendor is clear that the plugin addresses only CVE-2026-63077, whereas upgrading also brings other security updates. Teams should therefore regard the plugin as a narrow mitigation, not evidence that an ageing deployment is fully current.

Why a build server deserves urgent attention

A successful attack may reach TeamCity data, configuration and stored credentials, alter server state and undermine the integrity of build artefacts or downstream delivery pipelines. That combination matters because a build server does more than host an administrative screen: it often sits between source code, signing or deployment credentials and the systems receiving a release.

Internet exposure raises the immediate likelihood of contact, but an internal instance is not harmless. Compromised user devices, supplier connections and poorly separated networks can also provide a route to a reachable service. Exact inventory, version and access path matter more than a general assurance that TeamCity is 'not public'.

What defenders should do now

Identify every TeamCity On-Premises server, including development, standby and legacy instances, and record its exact version and network reachability. Upgrade to 2025.11.7 or 2026.1.3 using JetBrains' supported process. Where an immediate upgrade is genuinely impossible, apply the vendor's patch plugin to a supported eligible version and plan the full upgrade rather than leaving the exception open-ended.

Because exploitation is confirmed, remediation should include a review for earlier access. Preserve relevant TeamCity, proxy, identity, host and network logs before maintenance or retention limits change them. Investigate unexplained administrative changes, processes, build configuration edits, credential use and release activity through the organisation's incident-response process. Do not improvise exploit testing against a production server; it can disrupt service and alter useful evidence.

Restrict TeamCity access to trusted networks or a controlled remote-access route, and run the server with the minimum operating-system privileges it needs. JetBrains also recommends separating TeamCity servers from build agents. These controls reduce opportunity and consequence, but they do not replace the update or establish that a previously exposed server was untouched.

• Inventory every on-premises TeamCity server and confirm its exact release.
• Upgrade to 2025.11.7 or 2026.1.3, or apply the vendor's narrow patch plugin where necessary.
• Preserve evidence and investigate activity that predates remediation.
• Review stored credentials and rotate them where compromise is suspected.
• Limit network access and separate the server from its build agents.

The Beekeeper view

Build infrastructure is easy to classify as an internal development concern, yet it can exercise production-grade authority. If attackers can influence what the business compiles or releases, the security boundary extends beyond the TeamCity host to every credential, artefact and destination it can reach.

For UK businesses, the useful assurance question is concrete: can the team name every TeamCity server, show who can reach it, prove which fixed version it runs and explain what was checked for activity before the update? A clean patch report answers only one of those questions.