If your organization runs JetBrains TeamCity on your own servers, you need to stop and check your version today. A new critical flaw, tracked as CVE-2026-63077, lets attackers break into TeamCity servers without a username or password. Security researchers have already spotted active exploitation, and the U.S. government has given federal agencies a hard deadline to patch. This post explains what happened, why it matters, and exactly how to protect your build pipeline.

Table of Contents

1. What Is CVE-2026-63077?
2. How the Attack Works
3. Who Discovered It and When
4. Why This Is So Dangerous for CI/CD Pipelines
5. Is Your Server Affected?
6. CISA’s Involvement and the Federal Deadline
7. How to Patch Your TeamCity Server
8. How to Check for Signs of Compromise
9. Hardening Your TeamCity Deployment Going Forward
10. Frequently Asked Questions
11. Conclusion

What Is CVE-2026-63077?

CVE-2026-63077 is a security bug in JetBrains TeamCity, a popular continuous integration and continuous delivery (CI/CD) platform. Development teams use TeamCity to automatically build, test, and deploy software.

The flaw carries a CVSS score of 9.8 out of 10, which puts it in the “critical” category. <cite index=”16-1″>It is an unauthenticated remote code execution vulnerability caused by insecure deserialization of untrusted data</cite>. In plain terms, an attacker can trick the server into running malicious code just by sending it crafted data over the network. No password, no login, no user click needed.

The bug affects every TeamCity On-Premises version released before the fix. TeamCity Cloud, the JetBrains-hosted version, was already protected before the public disclosure.

How the Attack Works

TeamCity servers and build agents constantly talk to each other. <cite index=”16-1″>Build agents use a communication channel called the agent polling protocol to ask the central server for jobs and configuration updates</cite>.

This protocol accepts serialized data — a technical way of packaging information so it can travel over a network and get rebuilt on the other end. The problem is that <cite index=”15-1″>the server processes attacker-controlled serialized data without adequate validation</cite>. This weakness falls under a well-known bug category called CWE-502, or unsafe deserialization.

An attacker can abuse this gap to bypass authentication entirely. <cite index=”18-1″>They can then execute arbitrary operating system commands using the same privileges assigned to the TeamCity server process</cite>. That means the attacker effectively becomes the TeamCity server itself.

Why Deserialization Bugs Are So Common

Deserialization flaws are a recurring theme in enterprise software. Developers often trust that data arriving from “internal” services, like an agent talking to its own server, is safe. Attackers exploit that assumption by injecting hostile payloads into the data stream before the server ever checks who sent it.

Who Discovered It and When {#discovery}

A security researcher named Antoni Tremblay privately reported the vulnerability to JetBrains on July 10, 2026, following the company’s coordinated disclosure police. This is the responsible way to report a bug: tell the vendor first, give them time to build a fix, and only go public once a patch exists.

JetBrains moved quickly. The company fixed TeamCity Cloud right away and released patched versions of the on-premises product.JetBrains stated that it checked its Cloud environments for signs of exploitation and found none at the time of the advisory.

Despite the responsible disclosure process, the situation escalated fast once the patch details became public. Attackers routinely reverse-engineer official security patches to figure out exactly what was broken, then race to exploit anyone who has not updated yet.

Why This Is So Dangerous for CI/CD Pipelines

A CI/CD server is not just another application. It sits at the center of your entire software supply chain. TeamCity typically holds:

• Your source code repositories and access tokens
• Secrets and credentials used to deploy to production
• Code-signing certificates and keys
• Build configurations and deployment pipelines
• Connections to cloud infrastructure and package registries

A compromise of the central TeamCity server creates serious supply-chain risk. Attackers gaining access could steal source code, build settings, stored secrets, signing material, and deployment connections.

This is not a theoretical worry.State-sponsored hacking groups and ransomware affiliates have previously targeted unpatched TeamCity On-Premises servers. A single compromised build server can let an attacker slip malicious code into your software before it ever reaches customers, turning a legitimate product update into a delivery mechanism for malware.

The Supply Chain Ripple Effect

If attackers modify a build artifact on your TeamCity server, every downstream system that trusts that artifact inherits the compromise. That could mean:

• Production servers pulling a tampered container image
• Customers downloading a backdoored software update
• Internal tools silently exfiltrating data after a “routine” build

This ripple effect is exactly why security teams treat CI/CD servers as high-value targets, right alongside domain controllers and identity providers.

Is Your Server Affected?

Check your deployment type and version against this table.

Deployment	Affected?	Action Needed
TeamCity On-Premises, any version before 2025.11.7	Yes	Patch immediately
TeamCity On-Premises, any version before 2026.1.3	Yes	Patch immediately
TeamCity On-Premises 2025.11.7 or 2026.1.3	No	Already fixed
TeamCity Cloud	No	JetBrains already applied the fix

The issue impacts all TeamCity On-Premises versions exposed over HTTP or HTTPS, meaning any server reachable on the network is a potential target, not just ones directly exposed to the public internet.

CISA’s Involvement and the Federal Deadline

The U.S. Cybersecurity and Infrastructure Security Agency added CVE-2026-63077 to its Known Exploited Vulnerabilities catalog on August 5. This listing only happens once CISA has evidence that a flaw is being actively used in real-world attacks, not just theoretically exploitable.

CISA set an August 8 remediation deadline for affected federal civilian agencies. This requirement comes from Binding Operational Directive 26-04, which requires federal agencies to prioritize patching high-risk vulnerabilities listed in the KEV catalog.

Private organizations are not legally bound by this directive, but security professionals treat a KEV listing as a strong signal: if a nation-state agency is telling its own departments to patch within three days, everyone else should move just as fast.

As of the most recent reporting, it remains unclear exactly how attackers are exploiting the flaw in the wild, who is behind the attacks, or how widespread the campaign has become. That uncertainty is itself a reason for urgency — you cannot rule out that your organization is a target simply because you have not seen unusual activity yet.

How to Patch Your TeamCity Server

Here is a step-by-step path to closing this hole, starting with the fastest option.

Option 1: Upgrade to a Fixed Version (Recommended)

JetBrains fixed the issue in TeamCity versions 2025.11.7 and 2026.1.3. Upgrading is the most complete fix, since it resolves this vulnerability along with any other bug fixes bundled into that release.

If you manage your server from the command line on Linux, a typical upgrade flow looks like this:

# 1. Back up your TeamCity data directory and database first
tar -czvf teamcity-backup-$(date +%F).tar.gz /path/to/TeamCity/.BuildServer

# 2. Stop the TeamCity service
sudo systemctl stop teamcity

# 3. Download the new version from JetBrains
wget https://download.jetbrains.com/teamcity/TeamCity-2026.1.3.tar.gz

# 4. Extract it to your TeamCity installation directory
sudo tar -xzvf TeamCity-2026.1.3.tar.gz -C /opt/teamcity --strip-components=1

# 5. Restart the service and check the logs
sudo systemctl start teamcity
sudo journalctl -u teamcity -f

Always test upgrades on a staging server first if you have one, and confirm your backup is restorable before you touch production.

Option 2: Install the Security Patch Plugin

If you cannot upgrade right away, JetBrains offers a dedicated security patch plugin compatible with TeamCity 2017.1 and later. For installations running TeamCity 2024.03 or newer, this plugin downloads automatically, and administrators get a notification if update alerts are turned on</cite>.

To check for the patch manually:

1. Log in to the TeamCity Administration panel
2. Navigate to Administration | Updates
3. Look for the CVE-2026-63077 security patch plugin
4. Click Install, then restart the TeamCity server when prompted

Keep in mind that JetBrains says the plugin only fixes this specific vulnerability and does not replace a full version update. Treat it as a stopgap, not a permanent solution.

Option 3: Restrict Network Access as a Temporary Measure

If you cannot patch immediately for any reason, reduce your exposure while you plan the update:

# Example: restrict TeamCity server port access to trusted IPs only, using iptables
sudo iptables -A INPUT -p tcp --dport 8111 -s TRUSTED.IP.RANGE.0/24 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 8111 -j DROP

This is not a fix. It only buys you time by shrinking the pool of attackers who can reach the server at all.

How to Check for Signs of Compromise

Patching stops future attacks, but it will not undo damage already done.A successful attack can expose TeamCity data and configurations, modify server state, and potentially compromise the integrity of build artifacts and downstream pipelines.

Review these areas after patching:

• Server and access logs — look for unexpected requests to the agent polling endpoints, especially from unfamiliar IP addresses.
• User accounts and API tokens — check the Administration panel for any accounts or tokens you do not recognize.
• Build configurations — compare recent build steps and scripts against your version control history for unauthorized changes.
• Build artifacts — verify checksums of recently published artifacts against known-good versions.
• Deployment credentials — rotate any secrets, API keys, or signing certificates stored in TeamCity as a precaution.

A quick way to scan recent server logs for suspicious activity on Linux:

grep -i "agentPolling\|deserializ" /opt/teamcity/logs/teamcity-server.log | tail -n 200

If you find anything unusual, isolate the server from the network and involve your incident response team before continuing normal operations.

Hardening Your TeamCity Deployment Going Forward

Beyond this one patch, a few habits reduce your exposure to the next CI/CD vulnerability too:

• Keep TeamCity behind a VPN or firewall rather than exposing it directly to the public internet.
• Enable automatic update notifications so you learn about new patches quickly.
• Rotate secrets stored in TeamCity regularly, not just after an incident.
• Apply least-privilege access so build agents and service accounts hold only the permissions they truly need.
• Monitor the CISA KEV catalog for tools in your stack, so you catch active exploitation warnings early.

Frequently Asked Questions

Does this affect TeamCity Cloud? No. TeamCity Cloud customers are not required to take any action, since JetBrains already applied the fix on its hosted infrastructure.

Do I need to reinstall TeamCity from scratch? No. A standard upgrade to 2025.11.7 or 2026.1.3, or installing the security patch plugin, resolves the vulnerability without a full reinstall.

How was this vulnerability found? It was privately reported by security researcher Antoni Tremblay through JetBrains’ coordinated disclosure program, the standard responsible-reporting process used across the security industry.

Is there proof that attackers are actively exploiting this? Yes. CISA added it to its Known Exploited Vulnerabilities catalog, which only happens when there is confirmed real-world exploitation, though full details of the attack campaign are still emerging.

Conclusion

CVE-2026-63077 is about as serious as CI/CD vulnerabilities get: unauthenticated, remotely exploitable, and sitting at the heart of the software supply chain. TeamCity On-Premises administrators should treat this as a same-day priority, not a task for next sprint. Upgrade to version 2025.11.7 or 2026.1.3, or apply the security patch plugin if an immediate upgrade is not possible. Then check your logs, rotate your secrets, and confirm nothing slipped through before the patch went in.

Vulnerabilities like this one land in the news every week. Stay ahead of the next one by subscribing to GEANTECHNOLOGY’s security briefings for daily updates on critical CVEs, patch deadlines, and practical defense guides written for real IT teams.