GHSA-8x7x-83cf-c3pg: Medium severity go/github.com/hatchet-dev/hatchet vulnerability
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).
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
Event History
Frequently Asked Questions
What does an attacker need to exploit this issue?
The attacker needs a valid tenant-scoped Hatchet API token, including the lowest-level token issued to an OWNER of a newly created tenant, and must successfully guess the target worker UUID. No user interaction is required.
Which deployments have cross-tenant exposure?
Deployments hosting 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 token compromised from one tenant, such as a leaked low-privilege CI token, can be used against workers belonging to another tenant on that instance.
What could an attacker do to a targeted worker?
An attacker can overwrite the worker's affinity labels through Dispatcher/UpsertWorkerLabels or disconnect it from the dispatcher through Dispatcher/Unsubscribe. The affected RPCs do not authorize the requested worker_id against the caller's tenant.