|
 |
#254: TeamCity, Ransomware and the New Value of Development Infrastructure
Turning real disasters into real lessons
|
| |||||||||||||||
Advance Your Blue Team Career With 4 GIAC Certifications
 |
Build advanced skills in threat detection, network security, incident response, and security operations through SANS Technology Institute’s accredited Graduate Certificate in Cyber Defense Operations. Designed for working professionals, the flexible program combines hands-on SANS training with 4 GIAC certifications you can earn while continuing your career.
Use employer education benefits to help fund your education and put new skills to work immediately.
Ransomware operators have spent years looking for exposed systems that provide a reliable route into an organisation. Remote access services, VPN appliances, firewalls and internet-facing applications remain common targets, but development infrastructure is increasingly part of the same attack surface.
The latest example is JetBrains TeamCity. In July 2026, JetBrains disclosed CVE-2026-63077, a critical unauthenticated remote-code-execution vulnerability affecting TeamCity On-Premises. An attacker with HTTP or HTTPS access to a vulnerable server can exploit the TeamCity agent polling protocol and execute operating-system commands with the privileges of the TeamCity server process. JetBrains subsequently confirmed active exploitation, while the Australian Signals Directorate’s Australian Cyber Security Centre reported exploitation of the vulnerability against TeamCity servers in Australia. On 24 September, CISA updated its Known Exploited Vulnerabilities information to identify the flaw as being exploited by ransomware groups.
The technical vulnerability is serious on its own, but the more interesting security issue is where TeamCity sits. A CI/CD server is not simply another application server. It can have access to source repositories, build agents, credentials, artefact stores, cloud infrastructure and deployment systems. A compromise can therefore provide an attacker with access to a collection of trusted systems and automated processes.
This is why the TeamCity case matters to ransomware defence. The initial target is not necessarily the organisation’s data. It is a system that can provide the attacker with access to the infrastructure surrounding that data.
The vulnerability: unsafe deserialisation in the agent protocol
CVE-2026-63077 is an unsafe-deserialisation vulnerability in TeamCity’s agent polling protocol. It has a CVSS 3.1 score of 9.8 and does not require authentication. All versions of TeamCity On-Premises were affected; JetBrains fixed the vulnerability in versions 2025.11.7 and 2026.1.3.
TeamCity uses a central server to coordinate build agents. The agents register with the server, poll for commands and return build results. This communication is handled through endpoints under /app/agents/v1. Rapid7’s analysis found that these endpoints could process unauthenticated requests containing attacker-controlled XML.
The XML is processed using XStream, a Java library that serialises and deserialises Java object graphs. Object deserialisation is a common source of vulnerabilities because the input can define the objects that an application creates and the relationships between them. If an attacker can cause classes with useful side effects to be instantiated, a chain of otherwise legitimate components can sometimes be turned into arbitrary code execution.
TeamCity attempted to restrict the classes available during deserialisation through an allowlist. The implementation, however, added TeamCity’s permitted classes to XStream’s existing permissions rather than first removing those default permissions. Rapid7’s analysis identifies the missing NoTypePermission.NONE restriction as the key root cause. The patched implementation establishes a genuinely restrictive starting point before applying the TeamCity-specific allowlist.
The distinction is important. The problem was not simply that TeamCity had forgotten to check whether a user was logged in. The unauthenticated agent protocol exposed a deserialisation mechanism whose security restrictions could be bypassed by constructing a suitable Java object graph.