Attackers Are Actively Exploiting a Critical JetBrains TeamCity Flaw Rated 9.8 Out of 10

A critical unauthenticated remote-code-execution vulnerability in JetBrains TeamCity On-Premises is under active attack, with the US Cybersecurity and Infrastructure Security Agency confirming exploitation and ordering federal civilian agencies to patch within three days.

What is CVE-2026-63077 and why does it matter?

CVE-2026-63077 is a deserialization flaw rated 9.8 out of 10 on the Common Vulnerability Scoring System, placing it firmly in the critical tier. An attacker with no credentials at all can send a crafted HTTP request to an exposed TeamCity server and gain the ability to execute arbitrary operating-system commands.

TeamCity is the build-and-test automation platform that turns a developer's committed code into a shippable product. It sits deep inside corporate networks, typically with broad access to source code repositories, signing keys, deployment credentials, and pipeline secrets. Compromising it is not just one server falling over. It is a potential foothold into every project and every environment that pipeline touches.

How does the attack work?

The vulnerability works by tricking the TeamCity server into deserializing malicious data, treating attacker-supplied input as a trusted internal instruction. No login prompt appears. No user interaction is required. The attacker sends the request and the server processes it with whatever privileges the TeamCity process holds, which in many default deployments are substantial.

From that position an attacker can install tools, harvest stored credentials, pivot to connected systems, or quietly maintain persistence while normal development work continues around them.

What is the current exploitation status?

At the time JetBrains published the fix, the company reported no confirmed cases of active exploitation. That changed within roughly a week of public disclosure, a timeline that has become depressingly familiar to incident responders.

CISA added CVE-2026-63077 to its Known Exploited Vulnerabilities catalog shortly after attacks were confirmed. Inclusion in that catalog carries real weight: it signals that CISA has verified real-world abuse, not just theoretical risk. Under Binding Operational Directive 22-01, federal civilian executive branch agencies must remediate KEV-listed flaws within the deadlines CISA sets. For this flaw that window is three days.

What should IT and security teams do right now?

Update TeamCity On-Premises to version 2025.11.7 or 2026.1.3 immediately. Both versions include the complete fix. Organisations running installations dating back to version 2017.1 can apply the standalone security patch plugin that JetBrains released alongside the main update if a full upgrade cannot be completed right away.

Where patching is not immediately possible, restrict network access to the TeamCity server at the firewall or network-segmentation layer. Only explicitly authorised internal systems should be able to reach the service. Audit server logs for unexpected process execution, unfamiliar user accounts, or outbound connections to unusual destinations. Any signs of post-exploitation activity should trigger your incident response process immediately.

This is not a phishing flaw. Employees outside the IT and DevOps teams do not need to avoid clicking a link or opening an attachment to protect against this specific vulnerability. The risk is entirely server-side. That said, if the pipeline environment is breached, developer credentials, code-signing certificates, and deployment tokens stored within it become attacker property.

Why did exploitation begin so quickly after the patch?

The gap between patch release and confirmed exploitation is narrowing across the industry. When a vendor publishes a fix, the patch itself becomes a roadmap. Attackers study the difference between the vulnerable and patched versions to reverse-engineer exactly what the flaw is, then write exploit code and scan the internet for unpatched targets. Verizon's 2024 Data Breach Investigations Report found that exploitation of vulnerabilities as an initial access vector grew 180 percent year-over-year, and the speed of that exploitation continues to compress.

JetBrains had roughly a week of lead time before attacks began. That is a short window, and many organisations missed it.

What does this incident reveal about patch management and security culture?

The speed of exploitation here exposes a gap that security-awareness practitioners see repeatedly in real organisations: the assumption that because a flaw is "a server thing," it sits entirely in the hands of IT and does not need to be communicated more broadly. That assumption is dangerous.

Development teams who run TeamCity, or who depend on it, rarely receive proactive communication about patch urgency. The NIST Cybersecurity Framework treats vulnerability management as an organisational process, not just a technical one. When the people who own the system are not embedded in a security-aware culture, patches sit in queues behind feature work and scheduled maintenance windows. Attackers do not wait for the next maintenance window.

Security-awareness training programmes that include IT staff and developers, not just end-users, consistently surface this blind spot. Developers often feel exempt from security culture because they are technical. In practice they frequently administer high-value systems with weak patch cadences and minimal monitoring. Helping those teams understand that their build infrastructure is a priority target, and connecting them to clear escalation paths when a critical CVE drops, is as important as teaching a finance assistant to spot a spoofed invoice. If your programme does not reach the people who maintain infrastructure, consider reviewing your coverage with a platform that addresses multiple roles.

The second failure pattern this incident illustrates is network exposure. A build server that handles sensitive credentials and pipeline secrets should not be reachable from arbitrary internal addresses, let alone the internet. Least-privilege network segmentation is a standard control, documented in NIST SP 800-53. Many organisations deprioritise it because it requires cross-team coordination between network engineers and application owners. That coordination gap is exactly what attackers exploit when they find a deserialization flaw with no authentication requirement.

Patch fast. Segment the network. Make sure the people managing build infrastructure are inside your security-awareness programme, not outside it.