Assurance Guides9 September 20263 min read

From CI/CD to cloud takeover: lessons from TeamCity CVE-2026-63077 and the Cadence breach

A critical deserialisation flaw in TeamCity On-Premises let attackers into a vendor's own cloud service, where backups full of credentials were waiting. Build systems deserve the same assurance as domain controllers.

By the Aureon Intelligence analyst team

JetBrains published an advisory for CVE-2026-63077 on 27 July 2026. The flaw, rated CVSS 9.8, is a deserialisation of untrusted data in TeamCity On-Premises that allows an unauthenticated attacker with network access to abuse the agent polling protocol, bypass authentication and execute operating system commands with the privileges of the TeamCity server process. CISA added it to the Known Exploited Vulnerabilities catalogue on 5 August 2026.

Then the vendor's own infrastructure was hit.

What happened at Cadence

According to JetBrains' disclosure and subsequent analysis, attackers exploited the unpatched vulnerability against a TeamCity instance behind the Cadence cloud compute service between 8 and 24 August 2026. The intrusion was discovered on 23 August, the affected server was taken offline on 24 August, and the investigation concluded on 3 September.

The attackers gained initial access through api.cadence.jetbrains.com and then moved to server backups. Those backups contained credentials for further cloud resources. The data exposed included user account information (usernames, real names, email addresses, login timestamps and IP addresses), multiple AWS IAM credentials, project source code and configuration files, and secrets such as cloud credentials, authentication tokens, API keys and signing certificates, including files from S3 buckets in JetBrains' AWS accounts. On 28 August it was confirmed that the attackers had also accessed a backup from 2024.

The lesson is not about one vendor

Every organisation with a build pipeline has a version of this exposure. CI/CD systems hold the keys to everything: source code, deployment credentials, cloud roles, signing certificates and the ability to inject code into what ships to customers. They are usually managed by engineering teams, exposed to developers and agents across networks, and patched on engineering schedules rather than security ones.

Backups compound the problem. A backup of a build server is a backup of its secrets, and backups are rarely protected to the same standard as the live system.

Assurance checklist for build and deployment systems

Exposure and patching

  • Upgrade TeamCity On-Premises to 2025.11.7 or 2026.1.3, or apply the JetBrains security patch plugin for older versions. TeamCity Cloud customers are not affected.
  • Build servers should not be reachable from the internet. Agent and user access should pass through a VPN or a zero-trust gateway with MFA.
  • Treat CI/CD platforms as tier-zero assets with emergency patching rules equal to domain controllers and hypervisors.

Secrets

  • Move secrets out of build configurations and backups into a vault with short-lived, scoped credentials. Prefer workload identity federation to long-lived cloud keys.
  • Rotate every secret that has ever been stored in or reachable from a build server after any suspected compromise, and verify that old keys are revoked, not merely replaced.
  • Protect signing certificates in hardware-backed key stores with separate approval for use.

Backups

  • Encrypt backups with keys that the build server itself cannot access, store them outside the build environment and restrict restore rights.
  • Include backups in the scope of secret rotation. A backup from two years ago is still a credential store if the keys inside it were never rotated.

Detection

  • Alert on new agents registering, unexpected build steps, configuration changes outside change windows, and outbound connections from build servers to unfamiliar destinations.
  • Monitor cloud audit logs for use of credentials from unfamiliar IP addresses or regions, especially credentials associated with CI/CD roles.

For insurers and customers of software vendors

Ask vendors whether their build systems are internet-exposed, how quickly they patch critical CI/CD vulnerabilities, and whether backups containing secrets are encrypted with separate keys. The answers predict supply-chain risk better than most questionnaires.

Sources

JetBrainsTeamCityCI/CDsupply chaincloud securityKEV
This article is provided for general information and reflects public sources and the authors' professional opinion at the date of publication. Vulnerability details and recommendations change quickly; validate them against vendor advisories and your own environment before acting.
Keep reading

More insights.

All insights
Threat Landscape2 October 20264 min read

ClickFix inside ChatGPT: Malicious Custom GPTs used to deliver a remote access trojan

Attackers bought search ads for the word chatgpt, published fake Custom GPTs on the real ChatGPT domain and sent users to a counterfeit Cloudflare check that ends with a PowerShell command. The domain is no longer the signal. The instruction is.

Read article
Threat Landscape2 October 20265 min read

TerminalFix: The ClickFix lure moves to Windows Terminal and ends in a covert tunnel

Sophos links a campaign it tracks as STAC4924 to the group behind Vice Society and Rhysida. The chain hides shellcode as English words, fetches its servers from a forum profile and leaves a Python tunnel on the host. No encryption has been seen yet, which is exactly the point.

Read article
Vulnerability Alerts2 October 20265 min read

Zimbra CVE-2026-73570: What intruders did on compromised mail servers, and what to check on yours

An unauthenticated command injection in the SNMP notification path of Zimbra Collaboration was probed before public disclosure and exploited at scale afterwards. Microsoft's reconstruction shows web shells, a route to root through PAM, credential dumps and a cloud exfiltration attempt. The fix is 10.1.20. The work starts after the patch.

Read article