The TeamCity entry did not change on Wednesday. One field did, and it is the one your tooling drops
CVE-2026-63077 entered the exploited catalogue on 5 August with a three day deadline. On 23 September CISA flipped knownRansomwareCampaignUse from Unknown to Known, and nothing else about the record moved.
By Parminder Kumar Sharma · · 6 min read
Seven weeks old, and newly a ransomware entry point
CVE-2026-63077 is a deserialisation flaw in JetBrains TeamCity, scored 9.8, which lets an unauthenticated attacker reach remote code execution through the agent polling protocol. JetBrains patched it on 25 July in TeamCity On-Premises 2025.11.7 and 2026.1.3. CISA put it in the Known Exploited Vulnerabilities catalogue on 5 August, eleven days later, with a due date of 8 August.
On 23 September, CISA changed the record. Not the description, not the deadline, not the required action. One field: knownRansomwareCampaignUse, from Unknown to Known.
That is the entire event. A flaw that has been catalogued for seven weeks is now marked as used in ransomware campaigns, and the only visible evidence is a single value in a JSON file that most vulnerability management tooling ingests and never shows anybody.
What that does not establish. It does not establish which ransomware group, because CISA does not say and has published no accompanying detail. It does not establish when the ransomware use began, only when the catalogue reflected it. It does not establish new technical risk: the flaw is exactly as exploitable as it was in July. And it does not establish that anybody was compromised through an unpatched server, because no victim count exists.
What it does establish is that the catalogue carries a field that changes the meaning of an entry without changing the entry, and that the change arrives silently. If your process pulled this record in August, filed it, and patched, you are fine. If you pulled it in August, deferred it, and have not looked since, your risk profile changed on Wednesday and nothing told you.
What actually changed
The catalogue record for CVE-2026-63077, as fetched on 25 September 2026
| Field | Value |
|---|---|
| vendorProject and product | JetBrains, TeamCity |
| vulnerabilityName | JetBrains TeamCity Deserialization of Untrusted Data Vulnerability |
| shortDescription | Unauthenticated remote code execution via the agent polling protocol |
| cwes | CWE-502 |
| dateAdded | 5 August 2026 |
| dueDate | 8 August 2026, three days |
| forensicTriage | Yes |
| knownRansomwareCampaignUse | Known, changed from Unknown on 23 September |
Look at the two date fields. They still say August, because they describe when the entry was created and when federal agencies had to act. There is no field recording when the ransomware flag was set, which means the change is invisible in the record itself. You can only see it by comparing today's catalogue with a copy you kept.
That is a reasonable design choice for a catalogue whose purpose is a deadline. It is a poor one for anybody using the catalogue as an intelligence feed, which is most of the people consuming it.
Who is left
Shadowserver, which scans the internet daily and publishes counts, tracked roughly 700 exposed TeamCity servers vulnerable to this flaw shortly after the patch. It now tracks a little over 160.
That is about 77 per cent remediated in two months, which is a good number by the standards of any internet facing product. It also means about 160 organisations are running an unpatched, internet reachable build server with a 9.8 unauthenticated code execution flaw that is now confirmed in ransomware use.
And a build server is not an ordinary machine. It holds the credentials that reach your source control, your artefact registry and frequently your production deployment path. It signs things. Downstream systems trust what comes out of it precisely because it is the thing that builds them. Ransomware on a laptop is an incident. Ransomware on the machine that produces your releases is an incident plus a supply chain question you will be answering in public.
What to do about it
Take this with you
In the order worth doing
- Confirm every TeamCity On-Premises instance you run is at 2025.11.7, 2026.1.3 or later, including the instance a team stood up for one project and never decommissioned.
- Check whether any of them is reachable from the internet, and stop that being true regardless of patch level.
- If any server was exposed and unpatched after 25 July, treat it as a forensic question rather than a patching one: look at build history, artefact hashes and credential use.
- Rotate every credential the server holds, including source control tokens, registry credentials and deployment keys, because that is what an attacker goes for first.
- Then fix the general problem: make your vulnerability tooling store and display the ransomware flag from the catalogue, and alert when it changes on an entry you have already triaged.
- Keep a dated copy of the catalogue. It is a small file, and it is the only way to see what changed in an entry you already acted on.
- Add build servers to whatever list you keep of systems that get patched before everything else, if they are not on it already.
The question this leaves
Vulnerability management is built around the assumption that a record is a fact you read once. You pull the advisory, you score it, you queue it, you close it. The record sits still while you work.
These records do not sit still. A severity gets revised, as it did for the SharePoint flaw catalogued this week. A ransomware flag gets set, as it did here. An entry's description turns out to describe a different flaw entirely, as this site reported yesterday. In each case the thing that changed was not the vulnerability but the description of it, and in each case the change arrived without an announcement.
So the question is about your own pipeline rather than about TeamCity: when a record you triaged six weeks ago changes its mind, how does anybody on your team find out?
Sources
- PrimaryThe catalogue record for CVE-2026-63077, used for every field quoted hereCISAaccessed 2026-09-25
- PrimaryThe vendor advisory linked from the catalogue record, used for the fixed versions and the patch dateJetBrainsaccessed 2026-09-25
- Reported byExposure counts for unpatched TeamCity servers, reported through its daily scanningThe Shadowserver Foundationaccessed 2026-09-25
