Attackers Breached JetBrains Cadence via Unpatched TeamCity: What SMBs Must Do Now

Attackers breached JetBrains Cadence by exploiting an unpatched critical vulnerability in TeamCity and walked away with AWS credentials.

If your development pipeline touches TeamCity or any CI/CD tooling, this incident is a direct signal that unpatched build infrastructure is now a primary entry point for credential theft.

JetBrains confirmed that unidentified threat actors exploited a recently disclosed critical vulnerability in TeamCity to breach the company’s own environment, specifically its Cadence product. The attackers did not stop at access. They extracted AWS credentials that had been used during Cadence executions.

JetBrains responded by urging all Cadence users to immediately revoke or rotate all credentials and secrets that may have been used to run their Cadence executions. That instruction applies whether or not a given user has seen direct evidence of compromise.

The attack path here is one that repeats across the industry. A critical vulnerability is disclosed in a widely used development tool. A patch becomes available. Before organizations apply it, attackers move. JetBrains, a company that builds and maintains the affected software, was itself caught in that window.

For SMB owners and IT managers, the lesson is not that JetBrains failed in some unusual way. Build tools, CI/CD pipelines, and automation platforms sit close to source code and deployment secrets. Patch lag inside development infrastructure carries the same risk as patch lag on public facing servers, and attackers know this.

AWS credentials extracted from a CI/CD environment can be used to access cloud storage, spin up compute resources, exfiltrate data, or establish persistence inside a cloud account. The damage from a single set of leaked cloud credentials can extend well beyond the development environment where they originated.

TeamCity is a popular CI/CD platform used by software development teams of all sizes. Many SMBs running software products or managing internal development workflows will have it deployed, either on premises or through a managed instance. If your team uses TeamCity and has not yet applied the patch for the recently disclosed critical vulnerability, that action needs to happen today.

Patching quickly is necessary, but the JetBrains advisory makes an additional point worth taking seriously. Cadence users should rotate credentials regardless of whether they believe they were in the exposure window, because the scope of who may have been affected is not always clear from the outside. Revocation and rotation is the safe default.

Credential hygiene in CI/CD pipelines is an area many SMB IT teams under invest in. Secrets often get embedded in configuration files, environment variables, or pipeline definitions without a structured rotation policy. This incident creates a concrete reason to audit where AWS keys, API tokens, and other secrets are stored across your build and deployment systems.

Secrets management tools exist specifically to reduce this risk. Platforms like HashiCorp Vault, AWS Secrets Manager, or comparable solutions are designed to keep credentials out of pipeline configuration files and enforce automated rotation. Passing credentials manually through build definitions is a practice that needs to change.

Patch management for developer tooling often falls into a gray zone inside SMBs. Security teams patch servers and endpoints. Developers manage their own build tools. That split responsibility creates gaps. Someone needs to own the patching lifecycle for TeamCity, GitHub Actions runners, Jenkins instances, and similar platforms with the same rigor applied to anything else on the network.

The broader pattern is worth naming directly. Attackers are moving up the software supply chain. Source code repositories, build systems, and deployment pipelines are targets because compromising them can yield access to multiple downstream environments at once. A single set of extracted cloud credentials from one CI/CD breach can open doors into production systems, customer data, and third party integrations.

IT managers should use this incident as a prompt to run a short internal audit. Inventory every CI/CD and build automation tool in use across the organization. Check that each is running a current, patched version. Identify every credential or secret stored in or passed through those systems, and determine who holds administrative access and whether that access is reviewed regularly.

For organizations using JetBrains Cadence, the action is not optional. Follow the company’s guidance and revoke or rotate all credentials and secrets associated with Cadence executions. Document what you rotated and when, so you have a clear record if anomalous activity surfaces in your cloud environment later.

Vendors disclosing breaches that affect their own customers reflects a more transparent posture from software companies operating under heightened regulatory and customer scrutiny. Taking that transparency at face value and acting on the guidance is the appropriate response. Waiting to see if the issue affects you directly is not a sound risk posture when credentials are involved.

TeckPath Perspective: When attackers can breach the vendor who builds the tool you rely on, the only reliable defense is treating every credential touched by that tool as compromised and rebuilding your secrets posture from there.

Patch windows are not a planning problem, they are a security event, and CI/CD infrastructure deserves the same urgency as any public facing system on your network.