CVE-2026-84298: Cross-Tenant Authorization Bypass and Information Disclosure in Hatchet V1 Dispatcher

The Hatchet V1 Dispatcher manages asynchronous communication, task execution streams, and worker callbacks. It acts as the routing orchestrator for background processes, ensuring that durable workflow events and system state changes map back to their originating tenant worker streams. The dispatcher uses in-memory concurrency-safe maps to track state and maintain active network connections.

Historically, the dispatcher exposed a vulnerable surface through its durable task streaming endpoints. Specifically, the component failed to enforce logical tenant isolation boundaries during worker registration for incoming task execution streams. This lack of logical separation is categorized as CWE-862: Missing Authorization.

In multi-tenant deployments where different tenants share the same underlying dispatcher process, this omission allows workers to register interest in events from another tenant. If an attacker possesses the specific, non-enumerable task identifier, they can intercept the payload sequence of target workflow executions, bypassing tenant isolation controls.

The technical root cause resides in the declaration and application of the durableInvocations map within internal/services/dispatcher/dispatcher_v1.go. This map tracks active task execution callbacks using Go's syncx.Map. Prior to version 0.95.3, the map structure was configured as syncx.Map[uuid.UUID, *durableTaskInvocation], associating a flat task UUID directly with an active execution context.

When a worker calls the DurableTask gRPC endpoint to subscribe to execution updates, the handler in server_v1.go checks if the requested task identifier exists in its registry. It registers the connection in the global durableInvocations map using the user-supplied task ID as the key. This lookup and registration occur before validating whether the authenticated worker's tenant context owns the task.

Similarly, when a callback completes, the dispatcher resolves the destination stream using DeliverDurableEventLogEntryCompletion. Because this lookup queries the map solely by the task's external UUID, it locates any registered stream without checking the destination stream's tenant. Consequently, if an attacker registers the task UUID first, the dispatcher routes the completed execution payload to the attacker's stream session.

Analyzing the patch in commit 9555bfdd1e97f61d25e614ccaa107c5fb7dc4976 shows how Hatchet engineers transitioned the lookup logic from a single identifier to a compound key.

Before the patch, the registry was keyed solely by the task's external UUID:

// Vulnerable global map definition
durableInvocations syncx.Map[uuid.UUID, *durableTaskInvocation]

The patch fixes this vulnerability by introducing the durableInvocationsKey struct, which implements a composite key of the tenant ID and the task ID:

// Patched key implementation enforcing multi-tenancy boundaries
type durableInvocationsKey struct {
	tenantId uuid.UUID
	taskId   uuid.UUID
}
 
type DispatcherServiceImpl struct {
	// ... other fields ...
	durableInvocations syncx.Map[durableInvocationsKey, *durableTaskInvocation]
}

The registration logic in server_v1.go was updated to require the composite key during both storage and cleanup phases. This ensures that a worker's registration is isolated to their specific tenant scope:

// Patched registration logic enforcing the validated tenant context
if _, exists := registeredTasks[taskExtId]; !exists {
	d.durableInvocations.Store(durableInvocationsKey{
		tenantId: tenantId,
		taskId:   taskExtId,
	}, invocation)
	registeredTasks[taskExtId] = struct{}{}
}

When the task completes, the dispatcher retrieves the event stream using the authenticated tenant ID of the execution, making it impossible to query registrations associated with other tenants:

// Patched lookup using the verified tenant context
func (d *DispatcherServiceImpl) DeliverDurableEventLogEntryCompletion(
	tenantId uuid.UUID, 
	taskExternalId uuid.UUID, 
	// ... other parameters ...
) error {
	inv, ok := d.durableInvocations.Load(durableInvocationsKey{
		tenantId: tenantId,
		taskId:   taskExternalId,
	})
	if !ok {
		return fmt.Errorf("no active invocation found for task %s", taskExternalId)
	}
	// ... delivery sequence ...
}

Exploiting this flaw requires specific conditions and a sequenced approach. The target deployment must run shared dispatcher processes with multi-tenancy enabled. Single-tenant deployments are not affected.

First, the attacker must discover or acquire the non-enumerable UUIDv4 associated with a victim's active workflow task. Because UUIDv4 values have high entropy, brute-force search is not computationally feasible. The attacker must obtain the ID through logs, diagnostic API leaks, or adjacent path disclosures.

Second, the attacker establishes a gRPC stream connection using an authenticated worker on Tenant A. This worker calls the DurableTask stream subscription handler, passing the victim's task UUID as the execution target.

Third, when the dispatcher receives the completion signal for the victim's task, it queries the shared durableInvocations map. Because the lookup matches only on the task UUID, it finds the attacker's stream registration. The dispatcher then delivers the completed workflow result directly to the attacker's gRPC stream, revealing potentially sensitive payload details.

The overall security impact of this vulnerability is assessed as low (CVSS Base Score 3.1). Although it allows cross-tenant data leakage, the high complexity of discovering a targeted, non-enumerable UUIDv4 prevents automated, widespread exploitation.

The attack vector is Network, as the gRPC endpoint is accessible remotely. The attack complexity is High because the attacker must acquire the specific task identifier via out-of-band means and operate on the exact same dispatcher instance. Privileges required are Low, as the attacker must have valid credentials as a tenant worker.

Confidentiality impact is Low because only individual task execution result payloads can be retrieved. There is no impact on integrity or availability, as the routing collision does not allow modification of execution states or denial of service on the dispatcher platform itself. It is not currently included in CISA's Known Exploited Vulnerabilities catalog.

The primary recommendation is to update the Hatchet orchestrator to version 0.95.3 or later. This release replaces the vulnerable flat map key with a compound structure incorporating the verified tenant context, eliminating the routing collision vulnerability.

If upgrading is not immediately possible, deployers can restrict dispatcher instances to dedicated single-tenant workloads. Because the routing map exists in-memory per dispatcher process, isolating dispatcher instances by tenant blocks the cross-tenant exposure pathway.

Furthermore, developers and operators should review logging levels and sanitization rules. Ensure that internal task UUIDs are never exposed in user-facing logs, error messages, or diagnostic responses, as preserving the confidentiality of these identifiers is a key control in preventing exploitation.