CVE-2026-87857: Temporal Server workflow-history pagination token is not bound to the requested namespace and workflow
Temporal Server does not bind a workflow-history pagination token to the namespace and workflow named in the request that presents it. GetWorkflowExecutionHistory and GetWorkflowExecutionHistoryReverse authorize the caller against the namespace in the request, then select history from the branch recorded inside the caller-supplied nextpagetoken. The normal history continuation carries a run identifier, event bounds, a persistence cursor, and a branch token, but no namespace or workflow identity, and it is serialized as unauthenticated protobuf bytes. An authenticated caller holding read permission on one namespace, together with a genuine non-final continuation issued earlier for a workflow in a second namespace, can submit that continuation with a request naming the first namespace and receive the second namespace's workflow history, provided the supplied workflow identifier selects the same History shard as the continuation's branch. No workflow with the supplied identifier needs to exist. Because the token is unauthenticated, a holder can also advance its event range and clear its persistence cursor, which returns history events created after that caller's current credential no longer granted access to the continuation's namespace. Determining exposure is a version question rather than a configuration question: every release listed as affected omits the binding check on the forward history path, and on the reverse history path in releases from 1.16.0, which introduced GetWorkflowExecutionHistoryReverse; no setting in an affected release restores it, and affected releases emit no metric or log for the condition, so their telemetry provides no detection. Fixed releases add the check and, when a page token's branch token is not the requested execution's current branch token, record the counter paginationtokenbranchmismatch tagged with namespace and reason and write a History-service warning log reading "Pagination branch token is not the execution's current branch token" with the fields wf-namespace, wf-id, wf-run-id, reason, wf-branch-token, and wf-request-branch-token. Search History warning logs for that message, or for reason=foreignbranch, which denotes a branch token the requested execution never recorded and is not expected in normal operation; reason=noncurrentbranch denotes a retained but superseded branch of the same execution and can occur legitimately after conflict resolution or failover. A foreignbranch record does not by itself prove the read was refused, because the counter and log are emitted before the enforcement decision and therefore appear both when the check rejects the request and when history.enablePaginationTokenBranchValidationShadowMode is enabled and the read is served; confirm refusal from the gRPC response, which is InvalidArgument carrying a CurrentBranchChangedFailure detail. The metric and log are tagged with the requesting namespace, not the namespace whose history the token selects, so a foreignbranch alert does not name the exposed namespace. The issue does not provide unauthenticated access, construction of a usable continuation from public workflow identifiers, enumeration of workflows for which the caller holds no continuation, or any modification of workflow state.
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.7 - Upgrade
Upgrade
Temporal Serverto a version that resolves this vulnerability.Fixed in 1.31.3 - Upgrade
Upgrade
Temporal Serverto a version that resolves this vulnerability.Fixed in 1.32.0 - Configuration
Leave history.enablePaginationTokenBranchValidation at its default of true.
Temporal Server history.enablePaginationTokenBranchValidation = true - Configuration
Leave history.enablePaginationTokenBranchValidationShadowMode at its default of false.
Temporal Server history.enablePaginationTokenBranchValidationShadowMode = false
Event History
Frequently Asked Questions
Who can realistically exploit this issue?
An authenticated caller must have read permission on one namespace and possess a genuine, non-final history continuation token previously issued for a workflow in a different namespace. The request's supplied workflow identifier must select the same History shard as the branch recorded in that token.
Does the requested workflow need to exist for an unauthorized history read?
No. A workflow with the identifier supplied in the request does not need to exist, as long as that identifier selects the same History shard as the continuation token's branch.
What can an attacker do with a captured continuation token?
The caller can submit it to GetWorkflowExecutionHistory or GetWorkflowExecutionHistoryReverse while naming a namespace they are authorized to read, causing history from the token's recorded branch to be selected. Because the protobuf token is unauthenticated, the holder can also modify its event range and clear its persistence cursor.