CVE-2026-63077, TeamCity Unauthenticated RCE and CI/CD Supply Chain Risk

CVE-2026-63077 is a critical unauthenticated remote code execution vulnerability in JetBrains TeamCity On-Premises. An attacker who can reach a vulnerable TeamCity server over HTTP or HTTPS may be able to bypass authentication checks and execute operating system commands with the privileges of the TeamCity server process.

JetBrains says every TeamCity On-Premises version released before the fixes is affected. The vulnerability is fixed in TeamCity 2025.11.7 and 2026.1.3. Organizations that cannot immediately upgrade can install an official security patch plugin on TeamCity 2017.1 and newer, although JetBrains emphasizes that the plugin fixes only this vulnerability and does not replace a full update. TeamCity Cloud customers do not need to take action because JetBrains applied the necessary protections to its hosted environment. (The JetBrains Blog)

The CVE record maps the flaw to CWE-502, Deserialization of Untrusted Data, and assigns a JetBrains CNA CVSS 3.1 score of 9.8 with the vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. At the time of writing, NVD still marks the record as awaiting enrichment, so the 9.8 score is the vendor CNA assessment rather than an independent NVD analysis. CISA’s SSVC data attached to the record classified exploitation as none, automatability as yes, and technical impact as total on July 27, 2026. (NVD)

JetBrains said when it published the advisory that it was not aware of active exploitation. That statement is useful, but it is not evidence that every exposed server remained uncompromised. It describes the vendor’s visibility at one point in time. It does not eliminate undiscovered attacks, private exploit development, or exploitation after publication. TeamCity has previously attracted nation-state and financially motivated actors soon after severe vulnerabilities became public, so defensive decisions should be based on reachability, privilege, and downstream impact rather than waiting for a confirmed campaign.

The confirmed facts

項目	Confirmed information
CVE	CVE-2026-63077
製品	JetBrains TeamCity On-Premises
脆弱性タイプ	Unauthenticated remote code execution
エントリーポイント	TeamCity agent polling protocol
Network requirement	HTTP or HTTPS access to the TeamCity server
Authentication required	いいえ
User interaction required	いいえ
弱さ	CWE-502, Deserialization of Untrusted Data
CNA severity	CVSS 3.1 score 9.8, Critical
影響を受ける範囲	All TeamCity On-Premises versions before the fixed releases
修正版	2025.11.7 and 2026.1.3
Patch plugin	Available for TeamCity 2017.1 and newer
Execution context	Privileges of the TeamCity server process
TeamCity Cloud	No customer action required
Vendor exploitation statement	JetBrains was unaware of active exploitation when the advisory was published
Disclosure	Privately reported to JetBrains on July 10, 2026, by Antoni Tremblay
Public record date	July 27, 2026

The vulnerability description is unusually concise. JetBrains confirms that exploitation occurs through the agent polling protocol and can produce arbitrary operating system command execution, but it does not publish the vulnerable class, method, serialized object structure, protocol route, gadget chain, or request payload. (The JetBrains Blog)

That distinction matters. CWE-502 tells defenders the weakness class, not the complete exploit implementation. It is reasonable to explain how unsafe deserialization can become remote code execution. It is not reasonable to claim, without evidence, that TeamCity uses a particular public Java gadget chain, a specific dependency, or a known serialized payload format.

No reliable detection strategy should depend on an invented URL pattern or a payload copied from an unrelated Java deserialization exploit. Until JetBrains or the original researcher publishes additional technical details, the most defensible approach is to combine version verification, network exposure analysis, host telemetry, TeamCity audit data, file integrity monitoring, credential review, and artifact validation.

Why a TeamCity RCE is more than a server compromise

A TeamCity server is part of the software factory. It does not merely serve pages or store application data. It coordinates source retrieval, build configuration, test execution, package creation, artifact publication, infrastructure automation, and deployment.

A typical TeamCity installation may be trusted to communicate with:

• Source code repositories
• Build agents
• Package repositories
• Container registries
• Artifact storage
• Cloud providers
• Kubernetes clusters
• Deployment servers
• Secret managers
• Code-signing services
• Notification platforms
• Issue trackers
• Internal APIs

This position creates a much larger blast radius than a conventional application server compromise.

If attackers obtain command execution on a TeamCity server, they may be able to read configuration, inspect stored credentials, alter server state, change build behavior, introduce malicious plugins, manipulate build definitions, or interfere with artifact publication. JetBrains explicitly warns that exploitation could expose TeamCity data, configurations, and stored credentials, modify server state, and compromise the integrity of build artifacts and downstream CI/CD pipelines. (The JetBrains Blog)

The distinction between control-plane compromise and worker compromise is important. A build agent normally executes build steps, so command execution on an agent can already be dangerous. A compromised server may be worse because the server decides which agents receive which jobs, supplies build configuration, maintains project metadata, brokers credentials, and records the history that engineers use to decide whether a build is legitimate.

A successful attack does not have to modify source code in Git. An attacker may instead alter a build step after source review, change an environment variable, substitute a dependency, replace an artifact after compilation, redirect an upload destination, or modify the metadata used to associate an artifact with a source revision.

That creates a difficult forensic scenario: the source repository may look clean while the produced software is not.

How the agent polling protocol creates a reachable trust boundary

TeamCity agents normally use a unidirectional agent-to-server connection. An agent establishes an HTTP or HTTPS connection to the TeamCity server and periodically polls it for commands. The server does not need to initiate an inbound connection to the agent for this default mode. (JetBrains)

The direction of the TCP connection can be misleading. Because the agent initiates the connection, administrators may assume the protocol is relevant only to trusted agents. The server still receives, parses, and responds to protocol messages. Any reachable protocol handler must therefore treat remote input as untrusted until the peer has been authenticated and the message has been validated.

JetBrains documentation says that agent-to-server traffic can contain build settings, repository access credentials and keys, repository sources, build artifacts, build progress messages, and build logs. JetBrains recommends HTTPS for this communication because plain HTTP can expose that data to interception. (JetBrains)

CVE-2026-63077 crosses this trust boundary before authentication has protected the operation. According to the advisory, an unauthenticated attacker can exploit the agent polling protocol to bypass authentication checks and execute commands on the server.

The conceptual path is:

Attacker-controlled HTTP or HTTPS request
                  |
                  v
Reachable TeamCity server interface
                  |
                  v
Agent polling protocol handler
                  |
                  v
Untrusted serialized data is processed
                  |
                  v
Unexpected object behavior or object graph
                  |
                  v
Authentication boundary is bypassed
                  |
                  v
Code runs as the TeamCity server process
                  |
                  v
Credentials, configuration, builds, artifacts, and pipelines are at risk

This diagram is intentionally conceptual. JetBrains has not publicly documented the exact malicious request, object type, or internal call sequence. The useful conclusion is not that every agent request is malicious. It is that a protocol intended for machine-to-machine communication exposed a pre-authentication parsing path powerful enough to reach operating system command execution.

Why untrusted deserialization can become code execution

Serialization converts an object and its state into a representation that can be stored or transmitted. Deserialization performs the reverse operation by reconstructing objects from that representation.

The security problem is that object reconstruction is not necessarily passive. In Java, classes may define methods that run during deserialization. The runtime may instantiate multiple related classes, restore references, allocate arrays, resolve proxies, and execute custom logic while reconstructing the object graph.

Oracle’s Java documentation states plainly that deserialization is a form of code execution because a class’s readObject method can contain custom code. Oracle recommends not deserializing untrusted data and provides ObjectInputFilter to restrict acceptable classes and limit object graph complexity. Filtering is not automatically active unless an application or JVM configuration enables it. (Oracle Docs)

MITRE defines CWE-502 as a condition in which software deserializes untrusted data without sufficiently ensuring that the resulting data is valid. Depending on the language, libraries, available classes, and application logic, consequences can include object manipulation, denial of service, authentication bypass, or code execution. (Common Weakness Enumeration)

A common Java exploitation model involves a gadget chain. A gadget is an existing method or class behavior that performs an operation useful to an attacker when triggered in an unexpected object graph. Attackers do not always need to upload a new executable class. They may combine behaviors already present in the application’s classpath.

However, the presence of CWE-502 does not prove that CVE-2026-63077 uses a familiar public gadget chain. The exploit could involve:

• Native Java serialization
• A custom binary serialization layer
• Application-specific object reconstruction
• A framework serializer
• A dangerous callback in a TeamCity class
• A logic flaw combined with deserialization
• A bundled library gadget
• Another object-instantiation mechanism categorized under CWE-502

The public record does not currently distinguish among these possibilities.

The most effective architectural defense is to avoid accepting attacker-controlled serialized objects. When serialized objects are unavoidable, defenses should be layered:

1. Authenticate the peer before processing complex messages.
2. Protect message integrity so data cannot be altered in transit.
3. Allow only a small set of expected message types.
4. Reject unknown classes rather than attempting to sanitize them.
5. Limit object depth, references, arrays, and total byte size.
6. Validate every reconstructed field and state transition.
7. Run the parser with minimal operating system permissions.
8. Separate parsing from high-trust control-plane operations.
9. Remove unnecessary gadget-capable libraries from the classpath.
10. Log rejected types and malformed object graphs.

A denylist is usually weaker than an allowlist. A denylist assumes defenders know every dangerous class and every future bypass. An allowlist starts with the protocol’s expected types and rejects everything else.

What an attacker needs

CVE-2026-63077 has a low-complexity, network-reachable CVSS vector with no privileges or user interaction required. That does not mean every TeamCity installation is equally reachable. The practical attack surface depends on network design.

An attacker needs a path to the TeamCity server’s relevant HTTP or HTTPS interface. Possible paths include:

• Direct internet exposure
• Access through a reverse proxy
• A compromised VPN account
• A partner network
• A developer workstation
• A build-agent network
• A compromised internal service
• Cloud network peering
• A Kubernetes cluster network
• An SSRF primitive in another application
• An exposed administrative jump host

An internal-only TeamCity server is safer than an internet-facing one, but “internal” is not the same as unreachable. Build environments frequently connect many trust zones: developer devices, ephemeral runners, source platforms, cloud accounts, and production deployment systems. A threat actor with an existing foothold may view TeamCity as a privilege and supply-chain escalation target.

A plausible attack progression is:

Initial reachability

The attacker identifies a vulnerable TeamCity server or reaches it from a previously compromised system. The target responds over HTTP or HTTPS.

Pre-authentication protocol interaction

The attacker sends data to the agent polling protocol path. Because exploitation requires no TeamCity account, MFA and normal login controls do not prevent the initial trigger.

Server process execution

The vulnerable server processes attacker-controlled data and executes commands with the privileges of the TeamCity service account.

Local discovery

The attacker examines:

• TeamCity installation paths
• TeamCity Data Directory
• Database configuration
• Environment variables
• Running processes
• Mounted storage
• Plugin directories
• Network routes
• Service account permissions
• Available command-line tools
• Cloud instance metadata access
• Connected services

Credential access

The attacker looks for credentials associated with:

• VCS roots
• SSH keys
• API tokens
• Artifact repositories
• Container registries
• Cloud deployments
• Kubernetes
• Database connections
• Secret managers
• Signing services
• Notification and webhook integrations

Control-plane manipulation

The attacker may modify:

• User accounts
• Roles
• Access tokens
• Authentication settings
• Build configurations
• Build templates
• Project parameters
• Versioned settings
• Kotlin DSL
• プラグイン
• Agent authorization
• Artifact destinations
• Deployment steps

Downstream compromise

The attacker may then attempt to:

• Steal source code
• Modify a build without changing the repository
• Produce a trojanized artifact
• Replace an existing artifact
• Push a malicious package
• Publish a malicious container
• Deploy to a test or production environment
• Steal additional credentials from build agents
• Use CI access for lateral movement

Not every successful exploitation will reach every stage. The service account may be heavily restricted, secrets may be externalized, signing may occur in an isolated control plane, and build workers may be ephemeral. Those controls reduce impact. They do not make the vulnerable server safe to leave unpatched.

The TeamCity server process defines the first blast radius

JetBrains states that commands run with the privileges of the TeamCity server process. That detail should guide both prioritization and incident response. (The JetBrains Blog)

On Linux, administrators should identify:

• The Unix account running TeamCity
• Its group memberships
• Sudo permissions
• Writable directories
• Mounted secrets
• SSH material
• Container socket access
• Cloud instance roles
• Kubernetes service account tokens
• Database credentials
• Outbound network access

On Windows, they should identify:

• The service logon account
• Local group memberships
• Service privileges
• Access to credential stores
• Access to network shares
• Installed deployment tools
• PowerShell capabilities
• Domain privileges
• Access to code-signing certificates
• Scheduled task permissions

Running TeamCity as root, LocalSystem, a domain administrator, or another broadly privileged identity turns application-level RCE into a much larger infrastructure compromise.

A dedicated low-privilege account limits the immediate operating system scope, but an apparently restricted TeamCity account may still have valuable application access. A service account that cannot modify /etc may still read the TeamCity Data Directory, query the TeamCity database, alter build configurations, access stored VCS credentials, or communicate with build agents.

Least privilege changes the size of the first blast radius. It does not remove the CI/CD trust problem.

A CI/CD compromise can invalidate otherwise clean source code

Security reviews often assume that trusted source produces trusted software. That assumption holds only when the build platform is also trusted.

Consider a release process in which:

1. Engineers review a pull request.
2. The commit is signed and merged.
3. TeamCity retrieves the approved commit.
4. A build agent compiles the code.
5. TeamCity publishes the artifact.
6. A deployment job promotes it to production.

If an attacker controls the TeamCity server between steps three and five, the repository can remain unchanged while the output is altered.

Possible manipulation points include:

Manipulation point	Source repository changes required	Potential result
Build parameter	いいえ	Malicious compiler option or feature flag
Environment variable	いいえ	Alternate dependency, endpoint, or behavior
Build step	いいえ	Additional script executed during build
Build template	いいえ	Many projects inherit malicious behavior
Agent selection	いいえ	Job routed to a compromised worker
Dependency resolution	いいえ	Malicious package substituted
Artifact upload	いいえ	Clean output replaced after compilation
Version metadata	いいえ	Malicious artifact associated with trusted commit
Signing workflow	いいえ	Compromised output signed as legitimate
Deployment step	いいえ	Different artifact deployed from the one reviewed

This is why patching the TeamCity server does not automatically restore confidence in artifacts produced before the patch. The software factory must be treated as a trust system, not merely a collection of servers.

SLSA guidance describes the build platform as the full infrastructure that can influence the transformation from source to package. It emphasizes provenance generation and isolation between builds. SLSA also warns that signing secrets should remain in a trusted control plane rather than being directly accessible to build workers. (SLSA)

Affected versions and remediation choices

JetBrains provides two preferred fixed releases:

• TeamCity 2025.11.7
• TeamCity 2026.1.3

Both releases also include fixes for more than twenty security vulnerabilities, which is one reason a full update is preferable to installing only the CVE-2026-63077 patch plugin. (The JetBrains Blog)

Current deployment	CVE-2026-63077 status	推奨される措置
TeamCity 2026.1.3 or newer	Fixed	Confirm version, exposure controls, and successful restart
TeamCity 2026.1.0 through 2026.1.2	脆弱	Upgrade to 2026.1.3 or newer
TeamCity 2025.11.0 through 2025.11.6	脆弱	Upgrade to 2025.11.7 or newer
Older TeamCity 2017.1 or newer	脆弱	Upgrade; use the official security plugin only when immediate upgrade is impossible
Versions older than 2017.1	Vulnerable and not covered by the announced plugin range	Remove network access and upgrade to a supported fixed release
TeamCity Cloud	Customer action not required	No local patching required

JetBrains says the security patch plugin supports TeamCity 2017.1 and newer. For TeamCity 2017.1 through 2018.1, the server must be restarted after installation. Starting with TeamCity 2018.2, the plugin can be enabled without a server restart. TeamCity 2024.03 and newer can automatically download available security patch plugins and notify administrators when configured to do so. Administrators can review pending patches under Administration → Updates → Available security updates. (The JetBrains Blog)

The plugin is a temporary risk-reduction mechanism, not an equivalent replacement for the full maintenance release. JetBrains explicitly states that the plugin addresses only CVE-2026-63077. It does not deliver the other security fixes included in 2025.11.7 or 2026.1.3. (The JetBrains Blog)

Upgrade preparation

Before upgrading:

1. Record the current TeamCity version and build number.
2. Export or document installed plugins.
3. Check plugin compatibility with the target version.
4. Back up the TeamCity database.
5. Back up the TeamCity Data Directory.
6. Preserve supplementary data required for restoration.
7. Verify that the backup is stored outside the TeamCity host.
8. Record current service permissions and network rules.
9. Establish a rollback plan.
10. Notify build and release owners of the maintenance window.

JetBrains recommends backing up settings, database content, and supplementary data before upgrading. TeamCity stores information in both its database and the TeamCity Data Directory, and a new server version may convert those data structures during upgrade. (JetBrains)

A backup created after suspected exploitation should not automatically be considered trustworthy. It can be useful as evidence and as a source for carefully reviewed configuration, but restoring it wholesale may restore malicious plugins, modified build definitions, attacker-created identities, or compromised secrets.

Find every TeamCity server before deciding that the issue is fixed

Large organizations often have more TeamCity servers than the central platform team expects. Common sources of overlooked exposure include:

• Disaster-recovery instances
• Migration environments
• Test installations
• Legacy business units
• Acquired companies
• Developer-managed servers
• Temporary proof-of-concept systems
• Old Kubernetes namespaces
• Stopped but easily restarted cloud instances
• Cloned virtual machines
• Internet-facing reverse proxies
• Secondary TeamCity nodes
• Old Docker Compose stacks

Inventory should begin with internal sources rather than blind internet scanning:

• CMDB records
• DNS zones
• TLS certificate inventories
• Reverse proxy configurations
• Load balancer listeners
• Cloud asset inventories
• Kubernetes workloads
• Container registries
• Infrastructure-as-code repositories
• Firewall rules
• Endpoint software inventories
• Secrets manager references
• Monitoring targets
• Backup catalogs

The goal is to identify every reachable TeamCity server, its owner, version, trust zone, and downstream authority.

Authenticated version verification

TeamCity exposes server version information through its REST API. JetBrains documents /app/rest/version as a version endpoint and /app/rest/server as a broader server information endpoint. Use an authorized token and direct the request only at systems your organization owns. (JetBrains)

#!/usr/bin/env bash
set -euo pipefail

: "${TEAMCITY_URL:?Set TEAMCITY_URL, for example https://teamcity.internal.example}"
: "${TEAMCITY_TOKEN:?Set a read-only TeamCity access token}"

curl --fail --silent --show-error \
  --header "Authorization: Bearer ${TEAMCITY_TOKEN}" \
  "${TEAMCITY_URL%/}/app/rest/version"

printf '\n'

For broader server metadata:

curl --fail --silent --show-error \
  --header "Authorization: Bearer ${TEAMCITY_TOKEN}" \
  --header "Accept: application/json" \
  "${TEAMCITY_URL%/}/app/rest/server?fields=version,buildNumber,buildDate,startTime,webUrl"

Avoid placing tokens directly in shell history. Use a temporary environment variable, protected secrets file, workload identity, or approved secret injection method.

TeamCity CLI verification

For environments already configured with the TeamCity CLI:

teamcity api '/app/rest/server'

JetBrains documents the CLI’s teamcity api command as an authenticated interface to TeamCity REST endpoints. A read-only CLI configuration can reduce the chance of accidental modifications during inventory. (JetBrains)

Docker inventory

docker ps --format '{{.ID}}\t{{.Image}}\t{{.Names}}' \
  | grep -i teamcity || true

docker inspect teamcity-server \
  --format 'Image={{.Config.Image}} Started={{.State.StartedAt}}'

An image tag is useful but not conclusive. Mutable tags, locally rebuilt images, and stale containers can create differences between the declared image and the running software. Record the image digest and confirm the version through TeamCity itself.

Kubernetes inventory

kubectl get deployments,statefulsets,pods \
  --all-namespaces \
  -o custom-columns='KIND:.kind,NAMESPACE:.metadata.namespace,NAME:.metadata.name,IMAGES:.spec.template.spec.containers[*].image' \
  | grep -i teamcity || true

Then inspect the relevant workload:

kubectl -n ci get deployment teamcity-server -o yaml
kubectl -n ci get ingress,service,endpoints

Check both the image and network exposure. A patched container behind an old public load balancer is patched, but the load balancer may also lead to another forgotten TeamCity backend.

Prioritize by reachability and authority

Every vulnerable version requires remediation, but operational triage should account for exposure and downstream privilege.

Environment	優先順位	Reason
Internet-facing TeamCity server	Emergency	No credentials are required and remote code execution may expose the software supply chain
Reachable from broad corporate or partner networks	Emergency	A compromised user device or partner system may reach the server
Reachable from build-agent subnets with weak agent isolation	Emergency	A compromised agent or workload may attack the control plane
Internal server with strict allowlists and limited service permissions	クリティカル	Network controls reduce reachability but do not remove the vulnerability
Offline or powered-down legacy server	高い	Confirm it cannot be restarted or reached before scheduling removal
Patched server with evidence of suspicious pre-patch activity	Incident response	Patching does not remove persistence or restore credential trust

A WAF, VPN, firewall, or identity-aware proxy is a compensating control, not a fix. It can reduce who reaches the vulnerable code, but it does not correct unsafe processing inside TeamCity.

The vendor’s longer-term guidance is to restrict TeamCity access to trusted networks, require VPN access or an additional security layer for internet-facing installations, run the server with minimum operating system privileges, and place the TeamCity server on a dedicated host separate from build agents. (The JetBrains Blog)

Safe validation without attempting remote code execution

Production validation does not require an exploit.

A safe CVE-2026-63077 assessment should answer five questions:

1. Is the asset really TeamCity On-Premises?
2. Is its version below 2025.11.7 or 2026.1.3?
3. Has the official security patch plugin been installed and enabled?
4. Can an untrusted or insufficiently trusted network reach the server?
5. Is there evidence that the server may already have been compromised?

The result should be classified precisely.

結果	意味
脆弱	Version is affected and no effective official patch is present
パッチド	Fixed version is running or the official plugin is verified as active
Mitigated but vulnerable	Network access is restricted, but vulnerable code remains
Potentially compromised	Suspicious activity exists or exposure was significant enough to require investigation
Unable to determine	Version, patch state, or asset ownership cannot be verified
Not affected	Confirmed TeamCity Cloud deployment or another product

Do not mark an instance “not vulnerable” only because:

• The login page requires authentication
• MFA is enabled
• The server uses HTTPS
• No exploit alert fired
• A WAF is present
• The server is not indexed by an internet search engine
• No public PoC has been found
• The service account is non-root
• The server has been patched without reviewing pre-patch activity

Authentication on the normal web interface does not stop a vulnerability that bypasses authentication. HTTPS protects transport confidentiality and integrity; it does not make malicious application messages safe. Non-root execution reduces host impact but can still expose TeamCity data and connected systems.

Safe local PoC for understanding CWE-502

The following demonstration is not a TeamCity exploit. It does not implement the TeamCity agent polling protocol, connect to a network service, use a gadget chain, execute a command, or reproduce proprietary TeamCity code.

It runs entirely on the local machine. Its only purpose is to show two properties of Java deserialization:

• A deserialized class can execute a custom readObject メソッドを使用する。
• An allowlist filter can reject an unexpected class before its deserialization hook runs.

import java.io.ByteArrayInputStream;
import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.io.InvalidClassException;
import java.io.ObjectInputFilter;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import java.io.Serializable;

public final class SafeDeserializationDemo {

    /**
     * The only object type that our toy polling protocol expects.
     */
    private record PollingRequest(long agentId, long sequence)
            implements Serializable {
        private static final long serialVersionUID = 1L;
    }

    /**
     * An unexpected type with a harmless deserialization hook.
     * It prints a message only. It does not execute a system command.
     */
    private static final class UnexpectedMessage implements Serializable {
        private static final long serialVersionUID = 1L;

        private void readObject(ObjectInputStream input)
                throws IOException, ClassNotFoundException {
            input.defaultReadObject();
            System.out.println(
                "[demo] UnexpectedMessage.readObject was executed"
            );
        }
    }

    private static byte[] serialize(Object value) throws IOException {
        ByteArrayOutputStream bytes = new ByteArrayOutputStream();

        try (ObjectOutputStream output =
                     new ObjectOutputStream(bytes)) {
            output.writeObject(value);
        }

        return bytes.toByteArray();
    }

    /**
     * Unsafe because it accepts any serializable class available
     * to the application.
     */
    private static Object deserializeWithoutFilter(byte[] data)
            throws IOException, ClassNotFoundException {
        try (ObjectInputStream input =
                     new ObjectInputStream(
                         new ByteArrayInputStream(data))) {
            return input.readObject();
        }
    }

    /**
     * Safer toy implementation:
     * - permits only PollingRequest
     * - rejects deep or unusually large object graphs
     * - rejects every unexpected class
     */
    private static Object deserializeWithAllowlist(byte[] data)
            throws IOException, ClassNotFoundException {

        try (ObjectInputStream input =
                     new ObjectInputStream(
                         new ByteArrayInputStream(data))) {

            ObjectInputFilter filter = information -> {
                if (information.depth() > 4
                        || information.references() > 16
                        || information.streamBytes() > 4096) {
                    return ObjectInputFilter.Status.REJECTED;
                }

                Class<?> type = information.serialClass();

                if (type == null) {
                    return ObjectInputFilter.Status.UNDECIDED;
                }

                if (type == PollingRequest.class) {
                    return ObjectInputFilter.Status.ALLOWED;
                }

                return ObjectInputFilter.Status.REJECTED;
            };

            input.setObjectInputFilter(filter);
            return input.readObject();
        }
    }

    public static void main(String[] args) throws Exception {
        byte[] expected = serialize(new PollingRequest(42L, 7L));
        byte[] unexpected = serialize(new UnexpectedMessage());

        System.out.println("Reading expected message with allowlist:");
        System.out.println(deserializeWithAllowlist(expected));

        System.out.println();
        System.out.println("Reading unexpected message without filter:");
        deserializeWithoutFilter(unexpected);

        System.out.println();
        System.out.println("Reading unexpected message with allowlist:");

        try {
            deserializeWithAllowlist(unexpected);
        } catch (InvalidClassException exception) {
            System.out.println(
                "[demo] Rejected before the unexpected hook could run"
            );
        }
    }
}

Compile and run it in an isolated local directory:

javac SafeDeserializationDemo.java
java SafeDeserializationDemo

Expected output resembles:

Reading expected message with allowlist:
PollingRequest[agentId=42, sequence=7]

Reading unexpected message without filter:
[demo] UnexpectedMessage.readObject was executed

Reading unexpected message with allowlist:
[demo] Rejected before the unexpected hook could run

The example is intentionally benign. The unexpected class prints a local message and nothing more. A real deserialization vulnerability becomes dangerous when the application’s available classes, callbacks, object graph, or validation logic can perform sensitive operations.

The defensive lesson is that checking a field after readObject() returns may be too late. The application has already reconstructed the object and may already have triggered class-specific behavior. Type restrictions and graph limits must be enforced during deserialization.

アン ObjectInputFilter is also not a universal repair for every deserialization flaw. It can fail if:

• The allowlist is too broad
• A dangerous class is mistakenly allowed
• Application logic trusts malicious field values
• Multiple filters are combined incorrectly
• A different serialization mechanism bypasses the filter
• The object graph causes resource exhaustion within permitted types
• Authentication occurs after parsing
• An attacker can select an unexpected parser

For TeamCity administrators, the correct remediation is the JetBrains update or official security plugin. A JVM filter added without vendor guidance should not be treated as a substitute.

Detection cannot rely on a public exploit signature

JetBrains has not published the complete exploit format. That limits signature-level detection but does not prevent useful hunting.

Detection should focus on behavior across several layers.

Network telemetry

Collect and preserve:

• Reverse proxy access logs
• Load balancer logs
• WAF logs
• Firewall flow records
• TeamCity HTTP access logs
• TLS termination metadata
• Network detection telemetry
• DNS queries from the TeamCity server
• Outbound connection logs

Look for:

• Requests from networks that do not contain authorized build agents
• Requests from new internet sources
• Requests from hosting providers, anonymization services, or unusual geographies
• Sudden increases in polling-related traffic
• Unusual request sizes or content types
• Repeated malformed requests
• Requests followed by new outbound connections from the server
• Access during unusual maintenance windows
• Requests to TeamCity immediately before service restarts or configuration changes

Because the exact malicious route has not been disclosed, avoid a rule that assumes one URL, extension, header, or serialized magic sequence represents all exploitation.

A useful investigation sequence is temporal correlation:

Unexpected inbound TeamCity request
          followed within minutes by
TeamCity Java process spawning a shell or utility
          followed by
Outbound network connection or file creation
          followed by
User, token, plugin, or build configuration change

One signal may be benign. Several related signals are much stronger.

Process telemetry

The highest-value host signal is often an unexpected child process of the TeamCity server’s Java runtime.

Potentially suspicious children include:

• コマンドエグゼ
• パワーシェルエグゼ
• pwsh.exe
• sh
• バッシュ
• カール
• ウィジェット
• certutil.exe
• bitsadmin.exe
• rundll32.exe
• regsvr32.exe
• mshta.exe
• パイソン
• パール
• nc
• ソカット

Context matters. Some organizations run maintenance scripts from the same Java or Tomcat environment, and security software may use unexpected process paths. The server should normally be separate from build agents, which reduces the number of legitimate compilers and shells expected under the TeamCity server process. JetBrains recommends this separation. (The JetBrains Blog)

Microsoft Defender hunting example

This query is behavioral. It is not a CVE-specific signature.

DeviceProcessEvents
| where InitiatingProcessFileName in~ ("java.exe", "java")
| where InitiatingProcessCommandLine has_any (
    "TeamCity",
    "teamcity",
    "catalina",
    "BuildServer"
)
| where FileName in~ (
    "cmd.exe",
    "powershell.exe",
    "pwsh.exe",
    "sh",
    "bash",
    "curl.exe",
    "wget.exe",
    "certutil.exe",
    "rundll32.exe",
    "mshta.exe",
    "python.exe"
)
| project
    Timestamp,
    DeviceName,
    AccountName,
    InitiatingProcessFileName,
    InitiatingProcessCommandLine,
    FileName,
    ProcessCommandLine,
    SHA256
| order by Timestamp desc

Review the parent and grandparent processes, account, working directory, network activity, file writes, and nearby TeamCity requests. Do not automatically label every match as exploitation.

Linux audit review

Where auditd process execution rules are already deployed:

ausearch \
  --start "2026-07-01 00:00:00" \
  --end now \
  -ua teamcity \
  -m EXECVE \
  --interpret

For systems using a different service account, replace teamcity with the actual UID or username.

Journal review may also help:

journalctl \
  --since "2026-07-01" \
  _UID="$(id -u teamcity)" \
  --output short-iso

Investigate:

• Shell execution
• New interpreters
• Package installation
• Archive extraction
• Download tools
• User management commands
• Service creation
• Scheduled tasks
• Firewall changes
• Credential access
• Unusual file permissions

File and configuration telemetry

Monitor the TeamCity installation and data paths for unexpected changes.

The TeamCity Data Directory is critical because it contains configuration, build results, and operational files. TeamCity also stores build history, users, and other data in its database. (JetBrains)

レビュー

• Plugin installation directories
• Plugin cache directories
• Tomcat web application directories
• TeamCity configuration files
• Authentication configuration
• VCS root definitions
• Project configuration
• Versioned settings
• Startup scripts
• Service unit files
• Scheduled tasks
• Temporary directories
• Newly created JAR, ZIP, DLL, EXE, shell, or PowerShell files

A generic recent-file review on Linux can help narrow the timeline:

find /opt/TeamCity /home/teamcity/.BuildServer \
  -xdev \
  -type f \
  -newermt '2026-07-01 00:00:00' \
  -printf '%TY-%Tm-%TdT%TH:%TM:%TS %u %g %m %s %p\n' \
  2>/dev/null \
  | sort

Adjust paths to match the installation. Do not delete unfamiliar files before collecting hashes, metadata, and copies for analysis.

On Windows, use an approved endpoint or forensic collection tool to enumerate recently created and modified files in:

• TeamCity installation directories
• TeamCity Data Directory
• Tomcat work and webapps directories
• Service account profile directories
• ProgramData
• Temporary directories
• PowerShell history locations

Historical analysis of CVE-2024-27198 showed that malicious TeamCity plugins could leave artifacts in Tomcat work directories, webapp plugin paths, plugin caches, and TeamCity configuration. Those paths are not proof of CVE-2026-63077 exploitation, but they remain useful locations to inspect because plugins and configuration are powerful persistence mechanisms in TeamCity. (ラピッド7)

TeamCity audit and administrative review

Review the TeamCity administration audit history for:

• New users
• Role changes
• New system administrators
• Token creation or deletion
• Authentication provider changes
• Plugin upload, enablement, disablement, or deletion
• Agent authorization
• Project creation
• VCS root changes
• Build step changes
• Build template changes
• Parameter changes
• Artifact rule changes
• Cleanup policy changes
• Server setting changes
• HTTPS or certificate changes

Review both successful and failed operations. Attackers may create an account or token, use it, and then delete it. Deletion can be as important as creation.

Do not assume the audit log is complete after server-level command execution. An attacker with access to the database, data directory, or underlying storage may be able to alter or delete evidence. Correlate TeamCity records with immutable or external logs wherever possible.

Outbound network behavior

A TeamCity server may legitimately access:

• Source repositories
• Package repositories
• JetBrains update infrastructure
• Artifact stores
• Cloud APIs
• Internal services

Baseline those destinations. Investigate:

• New direct IP connections
• Newly registered domains
• Dynamic DNS
• Unapproved file-sharing services
• Anonymous paste services
• New SSH destinations
• Reverse tunnels
• Unexpected DNS-over-HTTPS
• High-volume data transfer
• Connections from the server to end-user subnets
• Connections to domain controllers
• Connections to cryptocurrency infrastructure

Egress filtering can reduce post-exploitation capability. It should permit only the services the TeamCity server itself needs. Build-agent internet access should be governed separately.

Patching and compromise assessment are different tasks

A patched server can still be compromised.

Installing TeamCity 2026.1.3, 2025.11.7, or the security patch plugin prevents the vulnerable path from being exploited in the same way. It does not automatically:

• Remove attacker-created users
• Revoke stolen tokens
• Delete malicious plugins
• Restore modified build configurations
• Remove scheduled tasks
• Undo service changes
• Remove malware
• Restore artifact integrity
• Revoke published packages
• Rebuild compromised containers
• Rotate cloud credentials
• Restore trust in signing keys

Use two separate workstreams:

Vulnerability remediation

• Restrict access
• Upgrade or apply the official plugin
• Confirm the running version
• Confirm service restart where required
• Verify the patch state from an approved network
• Restore controlled availability

Incident investigation

• Determine the exposure window
• Preserve evidence
• Hunt for exploitation and persistence
• Identify accessible credentials
• Review TeamCity changes
• Inspect agents and downstream systems
• Validate artifacts
• Rotate secrets
• Rebuild compromised infrastructure

Completing the first workstream does not close the second.

Incident response for an exposed or suspicious server

Contain without destroying evidence

If exploitation is suspected:

1. Remove the server from internet and untrusted network access.
2. Preserve access for designated responders through a controlled path.
3. Stop new builds and deployments where business impact allows.
4. Disable artifact promotion.
5. Prevent automatic cleanup from deleting relevant logs.
6. Capture volatile information before rebooting.
7. Snapshot disks or virtual machines using approved forensic procedures.
8. Record the current system time and timezone.
9. Record running processes and network connections.
10. Preserve reverse proxy and firewall logs outside the host.

Do not immediately reinstall the operating system if doing so would destroy the only available evidence. Conversely, do not keep a potentially compromised build control plane operating merely to preserve convenience.

Establish the exposure window

Record:

• First date the vulnerable version was deployed
• First date the server became reachable from each trust zone
• Date and time the official fix was applied
• Date and time network restrictions were introduced
• Earliest retained network logs
• Earliest retained endpoint telemetry
• Earliest retained TeamCity audit records
• Build and release activity during the window

The vulnerable software may have existed for years, but the useful investigation window also depends on when exploit knowledge became available to potential attackers. JetBrains received the private report on July 10, 2026, and the CVE became public on July 27. A cautious investigation should not assume exploitation could begin only after the public date, especially for highly exposed or targeted environments. (The JetBrains Blog)

Preserve TeamCity evidence

Collect:

• TeamCity server logs
• Activity and audit logs
• HTTP access logs
• TeamCity Data Directory
• Database snapshot
• Installed plugin inventory
• Plugin binaries and hashes
• Authentication configuration
• User and role inventory
• Access token metadata
• Agent inventory
• Project configuration
• Build configurations and templates
• Versioned settings
• Kotlin DSL repositories
• VCS roots
• Artifact storage configuration
• Build history
• Deployment history
• Server health history
• Backup history

Store evidence on a system the TeamCity service account cannot modify.

Review identity changes

Investigate:

• Accounts created during the exposure window
• Accounts granted administrator rights
• New access tokens
• Tokens with unusual names
• Tokens created and quickly deleted
• Changes to external authentication
• New service accounts
• Disabled security controls
• Changes to group membership
• Unexpected agent authorizations

Compare TeamCity identity records with identity provider, endpoint, and administrator activity.

Review build control changes

For every high-value project, compare current configuration with a known-good version.

検査しろ：

• Build steps
• Templates
• Triggers
• Dependencies
• Artifact rules
• Environment variables
• Password parameters
• Command-line runners
• PowerShell runners
• Docker runners
• Maven, Gradle, and npm settings
• Deployment steps
• Branch filters
• Pull-request handling
• Agent requirements
• Failure conditions
• Cleanup rules
• Versioned settings synchronization

If Kotlin DSL or another configuration-as-code mechanism is enabled, compare the TeamCity UI state, repository history, and last applied revision. A clean repository does not prove the runtime configuration was never changed through the UI.

Credential rotation priorities

Credential rotation should be based on whether the compromised server process could access or influence the credential, not merely whether a secret appeared in a log.

Credential category	優先順位	Required response
Code-signing and release-signing keys	最高	Suspend use, assess key exposure, replace or revoke where necessary
Package and container publishing tokens	最高	Revoke, issue new scoped tokens, review published versions
Cloud deployment credentials	最高	Revoke sessions, rotate credentials, review cloud audit logs
Kubernetes credentials	最高	Replace tokens or certificates, inspect deployments and secrets
VCS write or administrator tokens	最高	Revoke, review repository and organization audit history
TeamCity administrator tokens	最高	Revoke all untrusted sessions and tokens
Artifact repository credentials	高い	Rotate and review uploads, downloads, and deletions
SSH private keys	高い	Replace keys and review authorized-key use
Database credentials	高い	Rotate and review database access
Notification webhooks	Medium to high	Rotate if they expose data or permit actions
Read-only source credentials	Context dependent	Rotate if source confidentiality matters or lateral movement is possible

TeamCity recommends storing sensitive values as password-type parameters and using external secret-management tools where possible. Password masking reduces accidental display, but it does not make a secret safe from a process that legitimately needs to retrieve or use it. (JetBrains)

Rotation must include downstream invalidation. Creating a new token without revoking the old one leaves the attacker’s copy valid.

Where short-lived workload identity is available, prefer it over permanent static credentials. A credential that expires after one build limits the value of later theft, although an attacker controlling the build during that window can still misuse it.

Decide which artifacts remain trustworthy

The hardest question may not be whether the TeamCity server was vulnerable. It may be whether software produced during the exposure window can still be trusted.

Classify artifacts by evidence.

Artifact condition	Recommended decision
Built after patch on a clean, verified platform	Normal verification
Built before patch but reproducibly rebuilt with identical output	Compare provenance and release metadata before restoring trust
Built while suspicious server activity occurred	Treat as untrusted
Signed by a key potentially accessible to the server	Signature alone is insufficient
Uploaded through a potentially compromised publication token	Verify repository history and replace if uncertain
Deployed to production during suspected compromise	Investigate deployed environment
Cannot be tied to an immutable source revision and build recipe	Rebuild
Build logs or provenance are missing	Rebuild high-value artifacts

A signature proves that someone or something with access to a signing identity authorized the artifact. If the build platform or signing identity was compromised, the signature may faithfully authenticate malicious output.

Stronger architectures keep the signing authority outside the ordinary build worker and require an independent policy decision before signing or promotion. SLSA recommends separating builds from trusted control-plane secrets, while Sigstore supports artifact and container signing workflows that can be independently verified. (SLSA)

Clean rebuild procedure

For critical releases:

1. Create a new build environment from a known-good image.
2. Patch the TeamCity server before reconnecting it.
3. Use newly issued credentials.
4. Verify the source commit and dependency locks.
5. Review build definitions against version control.
6. Use fresh build agents.
7. Disable unneeded network access.
8. Rebuild the artifact.
9. Generate new provenance.
10. Compare the new output with the previously published artifact.
11. Investigate unexplained differences.
12. Sign and publish only after independent verification.

Reproducible builds provide stronger evidence, but not every project is bit-for-bit reproducible. Timestamps, archive ordering, embedded paths, compiler nondeterminism, dependency resolution, and signing can cause benign differences. Where exact reproducibility is unavailable, compare intermediate outputs, dependency manifests, source maps, SBOMs, symbols, package contents, and runtime behavior.

TeamCity’s history changes the risk calculation

CVE-2026-63077 is not the first critical TeamCity vulnerability to place build infrastructure at risk.

CVE-2023-42793

CVE-2023-42793 was a critical authentication bypass that allowed unauthenticated attackers to perform remote code execution on TeamCity On-Premises. JetBrains fixed it in TeamCity 2023.05.4 and provided a patch plugin for older versions. (The JetBrains Blog)

The vulnerability was exploited by multiple state-sponsored groups. Microsoft observed North Korean actors Diamond Sleet and Onyx Sleet exploiting it in early October 2023. Post-exploitation activity included malware deployment, account creation, credential dumping, proxy deployment, scheduled-task persistence, and remote access. Microsoft emphasized that compromising a CI/CD environment creates a particularly serious supply-chain risk. (マイクロソフト)

CISA and partner agencies also documented exploitation by Russia’s Foreign Intelligence Service. Their advisory states that SVR actors began exploiting internet-connected TeamCity servers in late September 2023. (CISA)

The lesson is direct: TeamCity vulnerabilities are not merely theoretical CVE records. Threat actors understand the value of CI/CD systems and have used TeamCity compromise for persistence, credential access, and broader operations.

CVE-2024-27198 and CVE-2024-27199

Rapid7 disclosed two TeamCity authentication bypass vulnerabilities in March 2024.

CVE-2024-27198 was a critical alternative-path authentication bypass with a CVSS score of 9.8. Rapid7 demonstrated that it could lead to complete control of a vulnerable TeamCity server, including creating administrator users and tokens and uploading malicious plugins.

CVE-2024-27199 was a high-severity path traversal authentication bypass that allowed more limited information disclosure and system modification.

Both affected versions before TeamCity 2023.11.4. Rapid7 warned that a compromised TeamCity server gave attackers control over projects, builds, agents, and artifacts, making it a suitable platform for a supply-chain attack. (ラピッド7)

CISA added CVE-2024-27198 to its Known Exploited Vulnerabilities Catalog on March 7, 2024, only days after public disclosure. (CISA)

CVE-2026-44413

In May 2026, JetBrains disclosed CVE-2026-44413, a high-severity post-authentication TeamCity vulnerability. It could allow an authenticated user to expose parts of the TeamCity server API to unauthorized users. The flaw affected TeamCity On-Premises through 2025.11.4 and was fixed in TeamCity 2026.1. (The JetBrains Blog)

Its exploitation conditions differ from CVE-2026-63077. CVE-2026-44413 required an authenticated user, while CVE-2026-63077 requires no TeamCity credentials.

Comparison

CVE	認証	Main weakness	Potential impact	Fixed version	Known exploitation
CVE-2023-42793	なし	Authentication bypass leading to RCE	Server takeover and supply-chain access	2023.05.4	Yes, including Russian and North Korean actors
CVE-2024-27198	なし	Alternative-path authentication bypass	Complete TeamCity compromise and RCE	2023.11.4	Yes, added to CISA KEV
CVE-2024-27199	なし	Path traversal authentication bypass	Limited disclosure and configuration changes	2023.11.4	Public exploitation status less significant than CVE-2024-27198
CVE-2026-44413	Authenticated user required	Improper authorization involving API exposure	Unauthorized API access	2026.1	No equivalent public campaign established here
CVE-2026-63077	なし	Untrusted deserialization in agent polling protocol	Operating system command execution as TeamCity server process	2025.11.7 and 2026.1.3	JetBrains reported none known at publication

The historical comparison does not prove that CVE-2026-63077 is being exploited. It demonstrates that severe TeamCity flaws have repeatedly drawn rapid operational interest. Waiting for a public exploit or named threat actor gives defenders less time, not more certainty.

Hardening TeamCity after the emergency patch

Patching addresses the immediate vulnerability. Architecture determines the impact of the next one.

Remove direct internet exposure

A TeamCity login page should not be treated like a public application portal. Restrict access using:

• Private network placement
• VPN
• Identity-aware access proxy
• Source IP allowlists
• Mutual TLS where operationally appropriate
• Separate administrative and agent access paths
• Strong monitoring at the access gateway

JetBrains advises that even exposing the login screen or REST API can create entry points for newly disclosed vulnerabilities. (The JetBrains Blog)

A proxy should enforce access policy but should not become the only layer. Confirm that users cannot bypass it by reaching the TeamCity backend directly.

Separate the server from build agents

The server and build agents have different risk profiles.

Build agents execute untrusted or semi-trusted build instructions. A pull request may influence source code, tests, build scripts, dependencies, and generated files. The TeamCity server is the control plane that assigns work and stores configuration.

Running both on one host allows a malicious build to attack the control plane locally and allows a server compromise to reach build workspaces directly.

JetBrains recommends dedicated server hosts separate from build agents. (The JetBrains Blog)

Use ephemeral and isolated workers

Where possible:

• Create a clean agent for each build
• Destroy it after completion
• Prevent one build from modifying later builds
• Separate trusted release jobs from untrusted pull-request jobs
• Do not share writable caches across trust boundaries
• Do not mount the container runtime socket unnecessarily
• Do not allow build workers to access control-plane signing keys
• Restrict worker network access by job type

SLSA’s threat model highlights persistent worker state and insufficient isolation as ways one build can influence another. Clean, isolated environments make this more difficult. (SLSA)

Reduce credential concentration

Do not give every build every secret.

Use:

• Project-scoped credentials
• Environment-scoped credentials
• Short-lived cloud identities
• Short-lived registry tokens
• Protected release branches
• Manual or policy approval for production credentials
• Separate read and write identities
• Separate test and production accounts
• Secret-manager audit logs
• Automatic expiration

A pull-request test should rarely need a package publishing token, production Kubernetes credential, or code-signing identity.

Protect signing outside the ordinary worker

Signing is most valuable when compromise of the build worker does not automatically grant signing authority.

A stronger design is:

Source and build request
          |
          v
Isolated build worker
          |
          v
Unsigned artifact and provenance
          |
          v
Independent policy verification
          |
          v
Protected signing or promotion service
          |
          v
Published release

The policy layer can verify:

• Expected source repository
• Approved branch or tag
• Trusted builder identity
• Dependency policy
• Test status
• Provenance
• Artifact digest
• Required reviewers
• Environment separation

If the TeamCity server can directly invoke the signing key without an independent control, server compromise may still produce valid-looking malicious releases.

Protect and test backups

Backups should include the database, TeamCity Data Directory, and required supplementary data. They should be:

• Encrypted
• Stored outside the TeamCity host
• Protected from the TeamCity service account
• Versioned
• Monitored for deletion
• Tested through restoration exercises
• Retained long enough for incident investigation

A backup that has never been restored is an assumption, not a recovery capability.

Monitor administrative changes externally

Forward audit and security events to storage that TeamCity administrators and the TeamCity service account cannot alter.

Alert on:

• New system administrator
• New token
• Plugin installation
• Authentication change
• New VCS root
• Build template change
• Artifact destination change
• Agent authorization
• Release pipeline change
• Audit logging failure
• Log deletion or sudden volume loss

Maintain a fast security-update path

TeamCity 2024.03 and newer can automatically download security patch plugins and alert administrators about available security updates. That feature reduces discovery delay but does not replace ownership. Someone must review, approve, apply, and verify the update. (JetBrains)

A mature patch process should define:

• Named TeamCity owners
• Security advisory subscriptions
• Emergency maintenance authority
• Backup procedures
• Plugin compatibility testing
• Maximum patch windows
• Compensating controls
• Verification steps
• Incident-response escalation criteria

Use evidence-based authorized validation

A scanner that reports an old version is useful, but it does not answer every operational question. Teams also need to know whether the service is reachable from an untrusted network, whether the official patch is active, whether the server runs with excessive privileges, and whether remediation actually changed the exposure.

Organizations using an authorized platform such as 寡黙 can structure this as a controlled verification workflow: inventory approved TeamCity assets, query versions using authenticated read-only methods, verify segmentation, preserve commands and results, and repeat the checks after remediation. Such a workflow should not launch an unauthenticated RCE against a production TeamCity server.

The same distinction applies to continuous AI pentesting: automation is valuable when it connects new vulnerability intelligence to owned assets, safe validation, human approval, and evidence. It is dangerous when “validation” becomes indiscriminate exploitation. (寡黙)

A practical response checklist

Immediate actions

• Identify every TeamCity On-Premises server.
• Block unnecessary internet and partner-network access.
• Upgrade to 2025.11.7, 2026.1.3, or a newer fixed version.
• Install the official plugin only when immediate upgrade is impossible.
• Confirm the running version after restart.
• Record the remediation timestamp.
• Stop high-risk releases from exposed servers until investigation is complete.

Investigation actions

• Preserve network, proxy, host, TeamCity, and database evidence.
• Review TeamCity server child processes.
• Review outbound connections.
• Inspect new and modified files.
• Review users, roles, tokens, plugins, agents, and authentication.
• Compare build definitions with known-good configuration.
• Review releases produced during the exposure window.
• Identify every credential accessible to the server or its pipelines.

Recovery actions

• Rebuild a suspected server from a known-good image.
• Issue new TeamCity administrative credentials.
• Rotate VCS, cloud, registry, deployment, SSH, and signing credentials as required.
• Replace potentially compromised build agents.
• Rebuild high-value artifacts in a clean environment.
• Generate new provenance and signatures.
• Review downstream production systems.
• Document residual uncertainty.

Long-term actions

• Keep TeamCity private.
• Separate servers from agents.
• Use least-privilege service accounts.
• Adopt ephemeral workers.
• Separate pull-request testing from trusted release jobs.
• Move signing authority into a protected control plane.
• Deploy external audit logging.
• Exercise backup restoration.
• Continuously verify version, reachability, and privilege.

Frequently asked questions

Is TeamCity Cloud affected by CVE-2026-63077?

• JetBrains says TeamCity Cloud customers do not need to take action.
• The company applied the necessary measures to its hosted environment.
• JetBrains also said it had found no evidence that TeamCity Cloud environments were exploited through this vulnerability at the time of the advisory.
• This statement does not apply to a customer-managed TeamCity server hosted in AWS, Azure, Google Cloud, or another cloud provider. A self-managed cloud VM is still TeamCity On-Premises. (The JetBrains Blog)

Which TeamCity versions fix CVE-2026-63077?

• TeamCity 2025.11.7 fixes the vulnerability for the 2025.11 release line.
• TeamCity 2026.1.3 fixes it for the 2026.1 release line.
• Newer versions containing the fix should also be used when available.
• All earlier TeamCity On-Premises versions should be treated as affected unless the official security patch plugin has been installed and verified.
• The plugin supports TeamCity 2017.1 and newer. (The JetBrains Blog)

Can a VPN, WAF, or firewall replace the patch?

• No. These controls reduce reachability but do not remove the vulnerable code.
• A VPN account, internal workstation, build agent, partner system, or SSRF vulnerability may still provide a route to TeamCity.
• Use access restrictions as an immediate compensating control while applying the official fix.
• Keep the restrictions after patching because they reduce exposure to future pre-authentication vulnerabilities.

How can I verify exposure without running an exploit?

• Query the TeamCity version through the administrator interface or authenticated REST API.
• Confirm whether the server is older than 2025.11.7 or 2026.1.3.
• Verify the official security plugin state when an upgrade has not yet occurred.
• Review firewall, proxy, VPN, and routing data to determine which networks can reach the server.
• Confirm the operating system identity and privileges of the TeamCity server process.
• Preserve the evidence and repeat the checks after remediation.
• Do not send a deserialization payload to a production server merely to prove that the documented vulnerable version is exploitable.

What evidence could indicate TeamCity compromise?

• Unexpected shell or scripting processes started by the TeamCity Java server process
• New outbound connections from the TeamCity server
• New users, administrator roles, or tokens
• Plugin installation or unexplained plugin files
• Changes to authentication, VCS roots, build steps, templates, or artifact destinations
• Unexplained service restarts
• New scheduled tasks or services
• Modified TeamCity configuration or startup files
• Artifacts that do not match clean rebuilds
• Missing or altered logs

None of these indicators is individually conclusive. Correlate host, network, application, identity, and artifact evidence.

Which credentials should be rotated after suspected exploitation?

• TeamCity administrator passwords and tokens
• VCS access tokens and SSH keys
• Package and container registry credentials
• Cloud credentials
• Kubernetes credentials
• Deployment credentials
• Artifact repository credentials
• Database credentials
• Webhook secrets
• Code-signing and release-signing identities

Prioritize credentials that the TeamCity server process, build configuration, plugins, or connected agents could retrieve or use. Revoke old credentials rather than merely creating new ones.

Do artifacts produced before patching need to be rebuilt?

• Rebuild artifacts produced during a suspected compromise window.
• Rebuild high-value releases when available evidence cannot establish build integrity.
• A clean source repository is not sufficient because build configuration or artifact handling may have been modified outside Git.
• A signature is insufficient if the signing identity may have been accessible to the compromised pipeline.
• Use a clean builder, new credentials, reviewed configuration, and new provenance.
• Compare rebuilt outputs with previously published artifacts and investigate unexplained differences.

Is there a public exploit for CVE-2026-63077?

• JetBrains has not published an exploit.
• The vendor advisory does not disclose the complete malicious request, vulnerable class, gadget chain, or payload.
• JetBrains said it was unaware of active exploitation when it published the advisory.
• The CVE’s CISA SSVC data initially recorded exploitation as none while classifying the vulnerability as automatable with total technical impact.
• The absence of a public exploit should not delay patching. Previous TeamCity vulnerabilities were exploited quickly after disclosure. (The JetBrains Blog)

Restoring trust in the software factory

CVE-2026-63077 deserves emergency treatment because it combines four dangerous properties: network reachability, no authentication requirement, low attack complexity, and command execution inside a CI/CD control plane.

The immediate sequence is clear: restrict access, upgrade to TeamCity 2025.11.7 or 2026.1.3, or apply JetBrains’ official plugin when an immediate upgrade is impossible. Then determine whether the server was merely vulnerable or may have been compromised.

For exposed or suspicious installations, the job is not complete when the new version starts successfully. Credentials may need to be revoked, plugins and build definitions must be reviewed, agents and downstream systems must be inspected, and critical artifacts may need to be rebuilt in a clean environment.

The central security question is not only whether TeamCity is now patched. It is whether the organization can still prove that its source, build process, signing authority, published artifacts, and deployment history deserve to be trusted.