Temporal Discloses Eight Authorization and Availability Flaws

Quick Answer

The authority published CVE-2026-16651 for Temporal Server 1.29.7 and earlier and affected 1.30/1.31 branches, plus the listed sqlparser, tchannel-go, and ringpop-go dependency ranges. temporalio/sqlparser can panic when Parse, ParseStrictDDL, or ParseNext processes a MySQL version comment whose contents are empty or consist only of one to five decimal digits. ExtractMysqlComment does not check the -1 result returned by strings.IndexFunc before using it as a slice boundary. The resulting Go runtime panic propagates unless the caller recovers it on the parsing goroutine, so applications that parse attacker-controlled SQL can terminate. Temporal Server exposes the affected parser through ListWorkers. When that API is enabled, an authenticated caller with namespace read permission can submit a malformed query that terminates the receiving Matching process. Repeated requests can sustain a denial of service. The issue affects availability only; no confidentiality or integrity impact was identified. Temporal Server did not bound the work performed while searching for a Schedule's next action time. An authenticated caller with namespace write permission could create or update a Schedule that combines a fine-grained cadence with an exclusion calendar that rejects every candidate time, causing the server to evaluate excluded candidates without a per-search work budget. This can consume excessive CPU in Frontend and Schedule worker components. A persisted specification can also cause its backing Schedule Workflow to repeatedly fail and retry, allowing CPU consumption to continue without additional requests until the Schedule is deleted or its backing Workflow is terminated. Repeated or parallel exploitation can deny service. The issue affects availability only; it does not expose or modify Workflow data. temporalio/sqlparser accepts SQL containing deeply nested unary expressions and can return a correspondingly deep abstract syntax tree without enforcing an applicable nesting limit. The library's String and Walk operations recursively traverse that tree. An application that parses attacker-controlled SQL and later formats or walks the returned tree can encounter a runtime-fatal Go stack overflow that terminates the process; Go panic recovery cannot contain this condition. Temporal Server passes caller-controlled query input through the affected parser in archival, visibility, and worker-query paths. In affected validation paths, the Server recursively formats an invalid expression while constructing an error. In a supported authenticated deployment, a caller with namespace read permission can terminate the receiving Frontend or Matching process. The dynamically confirmed ListWorkers route additionally requires at least one retained worker heartbeat. Repeated requests can sustain a denial of service. The issue affects availability only; no confidentiality or integrity impact was identified. github.com/temporalio/tchannel-go did not validate the one-byte checksum-type field in inbound TChannel call frames. A network peer that can reach a listener can complete the standard initialization handshake and send a call request with an unsupported checksum type. The parser uses that value as an index into a four-entry checksum pool, causing an unrecovered Go panic on the connection read goroutine and terminating the hosting process. This allows remote denial of service against applications that expose the listener to untrusted peers. The impact is limited to availability; no confidentiality or integrity impact was identified. github.com/temporalio/tchannel-go did not reject TChannel call fragments containing checksum metadata but no length-prefixed argument chunks. The fragment reader left its chunk slice empty and then unconditionally selected the first element. A network peer can supply such a malformed call fragment, including as a direct initial call request after completing the standard initialization handshake. On that inbound path, the resulting unrecovered Go slice-bounds panic occurs on a library-created dispatch goroutine and terminates the hosting process. This allows remote denial of service against applications that expose the listener to untrusted peers. The impact is limited to availability; no confidentiality or integrity impact was identified. github.com/temporalio/ringpop-go enforces configured LabelOptions limits when an application changes the local node's labels, but affected versions do not apply those limits to label maps received in SWIM membership changes. A network peer that can reach a live Ringpop TChannel listener can repeatedly submit changes for distinct member addresses containing label keys, values, or counts that exceed the receiver's configured limits. Accepted labels are retained in the member list and disseminated to peers, allowing memory and gossip-bandwidth consumption to exceed configured bounds and potentially making the hosting process unavailable. The fix validates peer-supplied label maps before they are retained or disseminated. Availability only; no confidentiality or integrity impact was identified. 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. Temporal Server compiles a Worker Controller Instance module into its Worker Service, and that module registers a compute provider named subprocess whose function is to launch a worker by running a command on the machine hosting the Worker Service. The program name and the argument vector that provider executes are taken from the compute provider configuration supplied in the caller's request rather than from operator configuration. An authenticated caller holding only a write role in a single namespace can therefore configure a worker deployment version so that the Worker Service executes a command of the caller's choosing on its own host, under the account the server process runs as. Execution is immediate rather than deferred: the configuration handler invokes every provider using the invoke strategy directly after validating the submitted specification, so no scaling decision, task arrival, or unusual request sequence is required. Because the Worker Service process holds the persistence credentials for every namespace in the cluster and the cluster's TLS material, the consequence reaches beyond the caller's namespace to the cluster as a whole. The provider is present in the official temporal-server binaries and container images for the affected releases. The only control that can keep it unreachable is the compute provider allowlist, the per-namespace dynamic configuration setting workercontroller.compute_providers.enabled, and that control does not deny by default: its default value is an unset list, and the allowlist check is skipped entirely when the value is unset, so every registered compute provider is permitted, this one included. To determine whether a deployment is affected, check the following together. The deployed Temporal Server version is 1.31.0 or later and earlier than 1.31.3. The Worker Service is running, which it is in the default service set and therefore in a stock deployment. The effective per-namespace value of workercontroller.compute_providers.enabled is either unset or contains subprocess. And authorization is configured, meaning a real authorizer and claim mapper are in place; a deployment running with no authorizer already grants every caller unrestricted access to every namespace, so it has no namespace boundary for this to cross. Note that the separate per-namespace dynamic configuration setting workercontroller.enabled does not gate the affected path. It defaults to false, and a deployment that has never set it in any namespace is still affected, which was confirmed by running an affected release with no value for that setting present anywhere in dynamic configuration. To look for a compute configuration that is already attached, call DescribeWorkerDeploymentVersion for each worker deployment version in each namespace and check whether any scaling group's compute provider type is subprocess. Affected deployments should be matched to the authority's exact scope and moved to the supported fixed release.

Last verified: 2026-09-21 UTC. Recheck the authoritative advisory and supported distribution channel before changing production.

Scope And Authority

Product scope	Temporal Server 1.29.7 and earlier and affected 1.30/1.31 branches, plus the listed sqlparser, tchannel-go, and ringpop-go dependency ranges
Advisory	CVE-2026-16651 / CVE-2026-16652 / CVE-2026-65651 / CVE-2026-65652 / CVE-2026-65653 / CVE-2026-65654 / CVE-2026-87858 / CVE-2026-89139
CVEs	CVE-2026-16651, CVE-2026-16652, CVE-2026-65651, CVE-2026-65652, CVE-2026-65653, CVE-2026-65654, CVE-2026-87858, CVE-2026-89139
Authoritative release date	2026-09-21 11:23:47.298 UTC
Authority revision date	2026-09-21 15:33:15.387 UTC
Affected versions	Temporal Server 1.29.7 and earlier and affected 1.30/1.31 branches, plus the listed sqlparser, tchannel-go, and ringpop-go dependency ranges
Fixed version	Temporal Server 1.30.7 / 1.31.3 / 1.32.0; tchannel-go 1.22.1; patched sqlparser and ringpop-go commits
CVSS base score	6.0 / 7.1 / 7.2 / 8.7 (CVSS v4.0)
CVSS severity	Medium to High
Exploitation status	Not stated by the authority; no exploitation claim is inferred.

What Changed

temporalio/sqlparser can panic when Parse, ParseStrictDDL, or ParseNext processes a MySQL version comment whose contents are empty or consist only of one to five decimal digits. ExtractMysqlComment does not check the -1 result returned by strings.IndexFunc before using it as a slice boundary. The resulting Go runtime panic propagates unless the caller recovers it on the parsing goroutine, so applications that parse attacker-controlled SQL can terminate. Temporal Server exposes the affected parser through ListWorkers. When that API is enabled, an authenticated caller with namespace read permission can submit a malformed query that terminates the receiving Matching process. Repeated requests can sustain a denial of service. The issue affects availability only; no confidentiality or integrity impact was identified. Temporal Server did not bound the work performed while searching for a Schedule's next action time. An authenticated caller with namespace write permission could create or update a Schedule that combines a fine-grained cadence with an exclusion calendar that rejects every candidate time, causing the server to evaluate excluded candidates without a per-search work budget. This can consume excessive CPU in Frontend and Schedule worker components. A persisted specification can also cause its backing Schedule Workflow to repeatedly fail and retry, allowing CPU consumption to continue without additional requests until the Schedule is deleted or its backing Workflow is terminated. Repeated or parallel exploitation can deny service. The issue affects availability only; it does not expose or modify Workflow data. temporalio/sqlparser accepts SQL containing deeply nested unary expressions and can return a correspondingly deep abstract syntax tree without enforcing an applicable nesting limit. The library's String and Walk operations recursively traverse that tree. An application that parses attacker-controlled SQL and later formats or walks the returned tree can encounter a runtime-fatal Go stack overflow that terminates the process; Go panic recovery cannot contain this condition. Temporal Server passes caller-controlled query input through the affected parser in archival, visibility, and worker-query paths. In affected validation paths, the Server recursively formats an invalid expression while constructing an error. In a supported authenticated deployment, a caller with namespace read permission can terminate the receiving Frontend or Matching process. The dynamically confirmed ListWorkers route additionally requires at least one retained worker heartbeat. Repeated requests can sustain a denial of service. The issue affects availability only; no confidentiality or integrity impact was identified. github.com/temporalio/tchannel-go did not validate the one-byte checksum-type field in inbound TChannel call frames. A network peer that can reach a listener can complete the standard initialization handshake and send a call request with an unsupported checksum type. The parser uses that value as an index into a four-entry checksum pool, causing an unrecovered Go panic on the connection read goroutine and terminating the hosting process. This allows remote denial of service against applications that expose the listener to untrusted peers. The impact is limited to availability; no confidentiality or integrity impact was identified. github.com/temporalio/tchannel-go did not reject TChannel call fragments containing checksum metadata but no length-prefixed argument chunks. The fragment reader left its chunk slice empty and then unconditionally selected the first element. A network peer can supply such a malformed call fragment, including as a direct initial call request after completing the standard initialization handshake. On that inbound path, the resulting unrecovered Go slice-bounds panic occurs on a library-created dispatch goroutine and terminates the hosting process. This allows remote denial of service against applications that expose the listener to untrusted peers. The impact is limited to availability; no confidentiality or integrity impact was identified. github.com/temporalio/ringpop-go enforces configured LabelOptions limits when an application changes the local node's labels, but affected versions do not apply those limits to label maps received in SWIM membership changes. A network peer that can reach a live Ringpop TChannel listener can repeatedly submit changes for distinct member addresses containing label keys, values, or counts that exceed the receiver's configured limits. Accepted labels are retained in the member list and disseminated to peers, allowing memory and gossip-bandwidth consumption to exceed configured bounds and potentially making the hosting process unavailable. The fix validates peer-supplied label maps before they are retained or disseminated. Availability only; no confidentiality or integrity impact was identified. 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. Temporal Server compiles a Worker Controller Instance module into its Worker Service, and that module registers a compute provider named subprocess whose function is to launch a worker by running a command on the machine hosting the Worker Service. The program name and the argument vector that provider executes are taken from the compute provider configuration supplied in the caller's request rather than from operator configuration. An authenticated caller holding only a write role in a single namespace can therefore configure a worker deployment version so that the Worker Service executes a command of the caller's choosing on its own host, under the account the server process runs as. Execution is immediate rather than deferred: the configuration handler invokes every provider using the invoke strategy directly after validating the submitted specification, so no scaling decision, task arrival, or unusual request sequence is required. Because the Worker Service process holds the persistence credentials for every namespace in the cluster and the cluster's TLS material, the consequence reaches beyond the caller's namespace to the cluster as a whole. The provider is present in the official temporal-server binaries and container images for the affected releases. The only control that can keep it unreachable is the compute provider allowlist, the per-namespace dynamic configuration setting workercontroller.compute_providers.enabled, and that control does not deny by default: its default value is an unset list, and the allowlist check is skipped entirely when the value is unset, so every registered compute provider is permitted, this one included. To determine whether a deployment is affected, check the following together. The deployed Temporal Server version is 1.31.0 or later and earlier than 1.31.3. The Worker Service is running, which it is in the default service set and therefore in a stock deployment. The effective per-namespace value of workercontroller.compute_providers.enabled is either unset or contains subprocess. And authorization is configured, meaning a real authorizer and claim mapper are in place; a deployment running with no authorizer already grants every caller unrestricted access to every namespace, so it has no namespace boundary for this to cross. Note that the separate per-namespace dynamic configuration setting workercontroller.enabled does not gate the affected path. It defaults to false, and a deployment that has never set it in any namespace is still affected, which was confirmed by running an affected release with no value for that setting present anywhere in dynamic configuration. To look for a compute configuration that is already attached, call DescribeWorkerDeploymentVersion for each worker deployment version in each namespace and check whether any scaling group's compute provider type is subprocess.

What To Validate Now

1. Inventory. Locate Temporal Server 1.29.7 and earlier and affected 1.30/1.31 branches, plus the listed sqlparser, tchannel-go, and ringpop-go dependency ranges deployments, versions, enabled features, exposure paths, owners, and dependent services.
2. Establish applicability. Compare each deployment with the authority's affected-version statement: Temporal Server 1.29.7 and earlier and affected 1.30/1.31 branches, plus the listed sqlparser, tchannel-go, and ringpop-go dependency ranges Do not infer applicability from product family or severity alone.
3. Remediate. Apply Temporal Server 1.30.7 / 1.31.3 / 1.32.0; tchannel-go 1.22.1; patched sqlparser and ringpop-go commits through the supported vendor or project channel, following the current advisory and change-control requirements.
4. Validate. Confirm the resulting version or managed-service state, exercise representative functionality and recovery paths, monitor for regressions, and document exceptions.
5. Retain evidence. Preserve asset and owner identifiers, the applicability decision, before-and-after versions, change approval, installation output, validation results, and any exception or rollback record.

Operational Cautions

Use the exact supported release stream and repository. Test dependencies, clusters, integrations, and rollback before broad deployment; a CVSS rating or reachable feature is not evidence of exploitation.

Evidence To Retain

• Exact product, release stream, package or application version, enabled feature, environment, and accountable owner.
• UTC timestamps, authority revision, approved change record, installer or package-manager output, and resulting version.
• Relevant logs and monitoring evidence, test results, exceptions, compensating controls, and rollback decisions.

Related TechGeeks Resources

• TechGeeks Security Notice Center
• All Security Notices

Authoritative References

• CVE-2026-16651
• CVE-2026-16652
• CVE-2026-65651
• CVE-2026-65652
• CVE-2026-65653
• CVE-2026-65654
• CVE-2026-87858
• CVE-2026-89139

Correction policy: If the authority changes affected versions, fixed versions, severity, exploitation information, mitigations, or required action, TechGeeks will update this notice and its verification date.