Fifteen Days on the Build Server: What JetBrains Missed Inside Its Own CI Pipeline

JetBrains published the advisory for CVE-2026-63077 on July 27, 2026. CISA added it to the Known Exploited Vulnerabilities catalog on August 5, with a federal patching deadline of August 8. On that same August 8, according to JetBrains' own incident write-up, attackers began operating inside Cadence, JetBrains' cloud compute service for PyCharm. The company found them on August 23 and pulled the server offline on August 24.

Fifteen days. On a build server. At a company that makes build servers.

I want to be careful here, because the easy read is a dunk on JetBrains and that read is useless to you. The company published a clear, updating incident page and told customers exactly what to rotate, which is more than most vendors manage. The interesting question is not why one server slipped through a patch campaign. Servers always slip through patch campaigns. The interesting question is why nobody noticed anything for two weeks on a machine that holds cloud credentials, source code, and signing keys for an entire product line.

What the vulnerability actually does

Rapid7's analysis of CVE-2026-63077 is worth reading in full, but the shape of the bug is simple and slightly depressing. TeamCity build agents talk to the central server over an agent polling protocol. That protocol deserializes data from agents that have not authenticated yet, so TeamCity restricts which Java classes XStream is allowed to instantiate. The fix that created the bug: the allowlist added TeamCity's own protocol classes on top of XStream's existing default permissions instead of replacing them. The result is a permissive allowlist. An unauthenticated attacker who can reach the server over HTTP gets command execution as the TeamCity service account. CVSS 9.8, no credentials, no user interaction, low complexity.

Patched versions are 2025.11.7 and 2026.1.3. If you run TeamCity and you are reading this in September, that part of the job is not complicated.

The part that is complicated is what running as the TeamCity service account means. It means you are standing inside the machine that, by design, has been handed every secret your engineering organization needs to ship software. That is not a misconfiguration. That is the purpose of a CI server.

Read the rotation list, not the breach summary

The most instructive artifact from this incident is not the timeline. It is the list JetBrains gave affected customers of what to rotate:

AWS, Azure and Google Cloud credentials. GitHub, GitLab and Bitbucket tokens. npm, Maven, NuGet and PyPI repository credentials. Docker Hub, ECR, GCR and ACR registry credentials. Slack tokens. Webhooks. API tokens. SSH and deployment keys. Service account credentials. Signing keys and certificates.

Go through that list and ask, for each entry, what a stolen copy buys an attacker. Cloud credentials buy infrastructure. Source control tokens buy the ability to commit. Package repository credentials buy the ability to publish a version of your library to everyone who depends on it. Signing keys buy trust. That last one is the reason this class of incident keeps producing supply chain events downstream: we saw exactly that mechanism play out when a maintainer's publish credential became the entry point in the Axios npm compromise that reached 100 million downloads.

JetBrains confirmed the attackers took usernames, real names, email addresses, last-login timestamps, last accessed IP addresses, and multiple AWS IAM credentials. They reached files in S3 buckets inside JetBrains AWS accounts. They got source code that PyCharm users had synced to the affected server. And they got a 2024 Cadence server backup that contained credentials and configuration data, which is its own quiet lesson: a backup from two years ago is a snapshot of every secret that existed two years ago, and GitGuardian found that 64% of the secrets that were valid in 2022 are still valid today. Old backups are not cold storage. They are warm credential archives.

The blind spot is structural, not accidental

Here is the argument I actually want to make, and it is not about TeamCity.

Your detection coverage was built around endpoints and identity providers. EDR on laptops and servers, SIEM ingesting authentication logs, maybe some cloud posture tooling. Now think about what a CI runner looks like through that lens. It executes arbitrary code as a design requirement. It pulls containers from the internet. It writes and deletes files constantly. It makes outbound network calls to package registries, cloud APIs, artifact stores. It authenticates to a dozen services per build using long-lived tokens.

Every behavioral signature you would normally use to catch an intruder is, on a build runner, the job description. The baseline is the attack. That is why the detection ideas that work everywhere else quietly fail here, and it is a sharper version of the coverage gap I wrote about when CrowdStrike measured a 27 second breakout time: the clock does not matter if the sensor was never pointed at the room.

GitGuardian's State of Secrets Sprawl 2026 put a number on how much this matters. Analyzing the Shai-Hulud 2 supply chain attack across 6,943 systems, they found 294,842 secret occurrences mapping to 33,185 unique secrets. And 59% of the compromised machines were CI/CD runners, not developer laptops. The same report counted 28.65 million hardcoded secrets pushed to public GitHub in 2025, up 34% year over year, and found that 32.2% of internal repositories contain at least one hardcoded secret versus 5.6% of public ones. Teams are careful in public and careless in private, and the build system consumes the private repositories.

So the credentials concentrate in the one place your telemetry does not reach. That is the whole problem in one sentence.

Cadence was not an isolated week

Four days after JetBrains took the Cadence server down, JFrog disclosed and patched CVE-2026-82329, a critical improper authentication flaw in Artifactory. Same CVSS 9.8, same profile: unauthenticated network access to administrative privileges under default configuration. By September 1, watchTowr had observed attackers exploiting it in the wild to mint administrator tokens, then using those tokens to enumerate users, groups, credentials and federated access relationships. In a smaller number of cases the attackers created backdoor users for persistent admin access. CISA added it to KEV on September 2.

Look at what the Artifactory attackers did with admin. They did not immediately steal artifacts. They enumerated. They mapped who has access to what, and which federated trust relationships lead outward, and then decided whether the environment was worth more effort. That is reconnaissance behavior, and it is the single most detectable phase of any intrusion, because reconnaissance means touching things you have no legitimate reason to touch.

Two 9.8s in one week, both landing on the artifact and build layer, both ending in an attacker holding admin over the credential store. The pattern here is the same one behind the N-central RMM compromise Storm-1175 rode into MSP networks: compromise the system that has legitimate reach into everything, and you inherit its reach.

What a canary in a build runner looks like

This is where deception stops being a philosophy and becomes an engineering choice, so let me be concrete about the mechanics rather than gesture at them.

A CI runner is close to the ideal place to plant a decoy credential, for a reason that has nothing to do with cleverness: the legitimate consumers of that environment are all machines, and machines are deterministic. Your build scripts touch exactly the variables they were written to touch. Nothing in a normal pipeline reads the whole environment, enumerates every key in the credential file, or calls sts:GetCallerIdentity against an IAM key it has never used. Humans browse. Pipelines execute.

So you place an AWS IAM key that grants nothing, in the same file, with the same naming convention as the real ones. AWS_ACCESS_KEY_ID_DEPLOY_LEGACY sitting next to the key your pipeline actually uses. No build job references it. It has no permissions attached. Its only job is to be indistinguishable from the real thing at read time. The moment anyone anywhere on earth attempts to authenticate with it, you know two things with certainty: someone enumerated the credential store on that runner, and it was not your pipeline. That is what Cloud Mines are built to do, and it is why the alert has no false positive story to argue about. There is no benign path to that event.

The same logic applies to the artifact side. A decoy repository in Artifactory that no build ever pulls from. A fake service account in the user directory that appears in exactly the enumeration call an attacker makes after minting an admin token. If the Artifactory attackers watchTowr observed had enumerated an environment seeded that way, their very first reconnaissance action would have been the alert.

One edge case worth knowing, because I have watched teams get this wrong. Do not put your decoy credential in a build environment where a secrets scanner also runs. Scanners like TruffleHog and GitGuardian's own agent will find the key, attempt validation against the provider, and fire the honeytoken. You will spend an afternoon chasing an alert generated by your own tooling. Either exclude the decoy path from the scanner's scope or place the decoy at a layer the scanner does not walk. Test this before you turn on paging. The same principle covers vulnerability scanners hitting decoy services, which is why MineField decoys get tuned against your existing scanner inventory rather than dropped in blind.

And be honest about the ordering. A canary in the CI runner would not have stopped CVE-2026-63077. Patching stops CVE-2026-63077. What a canary changes is the fifteen days. The gap between the exploit landing and somebody knowing, which in this incident was the entire incident. Automated credential harvesting has made that gap the whole game, as the Zerofot scanner's 2,975 keys in 48 days demonstrated at industrial scale.

The uncomfortable version

JetBrains told the world to patch this bug and then did not patch one of its own servers. That is not incompetence, it is what asset inventory looks like at scale in any organization above a certain size, and pretending otherwise is how security teams end up planning for a world they do not live in. Some server is always missed. Some credential is always older than the policy. The 2024 backup is always still sitting there.

Which means your security model cannot rest entirely on the assumption that patching completes. It has to include a layer that assumes the intruder is already inside the build system and asks what they will touch first. In almost every case, the answer is: the credentials. They are the reason to be there at all.

If you run TeamCity, Artifactory, Jenkins or GitHub Actions runners and you cannot say today what would alert if an attacker read the secrets on them, book a working session with our team and we will help you plant the first decoy credential in that pipeline and prove out the alert path before you trust it.