TeamCity RCE Is Under Attack. Your CI/CD Server Could Be the Backdoor

CI/CD infrastructure is not supposed to be reachable by random people on the Internet.

Yet plenty of it is.

Now attackers are actively targeting a critical vulnerability in JetBrains TeamCity On-Premises that allows unauthenticated remote code execution. The Australian Cyber Security Centre warned about attacks today, August 25, while CISA had already placed the flaw in its Known Exploited Vulnerabilities catalog.

• The Mess: CVE-2026-63077 is a CVSS 9.8 unauthenticated RCE in TeamCity’s agent polling protocol. An attacker who can reach the server over HTTP/HTTPS can execute operating-system commands with the privileges of the TeamCity server process.

That’s a terrible place for an RCE.

TeamCity is not just another web application. It sits inside the software delivery chain.

Developers push code.

TeamCity builds it.

Tests run.

Artifacts get created.

Deployment pipelines can push those artifacts toward production.

So if an attacker takes control of TeamCity, they haven’t merely compromised one server.

They may have compromised the machinery that builds the software everyone else trusts.

That’s the part worth paying attention to.

The vulnerability is caused by unsafe deserialization in the agent polling protocol. The vulnerable protocol shares a network interface with the TeamCity web UI, which means Internet-facing installations are directly exposed.

No account.

No password.

No employee interaction.

Just network access to a vulnerable TeamCity server.

And then the attacker gets to run commands.

• What Actually Happened: JetBrains patched the vulnerability in TeamCity 2025.11.7 and 2026.1.3, but reports of active and attempted exploitation against unpatched servers have since emerged. JetBrains published additional guidance after receiving those reports.

The vulnerability was disclosed by JetBrains on July 27.

At that point, the company said it was not aware of exploitation.

That didn’t last.

CISA added CVE-2026-63077 to its KEV catalog on August 5 after exploitation was observed. NVD now records the vulnerability as actively exploited, with a total technical impact assessment.

And now the Australian Cyber Security Centre is warning that TeamCity servers are being attacked.

That’s a pretty clear progression:

vulnerability → patch → exploitation → active warnings.

Anyone still running an old TeamCity server is playing against the clock.

There is also a nasty supply-chain angle.

TeamCity servers can hold credentials, source-code access and build configuration. JetBrains itself warns that CI/CD systems are high-value targets because they can provide access to source code and the ability to deploy code into production.

Compromise the build server and you may not need to attack the production application directly.

You attack what produces it.

• The Damage: A compromised TeamCity server can expose credentials, source code and build configuration while allowing attackers to manipulate build artifacts or downstream CI/CD pipelines.

Think about what a typical TeamCity installation might know.

Git credentials.

SSH keys.

Cloud tokens.

Package repository credentials.

Deployment secrets.

Database credentials.

Internal server addresses.

And potentially permissions to push software directly into production.

That’s a fantastic collection of things for an attacker to steal.

Even worse, CI/CD systems are designed to execute commands.

That’s literally their job.

So once the attacker gets remote command execution on the TeamCity server, they are sitting inside a machine whose normal purpose is to run scripts and build software.

Security teams therefore need to think beyond the TeamCity server itself.

If it was compromised, what credentials could it access?

What repositories could it reach?

Which build agents did it control?

Which artifacts did it produce?

What deployments happened while the server was potentially compromised?

Those questions can become much more important than the original exploit.

• The Fix: Upgrade TeamCity On-Premises to 2025.11.7 or 2026.1.3 immediately, or install JetBrains’ security patch plugin if a full upgrade is not currently possible. Then investigate exposed servers for signs of compromise.

JetBrains also provides the security patch plugin for older TeamCity versions, allowing administrators to address this specific vulnerability without immediately performing a full version upgrade.

Do not stop at patching.

If the vulnerable server was exposed to the Internet, rotate credentials that were accessible from TeamCity.

Review build histories.

Look for unexpected build configurations.

Check for modified scripts.

Inspect newly created users and tokens.

Review unusual outbound connections.

And check whether suspicious artifacts were generated during the exposure period.

If TeamCity can deploy to production, inspect those deployments too.

Because if an attacker controls the build pipeline, the question is no longer just “Did they break into TeamCity?”

It becomes:

“What did TeamCity build while they were inside?”

Bugstoday Verdict: A vulnerable web server is bad. A vulnerable CI/CD server is worse. It doesn’t just run code — it builds and ships it. If your TeamCity instance is still vulnerable, patch it before somebody else decides what gets deployed.