CVE-2026-16652: 
Wolfi vulnerability analysis and mitigation

CVE-2026-16652 is a denial-of-service vulnerability in Temporal Server (go.temporal.io/server) caused by unbounded work performed while searching for a Schedule's next action time. An authenticated caller with namespace write permission can craft a Schedule combining a fine-grained cadence with an exclusion calendar that rejects every candidate time, causing excessive CPU consumption in Frontend and Schedule worker components. The vulnerability affects versions 1.17.0 through 1.29.7, 1.30.0 through 1.30.6, and 1.31.0 through 1.31.2. It was published on September 21, 2026, with patches released the same day. It carries a CVSS v4 base score of 7.1 (High) (Github Advisory).

The root cause is classified as CWE-606 (Unchecked Input for Loop Condition): the GetNextTime function in the scheduler's spec evaluation logic iterated over candidate times without enforcing a per-search work budget, allowing an attacker-controlled exclusion calendar to drive unbounded looping (Github Advisory). The attack vector is network-based and requires only low privileges (namespace write permission) with no user interaction. The fix introduced configurable SchedulerSpecWarnIterations and SchedulerSpecMaxIterations dynamic config parameters that cap the number of iterations during next-time computation, returning an ErrComputeLimitExceeded error when the hard limit is reached (PR #11014, Commit c10c730). A persisted malicious Schedule specification additionally causes its backing Schedule Workflow to repeatedly fail and retry, sustaining CPU consumption without further attacker interaction until the Schedule is deleted or the Workflow is terminated (Github Advisory).

Exploitation affects availability only — confidentiality and integrity of Workflow data are not impacted. Successful exploitation causes excessive CPU consumption in the Temporal Frontend and Schedule worker components, which can degrade or deny service to all users of the affected Temporal Server instance. Repeated or parallel exploitation by one or more authenticated users can amplify the denial-of-service effect, and a single persisted malicious Schedule can sustain CPU exhaustion indefinitely without additional attacker requests (Github Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at the time of disclosure (Github Advisory). The EPSS score is 0.0, and the NVD SSVC assessment classifies exploitation as "none" and the attack as non-automatable. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Exploitation requires authenticated access with namespace write permission, which limits the attacker pool but does not require elevated administrative privileges.

1. Obtain namespace write access: Acquire credentials for a Temporal namespace with write permission — this could be via a legitimate user account, a compromised service account, or a self-provisioned account in a multi-tenant deployment.
2. Craft a malicious Schedule specification: Construct a Schedule payload that combines a fine-grained cadence (e.g., a CalendarSpec firing every second: {Second: "*", Minute: "*", Hour: "*"}) with an exclusion calendar using the identical spec, ensuring every candidate time is rejected.
3. Submit the Schedule via the Temporal API: Use the Temporal CLI, SDK, or gRPC API to call CreateSchedule or UpdateSchedule with the crafted specification targeting the vulnerable server.
4. Trigger unbounded CPU consumption: The server's GetNextTime loop evaluates each candidate time against the exclusion calendar without a work budget, consuming excessive CPU in the Frontend (on API calls such as ListScheduleMatchingTimes) and in the Schedule worker component.
5. Sustain the attack passively: Once persisted, the backing Schedule Workflow repeatedly fails and retries the next-time computation, continuing CPU exhaustion without further attacker interaction until the Schedule is deleted or the Workflow is terminated.
6. Amplify with parallel Schedules: Create multiple such Schedules in parallel to multiply CPU load and increase the likelihood of a full denial of service (Github Advisory, PR #11014).

• Metrics/Monitoring: Sudden, sustained spikes in CPU utilization on Temporal Frontend and Schedule worker processes without a corresponding increase in legitimate workflow throughput.
• Temporal Metrics: Elevated counts of the schedule_compute_limit_exceeded or schedule_compute_limit_warning metrics (introduced in the patched versions as detection signals) on unpatched servers may not be present, but abnormal scheduler loop durations can be observed.
• Logs: Repeated Schedule Workflow failure and retry log entries for the same Schedule ID in Temporal server logs; log messages indicating a Schedule Workflow is cycling through failure/retry states continuously.
• API Activity: Unusual CreateSchedule or UpdateSchedule API calls — particularly those specifying both a high-frequency cadence (e.g., every second) and an exclusion calendar — visible in Temporal Frontend access logs or audit logs.
• Schedule Definitions: Presence of Schedule specifications combining fine-grained cadence (e.g., Second: "*") with an exclusion calendar that matches all or nearly all candidate times, identifiable via ListSchedules API enumeration (Github Advisory, PR #11014).

Upgrade Temporal Server to version 1.30.7 or 1.31.3, which introduce a configurable per-search work budget via the SchedulerSpecWarnIterations and SchedulerSpecMaxIterations dynamic config parameters (v1.30.7 Release, v1.31.3 Release). Versions in the 1.17.0–1.29.7 range should be upgraded to a supported patched release. As interim mitigations: restrict namespace write permissions to trusted users only; monitor CPU usage on Frontend and Schedule worker components for anomalous spikes; audit existing Schedule definitions for suspicious cadence and exclusion calendar combinations; and delete or terminate any Schedules or backing Workflows exhibiting repeated failures and retries (Github Advisory).