CVE-2026-88978 in Hatchet
Summary
by MITRE • 09/21/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/21/2026
The vulnerability identified within the Hatchet platform stems from an insufficient access control mechanism implemented in the WorkerStatus gRPC polling path located in the pkg/repository/durable_events.go module. As a platform designed for orchestrating background tasks, AI agents, and durable workflows at scale, Hatchet relies on strict tenant isolation to ensure that data belonging to one customer or organization remains inaccessible to others. However, prior to version 0.106.1, the function responsible for listing satisfied entries failed to enforce tenant-specific filtering when processing requests from authenticated workers. Specifically, when a worker submits durable task, node, and branch identifiers via gRPC, these caller-supplied parameters are passed directly to the ListSatisfiedEntries method without verifying that the requesting entity owns or is authorized to access the specified resources. This architectural oversight creates a potential avenue for unauthorized data retrieval if an attacker can predict or obtain valid UUIDs associated with other tenants.
From a technical perspective, this flaw represents a classic case of insecure direct object references where the system trusts client-supplied identifiers without validating them against the authenticated user's context. The operational impact involves the ability of an authenticated tenant worker to retrieve matching durable event-log records belonging to another tenant, provided they possess the correct UUIDs for those tasks or nodes. While this constitutes a significant breach of data confidentiality and isolation boundaries in theory, practical exploitation is heavily constrained by the nature of the identifiers involved. The system utilizes UUIDv4 standards for these identifiers, which are randomly generated and non-sequential. Consequently, guessing or brute-forcing valid UUIDs for another tenant's resources is computationally infeasible under normal circumstances. Furthermore, single-tenant deployments remain unaffected as there is no concept of cross-tenant data access to exploit. Despite the low likelihood of successful exploitation due to these constraints, the vulnerability remains a critical security defect because it violates fundamental principles of multi-tenancy and could be leveraged if UUIDs are leaked through other vectors such as logs or error messages.
In terms of industry standards classification, this issue aligns with CWE-284 Improper Access Control, specifically reflecting failures in authorization checks where user input is not properly validated against access policies before being processed by backend functions. It also relates to CWE-601 URL Redirection to Untrusted Site or Resource if the identifiers were used for redirection, but more accurately fits CWE-798 Use of Hard-coded Credentials if we consider the implicit trust in UUIDs as valid keys without secondary verification. From an ATT&CK perspective, this vulnerability facilitates Data Exfiltration from Remote Systems via Network Service, allowing an adversary to access sensitive operational data stored within the durable event logs. The lack of tenant filtering means that once authenticated access is established, lateral movement across tenants becomes possible if identifiers are known, undermining the security boundary between different organizational units sharing the infrastructure.
To mitigate this risk and ensure robust security posture, organizations running Hatchet must upgrade to version 0.106.1 or later where the code has been patched to include proper tenant filtering in the ListSatisfiedEntries method. This update ensures that all queries for durable event logs are strictly scoped to the authenticated user's tenant ID, preventing cross-tenant data leakage regardless of whether valid UUIDs are known. Additionally, administrators should implement defense-in-depth strategies by auditing application logs and error responses to ensure that sensitive identifiers like task or node UUIDs are not inadvertently exposed in plaintext through debug outputs or stack traces. Regular security assessments focusing on multi-tenancy isolation checks can help identify similar flaws in other parts of the platform before they are exploited, ensuring that the integrity of data segregation remains intact across all operational workflows and AI agent executions managed by the system.