|
 |
Data Sovereignty and Databricks Don’t Have to Be a Tradeoff
 |
For security and compliance teams, moving regulated data into the cloud to analyze it is a nonstarter. MinIO AIStor lets Databricks query that data live, on-prem, read-only, and enforced at the storage layer—so nothing has to leave your control to get analyzed. GDPR, HIPAA, and residency mandates stay satisfied by design, not by exception. Databricks named MinIO its ISV Storage Partner of the Year for exactly this kind of architecture. Watch the joint MinIO and Databricks session for the full technical walkthrough.
Ransomware attacks have traditionally been associated with endpoints, remote access services, exposed servers and stolen credentials. That model remains common, but ransomware operators increasingly target systems that provide access to other parts of an organisation. Development infrastructure is one such target.
The latest example is JetBrains TeamCity, a continuous integration and continuous delivery (CI/CD) platform used to build, test and deploy software. A critical vulnerability, CVE-2026-63077, allows an unauthenticated attacker to execute operating system commands on an affected TeamCity On-Premises server. JetBrains released patches in July 2026, but exploitation followed quickly. The Australian Signals Directorate’s Australian Cyber Security Centre reported active exploitation of the vulnerability, and in September the US Cybersecurity and Infrastructure Security Agency (CISA) identified CVE-2026-63077 as being exploited by ransomware groups.
The significance of the vulnerability extends beyond the compromised server itself. TeamCity can have access to source code, build agents, credentials, cloud services, package repositories and deployment systems. A successful compromise can therefore provide an attacker with a position inside the software development environment and potentially access to systems far beyond the original vulnerable host.
This makes TeamCity a useful example of a broader change in ransomware operations. Attackers are looking for infrastructure that provides leverage. The most valuable system is not necessarily the one containing the most data; it can be the one with the most useful relationships and permissions.
What is the TeamCity vulnerability?
CVE-2026-63077 is an unauthenticated remote-code-execution vulnerability affecting TeamCity On-Premises. An attacker needs network access to a vulnerable TeamCity server over HTTP or HTTPS but does not need a valid TeamCity account.
The vulnerable code is associated with TeamCity’s agent polling protocol. TeamCity coordinates build agents through communication with the central server. Agents poll the server for work, receive instructions and return build information. The protocol therefore has to process structured data supplied by clients, including information that is ultimately handled by TeamCity’s Java application.
The vulnerability results from unsafe deserialisation involving XStream, a Java library used to convert XML representations into Java objects. Deserialisation becomes dangerous when an application accepts attacker-controlled data and permits classes with side effects to be instantiated or invoked. In this case, TeamCity attempted to restrict XStream’s deserialisation behaviour through an allowlist, but the implementation did not first remove XStream’s existing default permissions. The resulting policy was less restrictive than intended.
This is an important technical detail. An allowlist is only useful if it establishes the complete set of permitted classes. Leaving broader permissions in place means that classes outside the intended TeamCity-specific policy may still be available to an attacker. The attacker can then construct an object graph that causes the application to invoke a sequence of otherwise legitimate Java components.
Rapid7’s analysis describes a gadget chain involving XStream, Apache FreeMarker, Apache DBCP and HSQLDB. The chain abuses the interaction between these components rather than relying on a single malicious class. Attacker-controlled XML is deserialised into objects, which ultimately causes a database connection to be established with attacker-controlled properties. The connection is used to write a JSP file into the TeamCity web application directory. The attacker can then request that JSP over HTTP, causing TeamCity’s Java web container to execute the resulting server-side code.
The resulting capability is remote operating-system command execution under the privileges of the TeamCity service. This makes the vulnerability substantially more serious than an authentication bypass alone. An attacker does not first have to create an administrative account, obtain a session or steal a TeamCity credential. A vulnerable server can be attacked directly.
The privileges available to the TeamCity process then become important. If the service has excessive operating-system permissions or access to sensitive files, the impact increases. The same applies to credentials stored in TeamCity projects, build configurations and integrations. JetBrains warns that exploitation can expose TeamCity data and configuration, compromise stored credentials and affect build artefacts and downstream CI/CD pipelines.
The vulnerability therefore illustrates a familiar pattern in application security: a relatively narrow flaw in input processing can become an infrastructure-level compromise when the vulnerable application has extensive access to other systems.
Why ransomware operators want a build server
TeamCity sits within a chain of systems that organisations use to produce and deploy software. A server may communicate wit