Go · github.com/hatchet-dev/hatchet
Hatchet: Cross-tenant durable callback payload disclosure in Hatchet V1 Dispatcher
The V1 DurableTask stream handler registers worker-supplied durable task external IDs in an in-memory callback routing map before verifying that the authenticated tenant owns the task. If the tenant-scoped ownership check fails, the handler logs the error and continues, but the map entry persists until the stream closes.
Durable callback delivery resolves the destination stream by task_external_id only, without checking tenant identity. As a result, a tenant A worker that knows a tenant B durable task external UUID can hold its stream open and receive tenant B's durable callback result payload when the callback is delivered on the same dispatcher process.
This advisory requires an attacker to successfully guess a durable task external UUID belonging to another tenant. Durable task external IDs are generated with uuid.New() (UUIDv4) and are not enumerable across tenants, so exploitation requires prior knowledge of a target task UUID through an out-of-band channel. Thus, while the following environments are impacted, there is an extremely low probability it would be exploited.
Who is impacted. Any Hatchet deployment that hosts more than one tenant on the same instance:
Single-tenant self-hosted deployments are unaffected in practice (the "victim" and "attacker" tenants would be the same).
Is your project exposed to this? Stateward checks every dependency on every pull request and flags it only if your code actually reaches it.
Check my repoSources: CISA KEV (public domain), OSV.dev & GitHub Advisory Database (CC-BY-4.0), FIRST EPSS, NVD/CWE (public domain). Served live from the Stateward advisory database.