{"dataType": "CVE_RECORD", "dataVersion": "5.2", "cveMetadata": {"cveId": "CVE-2026-87858", "assignerOrgId": "61241ed8-fa44-4f23-92db-b8c443751968", "state": "PUBLISHED", "assignerShortName": "Temporal", "dateReserved": "2026-09-09T13:05:43.884Z", "datePublished": "2026-09-21T11:39:52.412Z", "dateUpdated": "2026-09-21T11:39:52.412Z"}, "containers": {"cna": {"providerMetadata": {"orgId": "61241ed8-fa44-4f23-92db-b8c443751968", "shortName": "Temporal", "dateUpdated": "2026-09-21T11:39:52.412Z"}, "title": "Temporal Server completion callback source header can direct attacker-chosen requests to the internal frontend with administrator authorization", "problemTypes": [{"descriptions": [{"lang": "en", "cweId": "CWE-807", "description": "CWE-807: Reliance on Untrusted Inputs in a Security Decision", "type": "CWE"}]}], "impacts": [{"descriptions": [{"lang": "en", "value": "Privilege escalation from a single-namespace caller to cluster administrator, resulting in unauthorized state-changing operations against any namespace in the cluster. Confirmed effects include terminating another namespace's Workflows, registering namespaces, modifying another namespace's configuration, and deleting another namespace together with its Workflows. No confidentiality impact was identified; the request path is write-only and response bodies are discarded."}]}], "affected": [{"vendor": "Temporal Technologies, Inc.", "product": "Temporal Server", "collectionURL": "https://pkg.go.dev", "packageName": "go.temporal.io/server", "repo": "https://github.com/temporalio/temporal", "modules": ["History", "Frontend"], "programFiles": ["components/callbacks/request.go", "chasm/lib/callback/request.go", "service/frontend/workflow_handler.go", "common/authorization/claim_mapper.go"], "programRoutines": [{"name": "routeRequest"}, {"name": "validateWorkflowCompletionCallbacks"}, {"name": "validateCallbackURL"}, {"name": "internalClaimMapper.GetClaims"}], "versions": [{"status": "affected", "version": "1.30.0", "lessThan": "1.30.7", "versionType": "semver"}, {"status": "affected", "version": "1.31.0", "lessThan": "1.31.3", "versionType": "semver"}], "defaultStatus": "unaffected", "cpes": ["cpe:2.3:a:temporal:temporal:*:*:*:*:*:*:*:*"]}, {"vendor": "Temporal Technologies, Inc.", "product": "Temporal Server", "collectionURL": "https://pkg.go.dev", "packageName": "go.temporal.io/server", "repo": "https://github.com/temporalio/temporal", "modules": ["History", "Frontend"], "programFiles": ["components/callbacks/fx.go", "service/frontend/workflow_handler.go", "common/authorization/claim_mapper.go"], "programRoutines": [{"name": "HTTPCallerProviderProvider"}, {"name": "validateWorkflowCompletionCallbacks"}, {"name": "validateCallbackURL"}, {"name": "internalClaimMapper.GetClaims"}], "versions": [{"status": "affected", "version": "1.25.0", "lessThanOrEqual": "1.29.7", "versionType": "semver"}], "defaultStatus": "unaffected", "cpes": ["cpe:2.3:a:temporal:temporal:*:*:*:*:*:*:*:*"]}], "descriptions": [{"lang": "en", "value": "Temporal Server decided whether a Workflow completion callback was internal by reading a caller-supplied HTTP header. An authenticated caller holding only write permission in a single namespace could attach a completion callback whose URL host matched the configured callback address allowlist, whose URL path was any Temporal HTTP API route, and whose header map contained a non-empty header named source. When the History service delivered that callback, the non-empty source header caused it to re-target the request at the local frontend client and rewrite only the scheme and host, preserving the caller's path, query, and request body. Where an internal frontend is deployed with its HTTP API enabled, that client resolves to the internal frontend, which authorizes every request as a system administrator without requiring authentication information. The result is that the server performs an attacker-chosen state-changing HTTP POST against its own administrative API on the caller's behalf, in namespaces where the caller has no permission. The caller never needs network access to the internal frontend, because the History service makes the request. Confirmed effects include terminating Workflows in other namespaces, registering namespaces, modifying another namespace's configuration, and deleting another namespace and its Workflows. The affected routing logic is present in both the HSM and CHASM callback delivery implementations. This description and the CVSS score in this record describe releases 1.30.0 and later, where any non-empty source header is sufficient. Releases 1.25.0 through 1.29.7 are affected by a narrower form of the same defect in which the header must exactly match a configured cluster ID, a UUID that a namespace-scoped caller cannot read through the API. The consequence once that match occurs is the same, but the attack is materially harder and scores lower. To determine whether a deployment is affected, check two settings together: the static Server configuration for a non-zero services.internal-frontend.rpc.httpPort, and the effective per-namespace dynamic configuration value of component.callbacks.allowedAddresses. A deployment is exposed only when an internal frontend is deployed with a non-zero HTTP port, at least one allowlist rule admits a host, and authorization is enabled. The allowlist is empty by default, which denies all external callback URLs, and the stock static topology does not include an internal frontend. Note that a failed attach returns the error 'invalid url: url does not match any configured callback address', which proves only that one tested URL did not match and does not prove the effective allowlist is empty. To look for callbacks already attached, use DescribeWorkflowExecution, which returns callback information for a Workflow's registered completion callbacks. Operators should be aware of a gap when searching for evidence of delivery: the frontend HTTP API server records the request method and URL at debug level only, so at default log levels a delivered request is not written to the internal frontend's logs, and the absence of such log entries is not evidence that the issue was not exploited.", "supportingMedia": [{"type": "text/html", "base64": false, "value": "<p>Temporal Server decided whether a Workflow completion callback was internal by reading a caller-supplied HTTP header. An authenticated caller holding only write permission in a single namespace could attach a completion callback whose URL host matched the configured callback address allowlist, whose URL path was any Temporal HTTP API route, and whose header map contained a non-empty header named source. When the History service delivered that callback, the non-empty source header caused it to re-target the request at the local frontend client and rewrite only the scheme and host, preserving the caller's path, query, and request body. Where an internal frontend is deployed with its HTTP API enabled, that client resolves to the internal frontend, which authorizes every request as a system administrator without requiring authentication information. The result is that the server performs an attacker-chosen state-changing HTTP POST against its own administrative API on the caller's behalf, in namespaces where the caller has no permission. The caller never needs network access to the internal frontend, because the History service makes the request. Confirmed effects include terminating Workflows in other namespaces, registering namespaces, modifying another namespace's configuration, and deleting another namespace and its Workflows. The affected routing logic is present in both the HSM and CHASM callback delivery implementations. This description and the CVSS score in this record describe releases 1.30.0 and later, where any non-empty source header is sufficient. Releases 1.25.0 through 1.29.7 are affected by a narrower form of the same defect in which the header must exactly match a configured cluster ID, a UUID that a namespace-scoped caller cannot read through the API. The consequence once that match occurs is the same, but the attack is materially harder and scores lower. To determine whether a deployment is affected, check two settings together: the static Server configuration for a non-zero services.internal-frontend.rpc.httpPort, and the effective per-namespace dynamic configuration value of component.callbacks.allowedAddresses. A deployment is exposed only when an internal frontend is deployed with a non-zero HTTP port, at least one allowlist rule admits a host, and authorization is enabled. The allowlist is empty by default, which denies all external callback URLs, and the stock static topology does not include an internal frontend. Note that a failed attach returns the error 'invalid url: url does not match any configured callback address', which proves only that one tested URL did not match and does not prove the effective allowlist is empty. To look for callbacks already attached, use DescribeWorkflowExecution, which returns callback information for a Workflow's registered completion callbacks. Operators should be aware of a gap when searching for evidence of delivery: the frontend HTTP API server records the request method and URL at debug level only, so at default log levels a delivered request is not written to the internal frontend's logs, and the absence of such log entries is not evidence that the issue was not exploited.</p>"}]}], "references": [{"url": "https://github.com/temporalio/temporal/pull/11965", "name": "Fix pull request", "tags": ["patch"]}, {"url": "https://github.com/temporalio/temporal/pull/11982", "name": "1.31 backport, adds the callback.inspectSourceHeader toggle defaulted to true", "tags": ["patch"]}, {"url": "https://github.com/temporalio/temporal/pull/12085", "name": "1.30 backport, adds the callback.inspectSourceHeader toggle defaulted to true", "tags": ["patch"]}, {"url": "https://github.com/temporalio/temporal/releases/tag/v1.30.7", "name": "Temporal Server 1.30.7", "tags": ["release-notes"]}, {"url": "https://github.com/temporalio/temporal/releases/tag/v1.31.3", "name": "Temporal Server 1.31.3", "tags": ["release-notes"]}, {"url": "https://github.com/temporalio/temporal/releases/tag/v1.32.0", "name": "Temporal Server 1.32.0", "tags": ["release-notes"]}], "metrics": [{"format": "CVSS", "scenarios": [{"lang": "en", "value": "GENERAL"}], "cvssV4_0": {"attackVector": "NETWORK", "attackComplexity": "LOW", "attackRequirements": "NONE", "privilegesRequired": "LOW", "userInteraction": "NONE", "vulnConfidentialityImpact": "NONE", "subConfidentialityImpact": "NONE", "vulnIntegrityImpact": "HIGH", "subIntegrityImpact": "NONE", "vulnAvailabilityImpact": "HIGH", "subAvailabilityImpact": "NONE", "exploitMaturity": "NOT_DEFINED", "Safety": "NOT_DEFINED", "Automatable": "NOT_DEFINED", "Recovery": "NOT_DEFINED", "valueDensity": "NOT_DEFINED", "vulnerabilityResponseEffort": "NOT_DEFINED", "providerUrgency": "NOT_DEFINED", "version": "4.0", "baseSeverity": "HIGH", "baseScore": 7.2, "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N"}}], "configurations": [{"lang": "en", "value": "Exploitation requires all of the following at once. Authorization must be enabled through a configured authorizer and claim mapper; without it every caller already holds administrative rights and there is no boundary to cross. The caller must be able to call StartWorkflowExecution in some namespace. An internal frontend must be deployed with services.internal-frontend.rpc.httpPort set to a non-zero value; the stock static topology contains no internal frontend, and an omitted or zero port disables its HTTP API. At least one rule in the effective per-namespace component.callbacks.allowedAddresses value must admit the supplied URL host; the code default is an empty rule set, which denies all external callback URLs. In the bundled config/docker.yaml template, setting USE_INTERNAL_FRONTEND also defaults INTERNAL_FRONTEND_HTTP_PORT to 7246, so opting into the internal frontend in that template also enables its HTTP API unless the rendered port is explicitly zero. Only the URL host is matched against the allowlist; the path and query are never validated, and the allowlist is not consulted again when the request is re-targeted internally.", "supportingMedia": [{"type": "text/html", "base64": false, "value": "<p>Exploitation requires all of the following at once. Authorization must be enabled through a configured authorizer and claim mapper; without it every caller already holds administrative rights and there is no boundary to cross. The caller must be able to call StartWorkflowExecution in some namespace. An internal frontend must be deployed with services.internal-frontend.rpc.httpPort set to a non-zero value; the stock static topology contains no internal frontend, and an omitted or zero port disables its HTTP API. At least one rule in the effective per-namespace component.callbacks.allowedAddresses value must admit the supplied URL host; the code default is an empty rule set, which denies all external callback URLs. In the bundled config/docker.yaml template, setting USE_INTERNAL_FRONTEND also defaults INTERNAL_FRONTEND_HTTP_PORT to 7246, so opting into the internal frontend in that template also enables its HTTP API unless the rendered port is explicitly zero. Only the URL host is matched against the allowlist; the path and query are never validated, and the allowlist is not consulted again when the request is re-targeted internally.</p>"}]}, {"lang": "en", "value": "Releases 1.25.0 through 1.29.7 are affected by a narrower form of the same defect and are listed as a separate affected entry above. In those releases the delivery path routes a callback internally only when the caller-supplied source header exactly matches a configured cluster ID, and an unrecognized value falls back to the external client rather than the local one. When that match does occur the request is re-targeted the same way, rewriting only the scheme and host while preserving the caller's path and query, so the outcome is identical once the precondition is met. The same requirement for an internal frontend with a non-zero rpc.httpPort applies. A cluster ID is a UUID: if the configured value is not a valid UUID the server generates a random one at startup, and reading it through GetClusterInfo requires a cluster-scoped read role that a namespace-scoped caller does not hold. Beginning in 1.30.0 the exact-match requirement was removed and any non-empty source header routes internally, which is why the two ranges are described separately. No fix is planned for 1.25 through 1.29; those releases fall outside the supported window, which covers the last three minor versions. Falling outside that window is a statement about support, not a statement that those releases are unaffected.", "supportingMedia": [{"type": "text/html", "base64": false, "value": "<p>Releases 1.25.0 through 1.29.7 are affected by a narrower form of the same defect and are listed as a separate affected entry above. In those releases the delivery path routes a callback internally only when the caller-supplied source header exactly matches a configured cluster ID, and an unrecognized value falls back to the external client rather than the local one. When that match does occur the request is re-targeted the same way, rewriting only the scheme and host while preserving the caller's path and query, so the outcome is identical once the precondition is met. The same requirement for an internal frontend with a non-zero rpc.httpPort applies. A cluster ID is a UUID: if the configured value is not a valid UUID the server generates a random one at startup, and reading it through GetClusterInfo requires a cluster-scoped read role that a namespace-scoped caller does not hold. Beginning in 1.30.0 the exact-match requirement was removed and any non-empty source header routes internally, which is why the two ranges are described separately. No fix is planned for 1.25 through 1.29; those releases fall outside the supported window, which covers the last three minor versions. Falling outside that window is a statement about support, not a statement that those releases are unaffected.</p>"}]}, {"lang": "en", "value": "The CVSS score in this record describes the worst case, which is releases 1.30.0 and later where any non-empty source header is sufficient. It does not apply uniformly to every listed version. For releases 1.25.0 through 1.29.7 the attacker must additionally supply an exact cluster ID UUID that a namespace-scoped caller cannot read through the API, which raises Attack Complexity to High and yields CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N, 6.1 Medium.", "supportingMedia": [{"type": "text/html", "base64": false, "value": "<p>The CVSS score in this record describes the worst case, which is releases 1.30.0 and later where any non-empty source header is sufficient. It does not apply uniformly to every listed version. For releases 1.25.0 through 1.29.7 the attacker must additionally supply an exact cluster ID UUID that a namespace-scoped caller cannot read through the API, which raises Attack Complexity to High and yields CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N, 6.1 Medium.</p>"}]}], "workarounds": [{"lang": "en", "value": "Until a fixed release is available, a cluster that does not accept externally addressed Workflow completion callbacks can set the effective component.callbacks.allowedAddresses dynamic configuration value to an empty list, and remove or empty any more specific namespace-constrained entries that admit a host. Verify the effective value for every namespace in scope. An absent key already has the same deny-all default, but an explicit empty value is easier to audit. This rejects external http and https callback URLs at StartWorkflowExecution, before persistence and before either delivery implementation runs. It is a targeted mitigation rather than a way to disable Nexus: the reserved internal forms temporal://system and temporal://internal remain admitted, and there is no supported cluster-wide setting that turns Nexus off. As a separate defense in depth, operators that do not need the internal frontend's HTTP API can remove that service or set services.internal-frontend.rpc.httpPort to zero after confirming no internal consumers depend on it; this closes the administrative amplifier but does not correct the routing defect itself. Restricting or removing Nexus endpoints is not sufficient, because attaching the affected completion callback does not require a registered Nexus endpoint.", "supportingMedia": [{"type": "text/html", "base64": false, "value": "<p>Until a fixed release is available, a cluster that does not accept externally addressed Workflow completion callbacks can set the effective component.callbacks.allowedAddresses dynamic configuration value to an empty list, and remove or empty any more specific namespace-constrained entries that admit a host. Verify the effective value for every namespace in scope. An absent key already has the same deny-all default, but an explicit empty value is easier to audit. This rejects external http and https callback URLs at StartWorkflowExecution, before persistence and before either delivery implementation runs. It is a targeted mitigation rather than a way to disable Nexus: the reserved internal forms temporal://system and temporal://internal remain admitted, and there is no supported cluster-wide setting that turns Nexus off. As a separate defense in depth, operators that do not need the internal frontend's HTTP API can remove that service or set services.internal-frontend.rpc.httpPort to zero after confirming no internal consumers depend on it; this closes the administrative amplifier but does not correct the routing defect itself. Restricting or removing Nexus endpoints is not sufficient, because attaching the affected completion callback does not require a registered Nexus endpoint.</p>"}]}], "solutions": [{"lang": "en", "value": "Upgrade to Temporal Server 1.32.0, which ships callback.inspectSourceHeader set to false and needs no further change. The fix makes the completion-callback source header opt-in behind the callback.inspectSourceHeader setting, so a callback's internality is decided from the server-generated callback URL rather than from a caller-supplied header. Releases 1.30.7 and 1.31.3 carry the same code but ship callback.inspectSourceHeader set to true for mixed-version compatibility while callbacks created with the older callback URL template drain, and while it is true the routing behavior matches the affected releases; an operator upgrading within the 1.30 or 1.31 line must therefore also set callback.inspectSourceHeader to false once every pre-fix server has drained. Operators who set callback.inspectSourceHeader to true restore the pre-fix behavior in full, including preservation of the caller's path and query across the internal rewrite, and should not enable it on a cluster that accepts caller-supplied completion callbacks. Temporal Server releases in the 1.25.0 through 1.29.7 range are outside the supported window and receive no fix; operators on those releases should upgrade to a supported line.", "supportingMedia": [{"type": "text/html", "base64": false, "value": "<p>Upgrade to Temporal Server 1.32.0, which ships callback.inspectSourceHeader set to false and needs no further change. The fix makes the completion-callback source header opt-in behind the callback.inspectSourceHeader setting, so a callback's internality is decided from the server-generated callback URL rather than from a caller-supplied header. Releases 1.30.7 and 1.31.3 carry the same code but ship callback.inspectSourceHeader set to true for mixed-version compatibility while callbacks created with the older callback URL template drain, and while it is true the routing behavior matches the affected releases; an operator upgrading within the 1.30 or 1.31 line must therefore also set callback.inspectSourceHeader to false once every pre-fix server has drained. Operators who set callback.inspectSourceHeader to true restore the pre-fix behavior in full, including preservation of the caller's path and query across the internal rewrite, and should not enable it on a cluster that accepts caller-supplied completion callbacks. Temporal Server releases in the 1.25.0 through 1.29.7 range are outside the supported window and receive no fix; operators on those releases should upgrade to a supported line.</p>"}]}], "credits": [{"lang": "en", "value": "An external security researcher who reported this issue responsibly to Temporal Technologies", "type": "finder"}], "source": {"discovery": "EXTERNAL"}}}}

{}

{}

{}

{}