Is CVE-2026-63077 (JetBrains TeamCity Deserialization of Untrusted Data) being exploited in the wild?

Yes. CISA added CVE-2026-63077 to its Known Exploited Vulnerabilities catalogue on 5 August 2026, which it does only when there is reliable evidence of active exploitation. CISA lists it as known to be used in ransomware campaigns. JetBrains TeamCity contains a deserialization of untrusted data vulnerability that could allow unauthenticated remote code execution via the agent polling protocol.

What the exploitation status means for TeamCity operators

For a TeamCity deployment, “exploited in the wild” means this is no longer a theoretical deserialization weakness to track for later. It is an active exposure that can be used for unauthenticated remote code execution through the agent polling protocol, so confirmation of exposure should move straight to containment, patching, and compromise review rather than routine ticketing.

Because TeamCity is part of build and delivery infrastructure, the practical question is not only whether the server is reachable, but whether it can execute attacker-controlled code before you finish remediation. That makes the vulnerable instance, its agents, and any credentials or tokens reachable from the server part of the same response scope.

How to confirm whether you are affected

Start by inventorying every TeamCity server, including forgotten test instances, mirrored environments, and internet-exposed admin consoles. If a server is exposed to untrusted networks, assume the opportunity for exploitation is materially higher and prioritise it first.

Then verify whether the relevant JetBrains advisory and the CISA Known Exploited Vulnerabilities Catalog list matches your installed TeamCity version and deployment path. For version details and fix guidance, rely on the vendor advisory rather than trying to infer safety from general patch level or from the absence of obvious errors in logs.

What to do if patching is delayed

If you cannot patch immediately, reduce reachability first. Restrict access to the TeamCity web and agent-facing interfaces, remove public exposure, and segment the system so that compromise of the server does not automatically open access to source code, signing material, secrets stores, or deployment targets.

Where compensating controls are all you have for the moment, treat them as temporary risk reduction rather than a substitute for remediation. For this class of flaw, filtering traffic alone is weaker than removing exposure, because unauthenticated remote code execution can bypass the trust assumptions baked into the application itself.

Risk and Threat Considerations

This vulnerability matters because a build server often sits near high-value assets, such as source repositories, deployment credentials, signing keys, and privileged automation paths. If an attacker gains code execution on TeamCity, the next step is commonly lateral movement into the software supply chain or theft of material that unlocks further access.

Failure mechanism: deserialization of untrusted data lets attacker-controlled input be interpreted as executable object state, which can trigger code execution before normal authentication or authorization controls can stop it.

Impact: A successful exploit can lead to full server compromise, credential theft, tampering with build outputs, persistence inside CI/CD, and downstream compromise of systems that trust the pipeline.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
MITRE ATT&CK	T1203 — Exploitation for Client Execution	CVE exploitation via untrusted deserialization is an execution path on the target.
Recommendation — Map the exploit path to T1203 and hunt for attacker-controlled execution on TeamCity hosts.
NIST CSF 2.0	PR.DS-01 — Data-at-rest protection	Build servers often store sensitive build artifacts, secrets, and signing material.
	PR.AA-05 — Identity management, authentication, and access control	TeamCity compromise can expose privileged access paths and credentials.
Recommendation — Protect build artifacts and sensitive pipeline data with strong storage controls. Tighten access control around TeamCity and rotate exposed credentials promptly.
CIS Controls v8	CIS-5 — Account Management	Exploitation can expose or enable misuse of privileged accounts and service access.
Recommendation — Review and disable unnecessary accounts that can reach TeamCity or its agents.
OWASP ASVS	V16 — Security Logging and Error Handling	Compromise assessment depends on logs that show exploit attempts and post-exploitation activity.
Recommendation — Retain and review logs needed to detect exploitation and follow-on actions.

Practitioner Guidance

What to verify: Confirm whether the TeamCity server has been reachable from untrusted networks since the exposure window, and check whether any agent polling or administrative activity coincides with unusual process creation, web requests, or new accounts.

Evidence to retain: Preserve server logs, agent logs, authentication records, and any records of new files, tasks, or configuration changes before rotating access material. If the server was reachable, assume you may need to investigate for pre-remediation compromise even when no obvious alert fired.

Decision rule: If the instance handled sensitive builds, signing operations, or deployment credentials, treat the response as a potential supply-chain compromise, not just a server patch. Credential and key rotation can be necessary when the exploit path may have exposed them.

Practitioner takeaway: When a build system vulnerability is already being exploited, the key decision is not whether the issue is “critical” in abstract terms, but whether the server’s trust relationships mean a single foothold can contaminate everything downstream.