CVE-2026-104355 in Server
Summary
by MITRE • 10/12/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/12/2026
The vulnerability described constitutes a critical logical flaw in the multi-cluster replication mechanism of Temporal Server, specifically affecting how inbound namespace metadata updates are processed by receiving clusters. In a properly secured temporal deployment, local namespaces are intended to remain isolated from remote cluster modifications to ensure operational stability and data integrity within each specific geographic or organizational boundary. However, the current implementation fails to enforce this isolation at the ingestion point for replication tasks. While the sending side correctly excludes local namespaces from outbound replication streams, the receiving side lacks a corresponding validation step to filter out inbound updates targeting these same protected entities. This asymmetry creates an attack vector where any entity controlling or compromising a registered peer cluster can manipulate the state of local namespaces on the target server without possessing direct credentials for that specific cluster.
From a technical perspective, the flaw lies in the namespace update logic within the replication handler. When an inbound task references an existing namespace identifier, the system performs only a superficial check to ensure the identifiers match before proceeding with an overwrite operation. This process indiscriminately updates critical metadata fields including description, owner information, retention policies, archival settings, and cluster membership lists. Furthermore, if the incoming update carries a higher failover version number than the current local state, the active cluster designation is also overwritten. Crucially, there is no verification to determine whether the target namespace is designated as global or local. This oversight allows an attacker to modify any existing namespace by name and identifier alone, bypassing authentication mechanisms that would normally protect such sensitive configuration changes.
The operational impact of this vulnerability is severe and potentially catastrophic for workflow reliability. An adversary can exploit this flaw to degrade service availability by marking critical namespaces as Deprecated, thereby preventing new workflow executions from starting in those environments. Additionally, the attacker can alter retention policies to shorten data storage periods, leading to potential loss of historical execution data required for debugging or compliance purposes. By changing the active cluster designation, an attacker could redirect traffic or disrupt failover mechanisms intended for high availability scenarios. The risk extends beyond user-defined namespaces; because local namespace metadata refreshes pass through the same vulnerable logic during history replication task processing, even built-in system namespaces such as temporal-system are susceptible to modification. Compromising these internal structures can destabilize the entire server instance, affecting core scheduling and execution capabilities.
This vulnerability aligns with CWE-20 Improper Input Validation, specifically regarding insufficient checks on input data before applying state changes. It also relates to CWE-693 Protection Mechanism Failure, as the system fails to protect against attacks that subvert intended security controls by exploiting logical inconsistencies in replication rules. In terms of MITRE ATT&CK, this behavior facilitates lateral movement and privilege escalation within a multi-cluster environment (T1078 Valid Accounts) and allows for impact through resource manipulation or denial of service via configuration tampering (TA0040 Impact). The attack requires the presence of at least one registered peer cluster with connection enabled, meaning clusters operating in isolation without remote connections are not exposed to this specific vector.
Mitigation strategies must focus on enforcing strict validation rules within the replication ingestion pipeline. Developers should implement a check that verifies whether an incoming namespace update targets a local namespace and reject such updates immediately if they do not originate from authorized global sources or lack appropriate administrative privileges for that specific cluster context. Additionally, implementing stricter identity verification for all metadata changes, regardless of their source, would prevent unauthorized modifications even if the replication logic is bypassed. Administrators should review registered peer connections regularly to ensure only trusted clusters are allowed to send updates and consider disabling automatic failover version overrides unless explicitly required by disaster recovery protocols. Regular auditing of namespace configurations across all clusters can help detect any unauthorized changes that may have occurred due to this flaw.