CVE-2026-16652: Temporal Server DoS Vulnerability

CVE-2026-16652 Overview

CVE-2026-16652 is a denial-of-service vulnerability in Temporal Server. The flaw stems from unbounded work performed while searching for a Schedule's next action time. An authenticated caller with namespace write permission can create or update a Schedule that pairs a fine-grained cadence with an exclusion calendar that rejects every candidate time. The server then evaluates excluded candidates without a per-search work budget, consuming excessive CPU in Frontend and Schedule worker components. A persisted specification can also cause its backing Schedule Workflow to repeatedly fail and retry, sustaining CPU consumption without further requests. The issue affects availability only and does not expose or modify Workflow data [CWE-606].

Critical Impact
Authenticated attackers with namespace write permission can trigger sustained CPU exhaustion in Temporal Frontend and Schedule worker components, denying service to legitimate workflows.

Affected Products

Temporal Server versions prior to v1.30.7
Temporal Server versions prior to v1.31.3
Temporal Schedule feature (Frontend and Schedule worker components)

Discovery Timeline

2026-09-21 - CVE-2026-16652 published to NVD
2026-09-22 - Last updated in NVD database

Technical Details for CVE-2026-16652

Vulnerability Analysis

The vulnerability resides in Temporal Server's Schedule specification evaluation logic. When computing the next action time for a Schedule, the server iterates through candidate times generated by the cadence and filters them against the Schedule's exclusion calendar. The loop lacked a bound on the number of candidates evaluated per search.

An authenticated caller with namespace write permission can define a Schedule with a fine-grained cadence, such as one that fires every second, combined with an exclusion calendar that rejects every generated candidate. The server enters a prolonged evaluation loop with no exit condition beyond finding a valid time. CPU consumption grows in both Frontend and Schedule worker components as requests are handled.

The persisted Schedule specification amplifies impact. The backing Schedule Workflow repeatedly fails and retries, causing continued CPU consumption without additional attacker requests. Parallel or repeated Schedule creation compounds the effect and can deny service across the cluster.

Root Cause

The root cause is missing per-search work budgeting in the Schedule generator. The prior implementation called spec.GetNextTime in a loop that terminated only when a valid time was found or the schedule ended. An over-excluded specification prevented either condition from occurring within a reasonable bound, classifying the flaw as an unrestricted recursion or iteration issue [CWE-606].

Attack Vector

Exploitation requires network access to the Temporal Frontend and valid credentials with namespace write permission. No user interaction is required. The attacker submits a crafted Schedule via the standard Temporal API, then optionally deletes or leaves it in place while its backing Workflow continues to retry.

// Patch excerpt from chasm/lib/scheduler/generator.go (PR #11014)
// Source: https://github.com/temporalio/temporal/commit/c10c730e53ae394fffaefe44ba3722150fe40720
for len(futureTimes) < count {
    res, err := spec.GetNextTime(sched.jitterSeed(), t)
    if err != nil || res.Next.IsZero() {
        // Over-excluded spec (limit) or end of schedule: return a partial list.
        break
    }
    t = res.Next
    futureTimes = append(futureTimes, timestamppb.New(t))
}

The patched GetNextTime returns an error when a per-search work limit is exceeded, allowing the caller to break out of the loop and return a partial list. See GitHub Pull Request #11014 for the full diff.

Detection Methods for CVE-2026-16652

Indicators of Compromise

Sustained high CPU utilization in Temporal Frontend or Schedule worker pods without corresponding request volume
Schedule Workflows in a repeated failure and retry state, visible in Temporal Web UI or via the CLI
Newly created or updated Schedules containing fine-grained cadences combined with broad exclusion calendars
Elevated latency on CreateSchedule, UpdateSchedule, or DescribeSchedule API calls

Detection Strategies

Audit Schedule specifications for combinations of sub-minute cadence and calendar exclusions that reject the majority of candidate times
Monitor per-namespace Schedule Workflow failure and retry counts and alert on sustained anomalies
Correlate Frontend CPU spikes with the identity of the authenticated principal that issued recent Schedule mutations

Monitoring Recommendations

Track the schedule_action_success and schedule_missed_catchup_window metrics alongside worker CPU usage
Enable audit logging on Schedule creation and update operations, capturing the caller identity and namespace
Ingest Temporal server logs and metrics into a SIEM to baseline normal Schedule behavior and flag deviations

How to Mitigate CVE-2026-16652

Immediate Actions Required

Upgrade Temporal Server to v1.30.7 or v1.31.3 or later, which introduce a per-search work budget for Schedule evaluation
Enumerate existing Schedules per namespace and terminate any backing Workflow exhibiting a repeated failure and retry pattern
Restrict namespace write permissions to trusted principals only, following least-privilege for Schedule management

Patch Information

The fix is delivered in GitHub Release v1.30.7 and GitHub Release v1.31.3. The change bounds work in spec.GetNextTime and returns an error when the budget is exceeded, allowing callers to return a partial list rather than looping indefinitely. The full commit is available at GitHub Commit c10c730.

Workarounds

Delete or terminate any offending Schedule and its backing Workflow to stop ongoing CPU consumption
Apply admission controls or policy checks that reject Schedule specifications combining sub-minute cadence with broad exclusion calendars
Reduce namespace write permissions until upgrade is possible, limiting who can create or update Schedules

bash

# Verify installed Temporal Server version and upgrade
temporal --version

# Example Helm upgrade to a patched release
helm upgrade temporal temporalio/temporal --version <chart-version-with-1.31.3>

# List Schedules per namespace and inspect specifications
temporal schedule list --namespace <namespace>
temporal schedule describe --schedule-id <id> --namespace <namespace>

# Delete a suspicious Schedule
temporal schedule delete --schedule-id <id> --namespace <namespace>