Attackers exploited JetBrains' own TeamCity bug to operate inside Cadence for 16 days

Read the remediation list as an asset inventory. JetBrains tells Cadence users to revoke and rotate every credential and secret that may have been used to run executions ^[10], then to go looking for suspicious activity in AWS accounts, S3 buckets, deployment environments, and package or container registries reachable with those credentials ^[11]. Then repositories, for unauthorized changes during the affected window, and any project files synced to Cadence from PyCharm, for secrets embedded in them ^[12]. That is not generic hygiene advice. It is a written-down list of what a build orchestrator holds keys to, produced by people who have just watched someone else hold them.

The instruction that turns this from patching into incident response is the last one: treat all executions, including their inputs and outputs, as potentially untrusted ^[13]. A patched server tells you nothing about what a binary built on the unpatched one contains.

Fifteen days passed between the earliest activity JetBrains has identified and the day it found the exploitation ^[20]. One more day to take the server off the network ^[22]. Treat that 15 as a measurement of JetBrains' detection on infrastructure it owns and instruments, not as a figure that transfers. For it to mean anything in your environment, you would need retained authentication logs on the TeamCity server itself, plus logs on every downstream service that server could authenticate to, covering the whole window. Self-hosted CI tends to ship build logs somewhere durable and let server access logs roll at whatever the distro default is. If yours rolls at seven days, the affected period closed before your evidence begins ^[7].

Two sentences in the advisory do the same work from opposite ends. Cadence users can request an inventory of the credentials and secrets associated with their usage, and JetBrains says that inventory should not be considered exhaustive ^[14]. Separately, it says the published indicators are not exhaustive and that their absence does not confirm a system was unaffected ^[16]. Neither artifact lets you narrow scope. Scope is whatever your server could authenticate as, which is why the rotation list is longer than the compromise you can prove.

Order matters, and it runs against instinct. The vulnerability allows an unauthenticated attacker to execute arbitrary commands on a vulnerable server ^[4]. Rotate before you patch and the new secrets land on a machine that still accepts unauthenticated commands, so you have paid the rotation cost twice and bought nothing. Network isolation or patch first, then rotate, then review connected systems with the indicator categories JetBrains published ^[17], which are worth reading as a checklist of the places CI credentials get spent: new service accounts in external services, changed IAM policies, modified access tokens, unexpected package publication.

The vendor that ships TeamCity was running a Cadence environment that the fix for its own critical CVE had not reached ^[5]. The queue for maintenance windows is apparently no shorter inside the building.

One caveat on reading this at all: the investigation is ongoing and the post is being revised as it progresses, with the version I have timestamped August 28 at 11:50 CEST ^[19]. The confirmed facts include extraction of personal data from the affected environment ^[9]. The affected period may not be final.