Description

Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. Prior to 0.106.1, the WorkerStatus gRPC polling path in pkg/repository/durable_events.go passes caller-supplied durable task, node, and branch identifiers to ListSatisfiedEntries without a tenant filter, allowing an authenticated tenant worker that knows another tenant's durable-task UUID to retrieve matching durable event-log records. The UUIDv4 requirement makes exploitation unlikely, and single-tenant deployments are unaffected in practice. This issue is fixed in version 0.106.1.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-09-21T16:17:26.010Z",
  "pubdate": "2026-09-21T16:17:26.010Z",
  "executiveSummary": "A broken access control vulnerability exists in Hatchet versions prior to 0.106.1, specifically within the WorkerStatus gRPC polling mechanism.\nThe vulnerability allows an authenticated tenant worker to perform unauthorized data retrieval of durable event-log records belonging to other tenants.\nThe flaw originates from an insufficient authorization check in the pkg/repository/durable_events.go file, where the ListSatisfiedEntries function fails to enforce tenant-based filtering on caller-supplied identifiers.\nWhile the exploitation requires knowledge of another tenant's UUIDv4-based durable-task identifier, the impact includes unauthorized information disclosure of cross-tenant task execution history.\nSingle-tenant deployments remain unaffected due to the absence of competing tenant identifiers. Multi-tenant environments are at risk if an attacker can discover or guess the specific UUIDs assigned to other tenants' workflows.\nThe risk is categorized as an improper authorization vulnerability that bypasses logical tenant isolation boundaries, potentially exposing metadata or state information contained within event logs.",
  "technicalDetails": "The vulnerability resides within the Hatchet gRPC polling path, specifically inside the pkg/repository/durable_events.go file. The root cause is a failure to implement proper tenant-scoping within the ListSatisfiedEntries function. When a worker initiates a gRPC call for WorkerStatus, it provides parameters including durable task, node, and branch identifiers. The backend logic processes these identifiers to retrieve event-log records from the repository layer without verifying that the requesting tenant possesses the requisite authorization for the specific IDs provided.\nIn a multi-tenant Hatchet architecture, the system is expected to partition data based on tenant identity. The implementation of ListSatisfiedEntries bypasses this partitioning by treating the supplied identifiers as globally accessible keys rather than scoped resources. Consequently, if a malicious actor—authenticated as a valid tenant worker—supplies a target UUID corresponding to an object owned by a different tenant, the repository query executes without a tenant filter, returning the sensitive durable event-log data to the unauthorized requester.\nThe attack flow follows these steps: 1) The attacker authenticates as a legitimate tenant worker within the platform. 2) The attacker obtains a target UUIDv4 associated with a durable task, node, or branch belonging to a different tenant. This discovery phase is the primary bottleneck, as UUIDv4 provides high entropy, making enumeration statistically improbable but theoretically possible if identifiers are leaked or logged elsewhere. 3) The attacker crafts a gRPC request targeting the WorkerStatus polling path, injecting the discovered UUIDs into the payload. 4) The server-side code in pkg/repository/durable_events.go processes the request and executes the database query without verifying the tenant-ownership relationship. 5) The repository layer returns the satisfied event log entries to the attacker, resulting in unauthorized data access.\nThe exposure of these logs provides insights into the workflow state, execution patterns, and potentially sensitive metadata of other tenants' tasks. Because the check is missing at the repository integration level, the application layer effectively trusts client-provided input to define the scope of data retrieval, violating the principle of least privilege and failing to enforce logical segmentation between mutually distrusting tenants."
}