CVE-2026-104355: Temporal Server applies inbound namespace replication from a connected peer cluster to local namespaces
A connected peer cluster can modify a Temporal Server cluster's local namespaces, which are never replicated to that peer, because the receiving cluster applies inbound namespace replication updates to them. In a multi-cluster deployment, each cluster pulls replication tasks from the remote clusters an administrator has registered with connection enabled; the sending side excludes local namespaces, but the receiving side does not apply the same rule. When an inbound task names an existing namespace, the server checks at most that the namespace identifiers match, then overwrites its state, description, owner, retention, archival settings, and cluster list, and its active cluster when the task carries a higher failover version, without checking that the namespace is global. A party that controls a registered peer's replies, by operating or compromising it, can therefore change any local namespace whose name and identifier it can supply, without any credential on the receiving cluster: for example, marking it Deprecated, making the peer its active cluster, and shortening its retention, after which new Workflow starts in that namespace fail. Local namespaces include the built-in temporal-system namespace. Namespace metadata the History service refreshes from the peer while processing its history replication tasks passes through the same logic. A cluster with no remote cluster registered with connection enabled is not exposed.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Temporal Serverto a version that resolves this vulnerability.Fixed in 1.30.8 - Upgrade
Upgrade
Temporal Serverto a version that resolves this vulnerability.Fixed in 1.31.4 - Upgrade
Upgrade
Temporal Serverto a version that resolves this vulnerability.Fixed in 1.32.1 - Configuration
Keep the dynamic configuration setting history.validateReplicationTaskSourceCluster at its default of true.
Temporal Server history.validateReplicationTaskSourceCluster = true - Operational
Review local namespaces for prior modification, including the built-in temporal-system namespace, because fixed releases do not repair an already modified local namespace.
Event History
Frequently Asked Questions
Which deployments are exposed?
The issue affects multi-cluster deployments where a cluster has a remote peer registered with connection enabled and pulls replication tasks from that peer. A standalone deployment or a deployment without such a connected peer is not described as exposed.
What does an attacker need to exploit this?
An attacker must operate or compromise a registered peer cluster and control its replication replies. They do not need credentials on the receiving cluster, but must be able to provide the target local namespace's name and identifier.
What impact can a malicious peer have on local namespaces?
It can overwrite namespace state, description, owner, retention, archival settings, and cluster membership. It can also make the peer the active cluster when it supplies a higher failover version; marking a namespace Deprecated or shortening retention can cause new Workflow starts in that namespace to fail.
How can an administrator identify potentially affected namespaces?
Review local namespaces on clusters connected to registered peers for unexpected changes to their state, description, owner, retention or archival settings, cluster list, or active cluster. The described condition applies where an inbound replication task names an existing local namespace with matching identifiers.