The Old Switcheroo: Bypassing Namespace Policies in Temporal (CVE-2025-14986)

Temporal is the engine that keeps the internet's state machines running. It’s complex, powerful, and usually, pretty strict about who does what. Recently, Temporal introduced ExecuteMultiOperation—a power-user feature designed to execute multiple commands (like starting a workflow and sending a signal) in a single, atomic gRPC call. It’s a performance optimization for high-throughput systems that need to reduce round-trips.

But here’s the thing about batch operations: they introduce complexity in validation. When you hand the bouncer a stack of IDs for your group, does he check every single one against the guest list, or does he just glance at the top one and wave you all through?

In CVE-2025-14986, it turns out the bouncer was a bit confused. He was checking the ID of the person inside the trench coat, but letting the person wearing the trench coat into the club based on that ID. This created a fascinating logic gap where policy checks (rate limits, feature flags) were decoupled from execution targets.

The vulnerability lies in the ExecuteMultiOperation API handler. This handler accepts a request object that wraps a list of operations. Crucially, the wrapper has a Namespace field (used for routing and authorization), and the embedded operations (like StartWorkflowExecutionRequest) also have their own Namespace fields.

Logic dictates that these should match. If I authenticate to Namespace-A, I shouldn't be able to submit an embedded command for Namespace-B. However, the code responsible for validating the request—checking if the namespace has enough rate limit quota remaining or if a specific beta feature is enabled—looked at the embedded namespace.

Meanwhile, the code responsible for executing the logic (creating the workflow row in the database) looked at the outer namespace.

This is a classic 'Object of Check vs. Object of Use' vulnerability. The system validated the rules for the decoy namespace but applied the effects to the target namespace.

Let's look at what the logic likely resembled before the fix. The handler iterates over the operations to perform pre-execution checks.

Vulnerable Logic (Conceptual):

func (h *Handler) ExecuteMultiOperation(ctx context.Context, req *workflow.ExecuteMultiOperationRequest) ... {
    // 1. Authorize against the OUTER namespace (Correct)
    if !h.authorize(ctx, req.Namespace) {
        return Error("Unauthorized")
    }
 
    // 2. Iterate over operations to validate limits/gates
    for _, op := range req.Operations {
        // BUG: Validating against the INNER namespace provided in the op!
        // If op.Namespace is "Enterprise-Tier", we get high limits.
        if !h.validateRateLimits(op.Namespace) {
             return Error("Rate limit exceeded")
        }
    }
 
    // 3. Execute in the OUTER namespace
    return h.engine.ExecuteMulti(ctx, req.Namespace, req.Operations)
}

Because the validateRateLimits function trusted the namespace string inside the operation struct, the attacker controlled the policy context completely independent of their execution context.

The Fix (PR #8839): The remediation was simple but critical: enforce that op.Namespace == req.Namespace.

for _, op := range req.Operations {
    if op.Namespace != req.Namespace {
        return Error("Namespace mismatch: Inner operation must match outer request")
    }
    // ... proceed with validation
}

To exploit this, we don't need memory corruption or complex heap spraying. We just need to speak gRPC. An attacker with access to a low-tier namespace (let's call it FreeTier-NS) wants to run a heavy workload that usually gets throttled.

They construct a ExecuteMultiOperationRequest:

1. Outer Namespace: FreeTier-NS (Where they have valid credentials).
2. Inner Operation: StartWorkflowExecutionRequest.
3. Inner Namespace: Enterprise-NS (A namespace known to have high throughput limits or specific feature flags enabled).

The Attack Chain:

1. The attacker sends this malformed packet to the Temporal frontend.
2. The Frontend validates the auth token against FreeTier-NS. Pass.
3. The Frontend checks rate limits. It sees the inner operation claims to be for Enterprise-NS. It checks the Enterprise-NS bucket. Pass (it has plenty of capacity).
4. The Frontend executes the workflow. It uses the FreeTier-NS context from the outer wrapper.
5. Success: The attacker has successfully started a workflow in their own namespace, bypassing the rate limits that should have stopped them.

The CVSS score of 1.3 (Low) suggests this is barely a nuisance. And strictly speaking, from a CIA (Confidentiality, Integrity, Availability) triad perspective, it is minor. You cannot read data from other namespaces. You cannot write data to namespaces you don't own.

However, in a multi-tenant SaaS environment, Policy is Money.

If Temporal is being offered as a managed service, this bug allows a tenant on the $5/month plan to utilize the resources and throughput of the $5000/month plan. It breaks the business logic of tenancy isolation, even if it preserves the data integrity of tenancy. Furthermore, it allows bypassing Feature Gates. If a feature is disabled in your namespace because it's buggy or security-sensitive, you might be able to toggle it on by masquerading as a namespace that has it enabled.