CVE-2026-54746: Hatchet: Cross-tenant write/DoS to other tenants' workers via Dispatcher gRPC UpsertWorkerLabels and Unsubscribe
Summary
A cross-tenant write / DoS vulnerability in the Hatchet Dispatcher gRPC service allows any holder of a normal tenant-scoped API token (the lowest credential Hatchet issues — an OWNER of a brand-new tenant) to overwrite the affinity labels of, or disconnect from the dispatcher, any worker UUID belonging to any other tenant on the same Hatchet instance. The two affected RPCs — Dispatcher/UpsertWorkerLabels and Dispatcher/Unsubscribe — read the caller's tenant from the bearer-token context only for analytics and response shaping, and never use it to authorise the workerid from the request body.
Impact This CVE requires the attacker to successfully guess the target UUID. Who is impacted. Any Hatchet deployment that hosts more than one tenant on the same instance: - Hatchet Cloud (multi-tenant SaaS) — every tenant is exposed to every other tenant. - Self-hosted Hatchet with multiple internal teams / business units sharing one instance — each team is exposed to every other team on the box. - Any deployment where a single tenant's API token can be obtained by an attacker (e.g. a leaked low-privilege CI token from a single tenant). One token is enough to attack every other tenant on the same instance.
Single-tenant self-hosted deployments are unaffected in practice (the "victim" and "attacker" tenants would be the same).
Other sources
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.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
go/github.com/hatchet-dev/hatchetto a version that resolves this vulnerability.Fixed in 0.91.2 - Upgrade
Upgrade
Hatchetto a version that resolves this vulnerability.Fixed in 0.91.1
Event History
Frequently Asked Questions
Which deployments are exposed?
Deployments that host multiple tenants on the same Hatchet instance are exposed, including Hatchet Cloud and self-hosted instances shared by multiple internal teams or business units. A single-tenant deployment is not identified as affected by the cross-tenant scenario described.
What does an attacker need to exploit this issue?
The attacker needs a valid tenant-scoped API token, including the lowest-level credential issued to an OWNER of a newly created tenant, and must successfully guess the target worker UUID. No interaction from the target tenant is required.
What can an attacker do after finding a target worker UUID?
They can overwrite that worker's affinity labels or unsubscribe it from the dispatcher, even if the worker belongs to another tenant on the same instance. This can cause cross-tenant integrity impact and denial of service.