CVE-2026-104355 Overview
CVE-2026-104355 affects Temporal Server multi-cluster deployments where inbound namespace replication tasks can overwrite local namespaces that were never meant to be replicated. The sending cluster correctly excludes local namespaces from outbound replication, but the receiving cluster does not enforce the same rule. A party that controls or compromises a registered peer cluster can modify any local namespace, including the built-in temporal-system namespace, without any credential on the receiving cluster. This authorization flaw [CWE-863] enables attackers to alter namespace state, retention, archival settings, active cluster, and failover version. Clusters with no remote cluster registered with connection enabled are not exposed.
Critical Impact
An attacker controlling a registered peer cluster can mark local namespaces as Deprecated, reassign the active cluster, and shorten retention, causing new Workflow starts to fail.
Affected Products
- Temporal Server versions prior to v1.30.8
- Temporal Server versions prior to v1.31.4
- Temporal Server versions prior to v1.32.1
Discovery Timeline
- 2026-10-12 - CVE-2026-104355 published to NVD
- 2026-10-16 - Last updated in NVD database
Technical Details for CVE-2026-104355
Vulnerability Analysis
Temporal Server supports multi-cluster deployments in which each cluster pulls replication tasks from remote clusters registered with connection enabled. The sending side correctly excludes local namespaces from outbound replication. The receiving side, however, applies inbound namespace replication updates without checking whether the target namespace is global.
When an inbound replication task names an existing namespace, the receiving cluster verifies at most that the namespace identifiers match. It then overwrites namespace state, description, owner, retention policy, archival settings, and cluster list. If the task carries a higher failover version, the active cluster is also replaced. The authorization check that would prevent writes to local-only namespaces is absent.
Namespace metadata refreshed by the History service while processing history replication tasks flows through the same vulnerable logic path.
Root Cause
The root cause is an authorization gap in common/namespace/replicationTaskExecutor.go where the executor does not verify that the target namespace is marked global before applying inbound updates. Local namespaces are implicitly trusted recipients of replication state, violating the invariant that local namespaces are never replicated. This maps to [CWE-863] Incorrect Authorization.
Attack Vector
An attacker who operates or compromises a peer cluster registered with connection enabled on the victim can craft namespace replication responses that reference any local namespace by name and identifier. No credential on the receiving cluster is required. The attacker can mark the namespace Deprecated, assign the peer as the active cluster, and shorten retention. Subsequent Workflow starts in the affected namespace fail. The built-in temporal-system namespace is in scope.
// Patch: common/namespace/nsreplication/replication_task_executor.go
// Skip replication tasks that target local namespaces
tag.String("Task Namespace Info Id", task.Info.GetId()))
return false, ErrNameUUIDCollision
}
if !resp.IsGlobalNamespace {
h.logger.Warn(
"Namespace replication task skipped because namespace is local",
tag.WorkflowNamespaceID(resp.Namespace.Info.Id),
tag.WorkflowNamespace(resp.Namespace.Info.Name),
tag.String("namespace-operation", task.GetNamespaceOperation().String()),
)
return false, nil
}
return true, nil
case *serviceerror.NamespaceNotFound:
Source: Temporal Commit f2b571e
Detect Identity Attacks the Moment Authentication Fails
Singularity™ Identity surfaces credential misuse, lateral movement, and privilege escalation in real time, so you can contain the breach before it spreads.
Stop Identity AttacksDetection Methods for CVE-2026-104355
Indicators of Compromise
- Unexpected changes to local namespace state, description, retention, or archival configuration without a corresponding administrative action.
- Local namespaces, including temporal-system, showing a remote cluster as the active cluster or carrying a non-zero failover version.
- New Workflow starts failing in namespaces that were previously operational, correlated with inbound replication activity.
Detection Strategies
- Audit all namespaces for the IsGlobalNamespace flag and verify that local namespaces have not been converted or had their cluster list altered.
- Compare current namespace metadata against known-good configuration baselines stored outside the cluster.
- Review History and namespace service logs for replication task processing events referencing local namespace identifiers.
Monitoring Recommendations
- Enable the history.validateReplicationTaskSourceCluster dynamic configuration flag introduced in the patch and monitor warnings about rejected inbound tasks.
- Alert on namespace mutation events whose source is a replication task rather than an authenticated administrative API call.
- Track peer cluster registrations and connection-enabled state to maintain an authoritative inventory of trusted replication sources.
How to Mitigate CVE-2026-104355
Immediate Actions Required
- Upgrade Temporal Server to v1.30.8, v1.31.4, or v1.32.1 or later on all clusters that have remote peers registered with connection enabled.
- Review the registered remote cluster list and disable connection for any peer that is not fully trusted or operationally required.
- Validate the integrity of all local namespaces, especially temporal-system, after upgrading and restore any modified metadata from backup.
Patch Information
The fix is tracked in Temporal Pull Request #12323 with additional hardening in pull requests #12328, #12329, and #12330. The executor now checks resp.IsGlobalNamespace and skips replication tasks targeting local namespaces. A new dynamic config setting ValidateReplicationTaskSourceCluster controls whether inbound workflow replication tasks are accepted only from clusters in the namespace cluster list. Fixed releases are v1.30.8, v1.31.4, and v1.32.1.
Workarounds
- Remove or disable connection for all registered remote clusters until clusters are patched; a cluster with no remote cluster registered with connection enabled is not exposed.
- Restrict network access to the Temporal frontend replication endpoints so only trusted peer clusters can deliver inbound tasks.
- Operate single-cluster deployments where multi-cluster replication is not an operational requirement.
# After upgrading, enable strict validation of replication task source clusters
# dynamicconfig/production.yaml
history.validateReplicationTaskSourceCluster:
- value: true
constraints: {}
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

