TeamCity CVE-2026-63077 Fix: 2026 Enterprise Emergency Upgrade Guide

The first action is not an upgrade command. It is to reduce the attacker’s available paths while preserving evidence.

For an unpatched TeamCity On-Premises server, the security team should restrict public access at the reverse proxy, firewall, VPN, or identity gateway. Keep only the administration and build traffic that is required for the recovery team. Do not assume that an allowlist is enough if the server remains reachable through an overlooked hostname, port, load balancer, or remote administration path.

TeamCity Cloud has a different operational boundary. The vendor states that users do not need to perform this specific server-side fix there. That does not remove the need to review Agents, credentials, artifacts, or organization-level access if suspicious activity has already been observed.

The emergency order should be:

• Restrict inbound access to the TeamCity server.
• Freeze non-essential administrator and project configuration changes.
• Pause production signing and release jobs.
• Preserve TeamCity logs, reverse-proxy logs, audit records, and relevant host snapshots.
• Record the server version, database type, Java runtime, plugin inventory, Agent list, and current queue state.
• Notify the owners of VCS, artifact storage, cloud access, deployment, Apple Developer, and signing systems.

The patch blocks further exploitation of the vulnerable condition. It does not answer whether an attacker already changed configuration, created an Agent, accessed secrets, or influenced a build.

Separate the recovery objects

A TeamCity server, a Mac Build Agent, a build workspace, a signing node, and a downstream artifact repository are different trust zones. Combining them into one “CI environment” makes the investigation harder.

The server controls projects, queues, permissions, connections, and Agent authorization. An Agent executes code and may contain source checkouts, dependency caches, environment variables, certificates, and Keychains. A workspace can contain generated scripts or modified files. A signing node adds a higher-value credential boundary. An artifact repository may preserve outputs that were created before the investigation began.

A clean server does not automatically make an old Mac Agent clean. Likewise, an Agent that reconnects successfully does not prove that its workspace, local users, launch agents, certificates, or signing Keychain were untouched.

The TeamCity CVE-2026-63077 fix should be selected from the current server version, license position, maintenance window, database compatibility, Java requirement, and plugin dependency map. The newest release is not automatically the safest emergency target.

The vendor has confirmed that 2025.11.7 and 2026.1.3 contain the fix. TeamCity 2026.2 was released on September 1, 2026, but an upgrade into that line requires a separate compatibility review. The TeamCity 2026.2 release notes should be checked before selecting it as the target.

A standard backup is not a complete evidence package. It may protect the database and TeamCity Data Directory, but the recovery team also needs to decide whether it has preserved reverse-proxy records, operating-system logs, access-control events, plugin files, Agent-side logs, workspace contents, build metadata, and artifact provenance. The exact scope depends on the deployment and retention policy.

Before the maintenance window, create an inventory that includes:

• TeamCity server version and installation path.
• Database engine, driver, connection method, and backup status.
• Java runtime and service account.
• Plugins, versions, custom integrations, and authentication providers.
• Agent names, authorization state, operating system, server URL, and host owner.
• VCS roots, artifact connections, cloud credentials, deployment secrets, and signing material.
• Build configurations that can publish, deploy, or sign.

The official server and Agent upgrade documentation should be used to validate the upgrade sequence rather than relying on a generic package replacement procedure.

A controlled upgrade should move through explicit gates. The purpose is to prevent a server restart from being mistaken for a security validation.

1. Freeze changes and capture the baseline

Export the current version, service status, queue state, administrator list, Agent list, plugin list, and active integrations. Preserve logs before rotating or deleting anything. Record the time of isolation and the people approving each action.

2. Confirm backups before stopping services

Verify that the database backup can be read or restored in a test location. Confirm that the Data Directory copy is complete and that configuration files, encryption-related material, and required build records are included according to the organization’s recovery design.

3. Stop the TeamCity server cleanly

Stop the service through the organization’s normal service-management method. Avoid ad hoc file deletion or forced termination unless the incident plan requires it. A clean stop preserves a clearer boundary between pre-upgrade and post-upgrade activity.

4. Install the selected fixed release or official mitigation

Apply the supported target selected during planning. If the official security patch plugin is used because an immediate upgrade is not possible, document the exception, owner, expiry condition, and planned upgrade date. Do not extend the mitigation indefinitely because builds appear to work.

5. Start the server and verify the version

Check the displayed server version, service logs, database connection, administrator access, plugin loading, and security patch state. Verify that the server is no longer presenting the vulnerable state identified by the vendor.

6. Test integrations without releasing production work

Validate a non-production VCS connection, a controlled queue operation, and a test project. Check that authentication failures are not being hidden by cached credentials. Keep production signing and deployment disabled until the investigation and credential review are complete.

7. Confirm the network boundary

Review firewall, reverse-proxy, VPN, DNS, and load-balancer rules. A repaired application remains exposed if an old public route still reaches the host. Record the final reachable interfaces and the administrator access path.

If the chosen upgrade enters the 2026.1 or 2026.2 line, verify Java and database prerequisites before enabling production traffic. TeamCity provides a dedicated Java 21 compatibility page; the runtime requirement must be checked against the existing service definition, plugins, database drivers, and operating-system package rather than inferred from the server’s current shell environment.

Operational warning: Do not force-restart Mac Agents during automatic Agent upgrade activity. Let the Agent upgrade complete, then inspect its state and reconnect behavior. An abrupt restart can create a separate upgrade failure and obscure the original investigation.

The recovery decision for a Mac Agent must be made per host. A server-side patch does not authorize every existing macOS node.

Disable production routing first. Then verify the following attributes for each Agent:

• Agent name and expected owner.
• Physical or virtual host identity.
• Authorization and approval state.
• Configured TeamCity server URL.
• Operating-system account and service startup method.
• Agent version and automatic upgrade result.
• Xcode, SDK, dependency manager, and build-tool inventory.
• Local workspace, caches, certificates, profiles, and signing Keychain.
• Recent build history and projects assigned to the node.

The TeamCity Agent status and authorization documentation can help administrators confirm the server-side state. The macOS startup behavior should also be compared with the official macOS Agent guidance, especially where the deployment uses custom launch services or a non-default service account.

An unknown Agent, an unexpected authorization request, or a host that cannot be tied to an approved owner is an investigation lead. It is not, by itself, proof of exploitation. Do not authorize it to “see whether it works.” Isolate the host, preserve its logs and disk state according to the incident process, and compare it with the approved Agent inventory.

The first test pipeline should be unsigned and non-production. It should cover:

• Repository checkout from the expected VCS connection.
• Xcode and SDK discovery.
• Dependency retrieval from approved sources.
• Compilation and test execution.
• Archive generation without release signing.
• Workspace cleanup and repeat execution.
• Artifact upload to a controlled test location.

The test should run on a clean or rebuilt node before an old node is returned to the production queue. A successful build proves that the selected workflow can execute. It does not prove that a previous workspace or credential store was trustworthy.

Investigation should correlate evidence across systems instead of searching for one decisive log line. The official security material provides clues for reviewing suspicious activity and unauthorized Agents, but a single unusual record cannot independently establish compromise.

Create an investigation table with these columns:

• Timestamp and timezone.
• System and host.
• Actor, service account, or Agent identity.
• Observed action.
• Related project, build, or credential.
• Evidence location and retention status.
• Classification: confirmed, suspicious, or unexplained.
• Owner and next action.

Review the TeamCity server, reverse proxy, identity provider, operating system, VCS, artifact repository, cloud account, deployment system, and Mac Agent records using a shared timeline. Pay particular attention to changes that occurred during the period when the server was externally reachable, but do not convert timing alone into a breach conclusion.

Credential rotation should follow ownership and blast radius:

• VCS access tokens and deploy keys.
• Artifact repository users, tokens, and publishing credentials.
• Cloud access keys and temporary role assumptions.
• Deployment and infrastructure secrets.
• Apple Developer credentials and App Store Connect access.
• Certificates, provisioning profiles, and signing identities.
• macOS Keychains used by signing nodes.
• TeamCity administration and integration credentials.

Rotate credentials from a trusted administrative environment. Revoke old values rather than merely adding new ones. Update the secret store and build configurations, then record which pipelines were tested with the replacement material.

Build artifacts created during the exposure window need provenance review. Check the source revision, build configuration, Agent identity, dependency inputs, signing event, artifact hash, publication destination, and downstream consumption. If the evidence is incomplete, quarantine the artifact and rebuild it on a trusted node.

A clean recovery environment should start with the minimum required production configuration. Avoid copying an entire old Mac workspace, cache directory, local shell profile, or signing Keychain into the replacement node without review.

The restoration sequence should be:

1. Prepare the isolated Mac node and confirm its host ownership.
2. Install the approved macOS, Xcode, SDK, dependency, and TeamCity Agent configuration.
3. Connect the Agent to the repaired server without enabling production routing.
4. Pull source from the approved VCS path.
5. Resolve dependencies from approved repositories.
6. Build and run tests without signing.
7. Generate an archive and verify its metadata.
8. Enable controlled signing only after credential rotation is complete.
9. Publish to a test or restricted artifact destination.
10. Compare the output and logs with the expected release process.
11. Approve limited production routing.
12. Monitor the first production jobs and retain their evidence.

The release gate should have five explicit conclusions:

• Server fixed: the selected TeamCity version or official mitigation is confirmed.
• Credentials rotated: affected or potentially exposed secrets are revoked and replaced.
• Artifacts traceable: outputs from the exposure window are reviewed, quarantined, or rebuilt.
• Agents recoverable: each restored Mac Agent has a known identity, approved route, and repeatable test result.
• Rollback available: the team can remove a suspect Agent or return to a controlled queue without restoring unreviewed state.

Teams without a spare Mac node should not use the only production signing host as the investigation environment. A short-term isolated Mac environment can provide a place to rebuild an Agent, rerun critical pipelines, and preserve the original node for evidence. Before arranging that environment, the team can use the NUKCLOUD remote Mac access page to review the available remote workflow, then evaluate a suitable remote Mac ordering option only if temporary capacity fits the organization’s security and procurement rules.

Which TeamCity version should an enterprise upgrade to?

Use a supported fixed release that matches the current branch and dependency constraints. The official update identifies 2025.11.7 and 2026.1.3 as fixed versions. TeamCity 2026.2 is a newer release, but a direct upgrade should wait until Java, database, plugin, and upgrade-note checks are complete.

What should be checked after the security patch?

Verify the version, patch state, administrator access, database connection, VCS integrations, queue behavior, plugins, and Agent authorization. Preserve logs before cleanup. Also check whether old public routes remain open and whether any production job can still use credentials that have not been reviewed.

How can the team assess possible exploitation?

Start with the official investigation clues, then correlate TeamCity, proxy, identity, operating-system, VCS, artifact, and Agent records. Unexpected administrator actions or unknown Agents deserve isolation and review. They are indicators, not standalone proof. The result should classify each finding as confirmed, suspicious, or unexplained.

How should a Mac Build Agent return to service?

Disable production routing, verify identity and authorization, inspect the server URL and upgrade status, and run an unsigned test pipeline on a clean or rebuilt environment. Test checkout, Xcode, dependencies, workspace cleanup, and archive generation. Restore signing only after the node and its credentials have passed separate review.

Which CI/CD credentials require rotation?

Review VCS, artifact, cloud, deployment, Apple Developer, certificate, provisioning-profile, and signing-Keychain credentials. Rotate according to ownership and possible access, revoke old values, and rebuild artifacts that cannot be traced to a trusted Agent and source revision.

The TeamCity CVE-2026-63077 fix is only one control in the recovery chain. An organization should reopen production signing only after the server is repaired, the exposure path is restricted, evidence is preserved, Mac Agents are individually assessed, credentials are rotated where required, and a trusted pipeline produces traceable output.

Compared with maintaining a single permanent Mac build host, a temporary rented Mac environment can provide an isolated place to rebuild an Agent and rerun critical jobs when the existing node must remain available for investigation. The trade-offs are real: the team must validate remote access controls, network routing, data handling, and procurement approval, and a rented node is not a substitute for a long-term dedicated signing architecture or a requirement for direct physical interfaces. For a short recovery window or a missing standby node, however, NUKCLOUD can be evaluated as a way to separate clean validation from the suspect production host.