Exploitation requires that the receiving cluster has registered the attacker's cluster as a remote cluster with connection enabled, which in turn requires clusterMetadata.enableGlobalNamespace to be true, and that the attacker controls the replication task replies that cluster returns. The attacker needs no credential on the receiving cluster, because the receiving cluster initiates the connection and authenticates the peer. The privileges-required assessment treats control of a registered peer as a high privilege: a registered peer is already trusted to change the metadata of every global namespace replicated with it, including failing it over, and this issue extends that authority to the receiving cluster's local namespaces, which the peer was never granted. The attacker must supply the target namespace's name and identifier. A local namespace's identifier is never sent to the peer by replication, but the identifier is not a secret and is returned to any caller that can describe the namespace, and temporal-system has the same identifier in every deployment, so this is not scored as an attack complexity factor. Releases before 1.17.0 do not compare the identifier on the update path at all, so there the namespace name alone is sufficient.
"}],"value":"Exploitation requires that the receiving cluster has registered the attacker's cluster as a remote cluster with connection enabled, which in turn requires clusterMetadata.enableGlobalNamespace to be true, and that the attacker controls the replication task replies that cluster returns. The attacker needs no credential on the receiving cluster, because the receiving cluster initiates the connection and authenticates the peer. The privileges-required assessment treats control of a registered peer as a high privilege: a registered peer is already trusted to change the metadata of every global namespace replicated with it, including failing it over, and this issue extends that authority to the receiving cluster's local namespaces, which the peer was never granted. The attacker must supply the target namespace's name and identifier. A local namespace's identifier is never sent to the peer by replication, but the identifier is not a secret and is returned to any caller that can describe the namespace, and temporal-system has the same identifier in every deployment, so this is not scored as an attack complexity factor. Releases before 1.17.0 do not compare the identifier on the update path at all, so there the namespace name alone is sufficient."},{"lang":"en","supportingMedia":[{"base64":false,"type":"text/html","value":"On fixed releases, rejection of inbound history replication tasks for a local namespace depends on the dynamic configuration setting history.validateReplicationTaskSourceCluster, which the fix adds and which defaults to true. A fixed release with that setting changed to false still applies history replication tasks from a connected peer to a local namespace, and so can still create or delete data in it. The checks that reject namespace replication tasks and task queue user data replication tasks for a local namespace do not depend on that setting.
"}],"value":"On fixed releases, rejection of inbound history replication tasks for a local namespace depends on the dynamic configuration setting history.validateReplicationTaskSourceCluster, which the fix adds and which defaults to true. A fixed release with that setting changed to false still applies history replication tasks from a connected peer to a local namespace, and so can still create or delete data in it. The checks that reject namespace replication tasks and task queue user data replication tasks for a local namespace do not depend on that setting."},{"lang":"en","supportingMedia":[{"base64":false,"type":"text/html","value":"To determine exposure, list the remote clusters registered with connection enabled, for example with temporal operator cluster list; every local namespace on the cluster, including temporal-system, is exposed to each of them.
"}],"value":"To determine exposure, list the remote clusters registered with connection enabled, for example with temporal operator cluster list; every local namespace on the cluster, including temporal-system, is exposed to each of them."}],"credits":[{"lang":"en","type":"finder","value":"Zellic, who reported this issue responsibly to Temporal Technologies"},{"lang":"en","type":"tool","value":"V12"}],"descriptions":[{"lang":"en","supportingMedia":[{"base64":false,"type":"text/html","value":"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.
"}],"value":"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."}],"impacts":[{"descriptions":[{"lang":"en","value":"Unauthorized modification of namespace metadata on the receiving cluster by a connected replication peer, for local namespaces, which are never replicated to that peer. Demonstrated effects on a local namespace are a change of state to Deprecated, the peer recorded as the namespace's active cluster, retention reduced to one minute, and new Workflow starts in that namespace failing. No confidentiality impact was demonstrated."}]}],"metrics":[{"cvssV4_0":{"Automatable":"NOT_DEFINED","Recovery":"NOT_DEFINED","Safety":"NOT_DEFINED","attackComplexity":"LOW","attackRequirements":"NONE","attackVector":"NETWORK","baseScore":7,"baseSeverity":"HIGH","exploitMaturity":"NOT_DEFINED","privilegesRequired":"HIGH","providerUrgency":"NOT_DEFINED","subAvailabilityImpact":"NONE","subConfidentialityImpact":"NONE","subIntegrityImpact":"NONE","userInteraction":"NONE","valueDensity":"NOT_DEFINED","vectorString":"CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N","version":"4.0","vulnAvailabilityImpact":"LOW","vulnConfidentialityImpact":"NONE","vulnIntegrityImpact":"HIGH","vulnerabilityResponseEffort":"NOT_DEFINED"},"format":"CVSS","scenarios":[{"lang":"en","value":"GENERAL"}]}],"problemTypes":[{"descriptions":[{"cweId":"CWE-863","description":"CWE-863: Incorrect Authorization","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-10-12T18:43:33.846Z","orgId":"61241ed8-fa44-4f23-92db-b8c443751968","shortName":"Temporal"},"references":[{"name":"Earliest source-confirmed affected release","tags":["product"],"url":"https://github.com/temporalio/temporal/blob/v1.0.0/common/namespace/replicationTaskExecutor.go#L191-L260"},{"name":"Fix pull request","tags":["patch"],"url":"https://github.com/temporalio/temporal/pull/12323"},{"name":"Fix commit","tags":["patch"],"url":"https://github.com/temporalio/temporal/commit/f2b571e2eee8a9143fbc4711f3db8b5a37146b3b"},{"name":"Backport pull request for the 1.32 release line","tags":["patch"],"url":"https://github.com/temporalio/temporal/pull/12328"},{"name":"Backport pull request for the 1.31 release line","tags":["patch"],"url":"https://github.com/temporalio/temporal/pull/12329"},{"name":"Backport pull request for the 1.30 release line","tags":["patch"],"url":"https://github.com/temporalio/temporal/pull/12330"},{"name":"Temporal Server 1.30.8","tags":["release-notes"],"url":"https://github.com/temporalio/temporal/releases/tag/v1.30.8"},{"name":"Temporal Server 1.31.4","tags":["release-notes"],"url":"https://github.com/temporalio/temporal/releases/tag/v1.31.4"},{"name":"Temporal Server 1.32.1","tags":["release-notes"],"url":"https://github.com/temporalio/temporal/releases/tag/v1.32.1"}],"solutions":[{"lang":"en","supportingMedia":[{"base64":false,"type":"text/html","value":"Upgrade to Temporal Server 1.30.8, 1.31.4, or 1.32.1, as appropriate for the deployed minor release line, and keep the dynamic configuration setting history.validateReplicationTaskSourceCluster at its default of true. Fixed releases ignore an inbound namespace replication task, including one applied through the namespace metadata refresh that history replication can trigger, when it targets a namespace the receiving cluster stores as local, and ignore inbound task queue user data replication for a local namespace. With history.validateReplicationTaskSourceCluster enabled, fixed releases also ignore an inbound history replication task when the sending cluster is not in the namespace's cluster list, which for a local namespace is every remote cluster. The fix does not change how a connected peer can update a global namespace replicated with the receiving cluster. Fixed releases do not repair a local namespace that was already modified; review local namespaces, including temporal-system, as described in the workarounds. Temporal Server releases up to and including 1.29.7 are outside the supported window and receive no fix; operators on those releases should upgrade to a supported line.
"}],"value":"Upgrade to Temporal Server 1.30.8, 1.31.4, or 1.32.1, as appropriate for the deployed minor release line, and keep the dynamic configuration setting history.validateReplicationTaskSourceCluster at its default of true. Fixed releases ignore an inbound namespace replication task, including one applied through the namespace metadata refresh that history replication can trigger, when it targets a namespace the receiving cluster stores as local, and ignore inbound task queue user data replication for a local namespace. With history.validateReplicationTaskSourceCluster enabled, fixed releases also ignore an inbound history replication task when the sending cluster is not in the namespace's cluster list, which for a local namespace is every remote cluster. The fix does not change how a connected peer can update a global namespace replicated with the receiving cluster. Fixed releases do not repair a local namespace that was already modified; review local namespaces, including temporal-system, as described in the workarounds. Temporal Server releases up to and including 1.29.7 are outside the supported window and receive no fix; operators on those releases should upgrade to a supported line."}],"source":{"discovery":"EXTERNAL"},"title":"Temporal Server applies inbound namespace replication from a connected peer cluster to local namespaces","workarounds":[{"lang":"en","supportingMedia":[{"base64":false,"type":"text/html","value":"Until upgrading, register a remote cluster, and keep its connection enabled, only when that cluster and everyone able to control it are trusted with administrative authority over every namespace on the receiving cluster, including its local namespaces and temporal-system. Disabling the connection to a remote cluster stops the receiving cluster from pulling replication tasks from it, and also stops legitimate replication of global namespaces with that cluster. Review local namespaces, including temporal-system, for a cluster list or active cluster other than the current cluster.
"}],"value":"Until upgrading, register a remote cluster, and keep its connection enabled, only when that cluster and everyone able to control it are trusted with administrative authority over every namespace on the receiving cluster, including its local namespaces and temporal-system. Disabling the connection to a remote cluster stops the receiving cluster from pulling replication tasks from it, and also stops legitimate replication of global namespaces with that cluster. Review local namespaces, including temporal-system, for a cluster list or active cluster other than the current cluster."}]}},"cveMetadata":{"assignerOrgId":"61241ed8-fa44-4f23-92db-b8c443751968","assignerShortName":"Temporal","cveId":"CVE-2026-104355","datePublished":"2026-10-12T18:43:33.846Z","dateReserved":"2026-10-01T20:45:19.047Z","dateUpdated":"2026-10-12T18:43:33.846Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-10-12 19:16:36","lastModifiedDate":"2026-10-12 19:16:36","problem_types":["CWE-863","CWE-863 CWE-863: Incorrect Authorization"],"metrics":{"cvssMetricV40":[{"source":"security@temporal.io","type":"Secondary","cvssData":{"version":"4.0","vectorString":"CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","baseScore":7,"baseSeverity":"HIGH","attackVector":"NETWORK","attackComplexity":"LOW","attackRequirements":"NONE","privilegesRequired":"HIGH","userInteraction":"NONE","vulnConfidentialityImpact":"NONE","vulnIntegrityImpact":"HIGH","vulnAvailabilityImpact":"LOW","subConfidentialityImpact":"NONE","subIntegrityImpact":"NONE","subAvailabilityImpact":"NONE","exploitMaturity":"NOT_DEFINED","confidentialityRequirement":"NOT_DEFINED","integrityRequirement":"NOT_DEFINED","availabilityRequirement":"NOT_DEFINED","modifiedAttackVector":"NOT_DEFINED","modifiedAttackComplexity":"NOT_DEFINED","modifiedAttackRequirements":"NOT_DEFINED","modifiedPrivilegesRequired":"NOT_DEFINED","modifiedUserInteraction":"NOT_DEFINED","modifiedVulnConfidentialityImpact":"NOT_DEFINED","modifiedVulnIntegrityImpact":"NOT_DEFINED","modifiedVulnAvailabilityImpact":"NOT_DEFINED","modifiedSubConfidentialityImpact":"NOT_DEFINED","modifiedSubIntegrityImpact":"NOT_DEFINED","modifiedSubAvailabilityImpact":"NOT_DEFINED","Safety":"NOT_DEFINED","Automatable":"NOT_DEFINED","Recovery":"NOT_DEFINED","valueDensity":"NOT_DEFINED","vulnerabilityResponseEffort":"NOT_DEFINED","providerUrgency":"NOT_DEFINED"}}]},"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"104355","Ordinal":"1","Title":"Temporal Server applies inbound namespace replication from a con","CVE":"CVE-2026-104355","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"104355","Ordinal":"1","NoteData":"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.","Type":"Description","Title":"Temporal Server applies inbound namespace replication from a con"}]}}}