A build server, an RMM console, and a firewall manager do different jobs. To an attacker, they share one useful feature: someone has already trusted them with access to everything else.

That is the thread connecting this week’s TeamCity and N-central KEV additions with Cisco’s newly updated FMC advisory. The bugs are different, and their impact is not identical, but each affects a management plane that can turn one foothold into a much larger incident.

TL;DR

  • JetBrains TeamCity — CVE-2026-63077 (CVSS 9.8): unauthenticated RCE via the agent polling protocol, added to CISA KEV on August 5
  • N-able N-central — CVE-2026-18577: an authentication bypass caused by an incomplete fix for CVE-2026-18556; exploited since August 1; Hotfix 2 now supersedes Hotfix 1
  • Cisco Secure Firewall Management Center — CVE-2026-20316: static credentials provide unauthenticated access to a built-in low-privilege account; Cisco confirmed active exploitation and released hotfixes
  • Deep dive: how TeamCity’s XStream deserialization flaw works, why CI/CD servers are supply-chain choke points, and what to hunt for

Three Bugs, One Uncomfortable Pattern

  1. JetBrains TeamCity — CVE-2026-63077 (CVSS 9.8) — Unauthenticated remote code execution via TeamCity’s agent polling protocol. Patched in 2025.11.7 / 2026.1.3. CISA added it to KEV on August 5 after confirming active exploitation. SecurityWeek
  2. N-able N-central — CVE-2026-18577 — Authentication bypass in the MSP/RMM platform caused by an incomplete fix for CVE-2026-18556. In observed attacks, operators used N-central’s “Take Control” feature to reach managed endpoints and deployed Cloudflare Tunnel for persistent access. On-premises operators should install Hotfix 2, build 2026.3.1.10, which supersedes Hotfix 1; hosted instances are updated by N-able. Rapid7
  3. Cisco Secure Firewall Management Center — CVE-2026-20316 — Static credentials let an unauthenticated remote attacker log in as a built-in low-privilege user and access sensitive data. Cisco rated the advisory High despite its 5.3 CVSS score because the flaw can be chained with other FMC vulnerabilities to elevate privileges. Cisco confirmed exploitation and released per-version hotfixes; there is no workaround. Cisco advisory

Deep Dive: CVE-2026-63077 — TeamCity’s Unauthenticated RCE

TeamCity earns the deep dive because it combines a 9.8 score, unauthenticated access, and command execution on a server that often holds source-code access, build secrets, and deployment credentials. Calling that server “internal infrastructure” does not make it less of a crown jewel. It only makes the crown jewel easier to overlook.

🔴 RED TEAM — How the Attack Works

The bug is CWE-502: Deserialization of Untrusted Data, living in the agent polling protocol — the channel build agents use to ask the TeamCity server for jobs and config updates. Because that channel has to work before an agent is authenticated, the server accepts and deserializes agent-supplied data before trust is established.

Attacker sends a crafted object to the TeamCity agent polling endpoint
        ↓
Server deserializes it using XStream, guided by an allowlist
        ↓
Allowlist adds TeamCity's own classes but never removes XStream's
permissive defaults (missing NoTypePermission.NONE)
        ↓
A gadget chain — a sequence of otherwise-harmless classes chained
to produce unintended behavior — reconstructs and executes
        ↓
Arbitrary OS commands run with the privileges of the TeamCity
server process

Why the window exists at all. A newly installed build agent connects before it has an authorization token; TeamCity generates and saves that token during the agent’s first connection. The server therefore has to process part of the agent’s initial communication before the agent is trusted to run builds. CVE-2026-63077 turns that pre-authorization processing into an attack surface. If the server is reachable from the internet, exploiting it for initial access fits T1190 – Exploit Public-Facing Application. The protocol needs a first-contact path, but exposing that path to the public internet is a deployment choice.

What “gadget chain” means in practice. The initial request does not need to upload a new Java class. It supplies an object graph that makes XStream instantiate and connect classes already available to the TeamCity process. Whether a chain works depends on the permitted types and the server’s classpath. Rapid7 found that TeamCity added its allowlisted protocol classes without first clearing XStream’s default permissions; those remaining permissions were sufficient for unsafe deserialization. That is why the patched code applies NoTypePermission.NONE before adding the intended allowlist.

No authentication, no user interaction, network-reachable — that combination is what drives the 9.8 score. This is a variant of the same root-cause pattern (CWE-502) behind CVE-2026-58644 in SharePoint a few weeks ago: an allowlist that’s supposed to restrict what can be deserialized ends up permissive by omission rather than by design.

What makes a CI/CD server specifically worth this effort: depending on its configuration, TeamCity may hold source-code access, build secrets, artifact-repository credentials, and deployment credentials. A foothold here isn’t necessarily “one server compromised”; it can become a supply-chain pivot point. Once execution lands, the objective shifts from the CVE to the environment around it. An attacker running as the TeamCity service account may be able to reach:

  • VCS tokens and SSH keys the server uses to pull every connected repository;
  • environment variables and parameter stores holding deployment and cloud credentials;
  • build configuration and step definitions, which can be edited so the next legitimate build silently ships attacker-controlled changes;
  • artifact repositories the server publishes to, extending reach beyond the build server itself.

Those paths do not require another software vulnerability when the relevant credentials and permissions are already available to the TeamCity process. That is the argument for the segmentation and credential-rotation steps in the Blue Team section below, independent of how the initial RCE was achieved.

🔵 BLUE TEAM — How to Defend

Patch first. Upgrade to TeamCity 2025.11.7 or 2026.1.3. JetBrains also provides a security patch plugin for TeamCity 2017.1 and later when an immediate upgrade is not possible. Restrict the server to trusted networks; JetBrains specifically recommends VPN access or an additional security layer for internet-facing instances.

Hunt the process boundary, the same way you would for the SharePoint bug: look for the TeamCity server’s Java process spawning shells or interpreters it has no legitimate reason to launch.

Sigma-style detection logic:
  ParentImage  contains "java" AND ParentCommandLine contains "TeamCity"
  Image        in (cmd.exe, powershell.exe, pwsh.exe, bash, sh, wget, curl, nc)
  → alert: unexpected child process of TeamCity server

Tune against your own baseline — some plugins legitimately shell out. The signal is an unexpected parent-child relationship combined with an unusual command line, destination, or account.

Treat a compromised build server as a supply-chain incident, not a single-host incident. If you find evidence of exploitation:

  • Rotate every credential and secret the TeamCity server had access to (VCS tokens, deployment keys, artifact repo credentials, cloud provider keys).
  • Audit recent build configurations, pipeline definitions, and artifacts for unauthorized changes — an attacker with server-level RCE can modify what your pipeline ships.
  • Correlate against your VCS and artifact repository logs, not just the TeamCity server’s own logs.

🛠 Tools

  • Red/Purple: Start with authenticated asset inventory and version checks. For TeamCity, confirm that every on-premises server runs 2025.11.7 or 2026.1.3, or has JetBrains’ security patch plugin installed; avoid testing production with a deserialization payload merely to prove it is vulnerable.
  • Purple: Shodan / Censys — use searches scoped to your own domains and addresses to identify accidentally exposed TeamCity, N-central, or Cisco FMC interfaces.
  • Blue: Wazuh — process-creation monitoring and file-integrity rules to catch the parent-child pattern above, plus a scheduled pull of the CISA KEV feed to auto-prioritize patching when your stack shows up.

📊 The Bigger Picture

Three different vendors, three different product categories, one shared pattern: CI/CD servers, RMM platforms, and network management consoles are privileged-by-design choke points. TeamCity RCE or N-central administrative takeover can expose downstream systems directly. Cisco’s FMC flaw is narrower on its own — low-privilege access and sensitive-data exposure — but Cisco warns that it can be chained with other FMC flaws for privilege elevation.

“Internet-facing management plane” is a design decision, not an accident of deployment. Reviewing that decision for every platform in this category — not just patching reactively when the KEV alert fires — is the actual fix. Patching closes this week’s hole; segmentation closes the pattern.

Sources

  1. Critical Security Issue Affecting TeamCity On-Premises (CVE-2026-63077) — JetBrains
  2. Hackers Start Exploiting Recent JetBrains TeamCity Vulnerability — SecurityWeek
  3. Rapid7 Analysis: Unauthenticated RCE in JetBrains TeamCity (CVE-2026-63077) — Rapid7
  4. CVE-2026-18577: N-able N-central Authentication Bypass Exploited in the Wild — Rapid7
  5. N-central 2026.3 Hotfix 2 — Additional Mitigation for CVE-2026-18577 — N-able
  6. Cisco Secure Firewall Management Center Software Static Credential Vulnerability — Cisco
  7. CISA Known Exploited Vulnerabilities Catalog — CISA
  8. Configure Agent Installation — JetBrains
  9. Exploit Public-Facing Application (T1190) — MITRE ATT&CK