Description

Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. From 0.40.0 until 0.91.1, the Dispatcher gRPC service does not verify that a request's worker ID belongs to the tenant identified by the bearer-token context in Dispatcher/UpsertWorkerLabels and Dispatcher/Unsubscribe. An authenticated owner of any tenant who guesses another tenant's worker UUID can overwrite that worker's affinity labels or disconnect the worker from the dispatcher. This can cause cross-tenant integrity impact and denial of service on multi-tenant Hatchet Cloud or shared self-hosted deployments. Single-tenant deployments are not practically affected because the attacker and target tenant are the same. This issue is fixed in version 0.91.1.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.4",
  "pubDate": "2026-08-28T20:18:17.390Z",
  "pubdate": "2026-08-28T20:18:17.390Z",
  "executiveSummary": "A critical authorization flaw exists within the Hatchet Dispatcher gRPC service, specifically affecting versions 0.40.0 through 0.91.0.\nThe vulnerability is characterized by improper validation of cross-tenant resource access, where the service fails to verify that a provided worker ID belongs to the authenticated tenant identified in the bearer token context.\nThis authorization bypass allows an authenticated attacker within one tenant to manipulate worker resources belonging to other tenants.\nImpact includes cross-tenant data integrity compromise, where an attacker can overwrite affinity labels, and a denial of service (DoS) capability by disconnecting arbitrary workers from the dispatcher.\nThe vulnerability is most significant in multi-tenant Hatchet Cloud or shared self-hosted deployments; single-tenant environments remain unaffected as the attacker and target exist within the same trust boundary.\nSuccessful exploitation requires the attacker to possess a valid bearer token for any tenant and to successfully guess or discover the UUID of a target worker belonging to a different tenant.",
  "technicalDetails": "The vulnerability resides in the Dispatcher gRPC service, specifically within the UpsertWorkerLabels and Unsubscribe function handlers. The root cause is a lack of server-side validation ensuring that the worker UUID provided in the gRPC request matches the tenant context associated with the bearer token presented by the caller.\nIn the Hatchet architecture, the Dispatcher service handles communication with worker nodes. When an authenticated client calls UpsertWorkerLabels or Unsubscribe, the service relies on the supplied worker UUID to perform operations. Because the service does not perform an authorization check to enforce tenant isolation, the system assumes the caller has ownership of the specified worker resource regardless of whether the bearer token belongs to that specific tenant.\nThe exploitation flow proceeds as follows: First, an attacker authenticates to their own legitimate tenant to obtain a valid bearer token. Second, the attacker identifies or guesses the UUID of a worker registered by another tenant. Given that worker UUIDs may be discoverable via other telemetry or logs, this serves as the primary barrier to entry.\nOnce the target worker UUID is obtained, the attacker issues a specially crafted gRPC request to the Dispatcher service. By calling UpsertWorkerLabels, the attacker can manipulate the affinity labels of the victim's worker. This action can redirect workflows, cause execution errors, or influence logic based on label-dependent routing. Alternatively, by invoking the Unsubscribe function, the attacker can force the victim worker to disconnect from the dispatcher, effectively creating a denial-of-service condition for the targeted background tasks.\nBecause the Dispatcher service performs these operations without verifying the mapping between the worker UUID and the tenant ID in the metadata, the security boundary between tenants is effectively dissolved. The platform fails to enforce 'Principle of Least Privilege' at the cross-tenant boundary. The vulnerability persists across versions 0.40.0 up to 0.91.0, and the logic error is remediated in version 0.91.1 by implementing an authorization check that cross-references the bearer token's tenant identifier with the target worker's registered tenant owner before executing any state-changing operations."
}