CVE-2026-63077: JetBrains TeamCity Deserialization of Untrusted Data Vulnerability
JetBrains TeamCity contains a deserialization of untrusted data vulnerability that could allow unauthenticated remote code execution via the agent polling protocol.
Overview
In JetBrains TeamCity before 2026.1.3, 2025.11.7 unauthenticated remote code execution was possible via the agent polling protocol
Vulnerability details
TeamCity's agent polling protocol, the channel through which build agents communicate with the server, accepts and deserializes incoming data without first authenticating the source. This is a CWE-502 (Deserialization of Untrusted Data) weakness: the application reconstructs objects from a byte stream supplied by an external party without validating that the sender is trusted. Because deserialization in many JVM-based frameworks can trigger arbitrary method execution through gadget chains present in the classpath, the absence of an authentication gate before deserialization makes the protocol endpoint directly exploitable.
An attacker with network access to the TeamCity server's agent polling protocol port can connect to that endpoint and submit a crafted serialized payload. No credentials are required. When the server deserializes the payload, attacker-controlled code executes in the TeamCity server process, yielding full confidentiality, integrity, and availability impact. The precondition is that the agent polling protocol port must be reachable from the attacker's position. TeamCity servers exposed to the internet or to untrusted network segments satisfy this condition without any further user interaction.
Severity and impact
Exploitation status
This vulnerability is confirmed as actively exploited in the wild — it is listed in CISA's Known Exploited Vulnerabilities (KEV) catalog.
Detection and monitoring
- Audit inbound connections to the TeamCity agent polling protocol port from source addresses outside the known, configured build-agent IP range. Any connection from an unrecognized host warrants investigation, as legitimate agents are a bounded, known set.
- Review TeamCity server process logs and host-level audit logs for unexpected child process creation or outbound network connections originating from the TeamCity server process, which may indicate post-exploitation activity following a successful deserialization payload execution.
- Check TeamCity server logs for deserialization errors or malformed-message exceptions on the agent communication channel. A spike in parse failures from a single source IP is a strong indicator of payload probing.
Remediation
Additional hardening
- Restrict network access to the TeamCity agent polling protocol port using host-based firewall rules or network ACLs, permitting only known build-agent IP addresses and blocking all other sources.
- Place the TeamCity server behind a network segment boundary so the agent polling port is not reachable from untrusted networks or the public internet, regardless of patch status.
- Audit and reduce the Java classpath available to the TeamCity server process to limit the gadget chains available for deserialization exploitation as a defense-in-depth measure.
- If patching is not immediately possible, consider taking the TeamCity server offline or disabling agent connectivity until the fixed version is deployed, given the critical severity and active KEV listing.
Key dates
References
Frequently asked questions
Does CVE-2026-63077 affect my FedRAMP authorization?
If JetBrains TeamCity runs inside your authorization boundary, CVE-2026-63077 affects your FedRAMP authorization directly. The vulnerability appears in CISA's Known Exploited Vulnerabilities (KEV) catalog with a remediation deadline of August 8, 2026. An unpatched KEV within your boundary is an assessor finding — one you must either remediate or formally document a mitigation for before your assessor or sponsoring agency raises it first.
How does Knox help me handle CVE-2026-63077?
Remediating JetBrains TeamCity is your responsibility under the FedRAMP shared-responsibility model — Knox does not patch your software. What Knox provides is the pre-authorized, single-tenant boundary to remediate within, plus continuous compliance monitoring and audit-artifact coverage to document the fix for your next assessment. The work of applying the patch is yours; maintaining a defensible compliance posture while you do it is not something you manage alone.
How does Knox's monitoring help with vulnerabilities like this?
Knox's automated continuous monitoring platform watches your environment for newly disclosed vulnerabilities and compliance issues on an ongoing basis. For a vulnerability like CVE-2026-63077, that means exposure surfaces during continuous monitoring rather than only when an assessor flags it at review time, giving you more time to act before it becomes a formal finding.
How do I get FedRAMP authorized with Knox?
Book a meeting and Knox maps your path to authorization: FedRAMP in 90 days for 90% less, without the delays or dependencies of the traditional process.
What happens if CVE-2026-63077 isn't remediated by August 8, 2026?
Missing the August 8, 2026 deadline turns CVE-2026-63077 into a Plan of Action and Milestones (POA&M) item. A growing POA&M list is what converts a routine continuous-monitoring review into a difficult conversation with your sponsoring agency. Meeting the deadline keeps your authorization clean and the agency relationship on solid ground.
Ready to achieve FedRAMP authorization in 90 days or less?
Schedule a meeting to discuss scope, parse readiness, and map your company’s accelerated path to FedRAMP authorization.
_Horizontal_RGB.png)
