Vulnerability ManagementAI SecurityIncident Response
Every organisation has a list of its third-party dependencies. It is maintained by procurement, or by a GRC platform, or by whoever last filled in the vendor risk spreadsheet. It contains the SaaS products someone signed a contract for.
It does not contain the cloud GPU service a machine learning engineer switched on from a checkbox inside their IDE, because nobody signed anything. That is the surface this week's disclosure lands on.
On September 3, 2026, JetBrains concluded its investigation into a breach of Cadence, its hosted cloud compute service, and the conclusion was worse than the initial notice on August 28. The Hacker News reported the expanded findings on September 5. Attackers held api.cadence.jetbrains.com from August 8 to August 24, and left with AWS IAM credentials, S3 objects from JetBrains' own AWS accounts, a full 2024 server backup, and customer project source code that had been synchronised to the service.
The way in was CVE-2026-63077 — a critical flaw in JetBrains TeamCity, patched by JetBrains, on a JetBrains server JetBrains had not patched.
Read the dates in order, because they are not ambiguous.
July 28, 2026 — JetBrains publishes the advisory for CVE-2026-63077, an authentication bypass in the TeamCity agent polling protocol carrying a CVSS of 9.8. Any attacker who can reach the server over HTTP runs OS commands as the server process, with no credentials. It was reported privately by Antoni Tremblay and affects TeamCity On-Premises across the board; the fixes are 2025.11.7 and 2026.1.3. JetBrains states at publication that it is not aware of active exploitation.
August 5, 2026 — CISA adds the CVE to the Known Exploited Vulnerabilities catalog, with a federal remediation deadline of August 8 — a three-day window, which CISA does not hand out casually.
August 8, 2026 — the earliest confirmed attacker activity inside Cadence. The intrusion begins on the day the federal deadline expires, eleven days after the vendor shipped its own fix.
August 23 — JetBrains detects it. August 24 — the server goes offline. August 28 — first public notice. September 3 — the investigation closes, having found more than the first notice described.
Fifteen days of dwell time on a build orchestrator holding customer workloads, in a window that opened after the patch existed, after the exploitation was public, and after a national authority had put a three-day clock on it.
Rapid7's write-up of the CVE spelled out the consequence in advance, quoting the vendor's own advisory: successful exploitation lets an attacker "read stored credentials" and "compromise CI/CD pipeline integrity." That is exactly what happened, to the company that wrote the sentence.
The patching failure is embarrassing but it is not the interesting part. Unpatched servers are a solved problem in the sense that everyone knows what the answer is. The interesting part is what was running on this one.
Cadence is a JetBrains-hosted service that lets a developer run projects on cloud compute resources — GPU-backed machine learning and heavy workloads — dispatched directly from PyCharm through an optional plugin. Your code is synchronised up, the job executes on JetBrains' infrastructure inside JetBrains' AWS accounts, and results come back into the IDE. TeamCity is what orchestrates the workloads, which is why a TeamCity flaw was a Cadence breach.
So the adoption path for this dependency was: a developer installs a plugin and signs in. No contract. No architecture review. No entry in the vendor register. No DPIA. And from that moment, a third party's compute environment is holding project source code and executing training and inference jobs on it, with whatever cloud credentials the developer configured for the run.
This is not a criticism of the product. It is a description of how essentially all AI compute gets adopted now. The friction that used to force a procurement conversation — provisioning hardware, signing an MSA, filing a budget request — has been compressed into an OAuth flow inside an editor. Every organisation with a data science function has some number of these relationships. Very few can produce the number.
JetBrains' remediation guidance is unusually direct, and one line in it is doing far more work than the rest. Alongside the expected advice — revoke and rotate every credential used for Cadence executions, review connected AWS accounts, repositories and registries, audit repos for unauthorised changes — the incident notice tells customers to:
Treat all executions, including their inputs and outputs in your Cadence project, as potentially untrusted.
Sit with that. It is not a confidentiality statement, it is an integrity statement. It says the artefacts that came back from those runs — model outputs, trained weights, evaluation results, generated code, whatever the job produced — may have been influenced by someone who controlled the execution environment for sixteen days. Anything downstream of them inherits the doubt.
Answering it requires knowing three things: which projects used Cadence, which executions ran between August 8 and 24, and where each of those outputs ended up. A team that ran one fine-tuning job whose weights are now serving production traffic has a very different morning from a team that ran a notebook and threw the result away. Both look identical from the outside.
For most organisations the honest position is not "we were unaffected." It is "we do not know whether anyone here used this." Credentials can be rotated blind — painful, but mechanical. Provenance cannot. You cannot rotate an artefact whose existence you never recorded.
That is a different failure from the one in this week's KEV additions, where the target was the API keys sitting in AI infrastructure. Here the credentials are the recoverable part. What does not recover is the chain of custody on the outputs.
Three of the stories we have covered this week share a shape, and it is not the one the AI security discourse expects.
GitSpawn executed attacker code through git, before an agent's model was involved at all. The ted backdoor was compiled into a victim's own load balancer and edited the counters its monitoring read. And now a cloud ML compute service falls to a deserialisation bug in a build server.
None of these are model failures. None of them would be caught by a better system prompt, a stricter guardrail, or a more capable evaluation harness. They are the ordinary software around the AI — the plugins, the orchestrators, the proxies, the registries — being adopted at the speed of AI enthusiasm and secured at the speed of whatever process the organisation had before any of it existed.
The industry has spent two years building controls for what the model says. The attacks keep arriving through what the model runs on.
The control that would have mattered here is not a guardrail. It is an answer to the question what AI compute and services does this organisation actually talk to, under whose name, and what left the building — asked before an incident notice forces it.
Obiguard Governance AI is built around that question rather than around model behaviour.
Registration turns an unknown into a queryable object. AI Use Cases and Agents are registered entities with a named owner, a linked business function, a policy set and a credential. That is deliberately administrative and it is the part that fails first in real deployments — but it is what converts "did anyone here use Cadence?" from an all-hands Slack thread into a lookup. Governance follows the workload, not the calendar.
Allow-lists make external AI compute an explicit permission rather than a plugin install. The domain allow-list governs which external endpoints an agent or workload may reach through retrieval and tooling, path-level, with any call to an unregistered destination blocked before the request leaves and written to the ledger with full context. The model and tool allow-lists do the same for model IDs and tool invocations, and the user allow-list binds who may invoke a given agent at all. It is a positive-permission model: if it is not on the list, it does not run. An unreviewed third party receiving source code is exactly the case that design exists for.
The Audit Ledger is what you read on the day the notice arrives. Every prompt, response, tool-call and policy decision is written to an append-only record with the model, the agent, the initiating identity and a timestamp, exportable to CSV for your GRC stack and streamable to Splunk, Sumo Logic, Datadog or S3. Given a compromise window of August 8 to August 24, the ledger is the difference between naming the affected runs in an afternoon and telling your regulator that you are unable to determine scope.
The Violations view and Review Queue give the finding somewhere to go. A blocked call to an unregistered endpoint is not useful sitting in a log nobody reads; it becomes a queue item with an assignee, an annotation and a resolution, with the trail from original event to decision preserved. That is also how a legitimate new AI service gets adopted properly — flagged, reviewed, approved and registered — rather than adopted by whoever installed the plugin first.
The boundary is worth stating plainly, as always: nothing in the Obiguard platform would have patched JetBrains' TeamCity server, and nothing in it prevents a developer from installing an IDE plugin. That patch was the vendor's job and they have said so. What governance changes is your side of the relationship — whether the service was known, whether it was permitted to receive what it received, and whether you can enumerate the runs when someone asks.
The comforting reading is that this was one missed patch at one vendor, and that vendors get breached.
The uncomfortable reading is in the adoption path. Nobody in any affected customer organisation made a decision to send source code to a third-party compute environment. They made a decision to try a plugin, and the rest followed silently — no contract to review, no register entry to maintain, no annual questionnaire, no line item anyone would notice.
That is now the default way AI capability enters a company. The dependency graph of the modern AI estate is not drawn in procurement; it is drawn one developer sign-in at a time, and it is invisible until an incident notice arrives asking you to identify which of your runs happened during a sixteen-day window in August.
JetBrains did the responsible thing here. They found it, disclosed it, expanded the disclosure when the investigation found more, and told customers exactly what to distrust. The instruction is clear and correct.
The problem is that clarity from the vendor is only useful to a customer who kept a record. Most did not.
Explore Obiguard Governance AI or talk to us about which external AI services your organisation is sending code and data to right now — and whether you could produce the list before someone else's incident report asks you for it.
Obiguard sits in front of every AI request your organization makes — screening prompts and outputs against the guardrails, compliance frameworks, and audit trails that stories like this one make necessary.
See how it works →