Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
7 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
SSRF via Unsigned UnsubscribeURL in SNS UnsubscribeConfirmation Handler in github.com/hatchet-dev/hatchet
Recommended action: Upgrade to 0.91.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Unauthenticated OAuth state CSRF via empty-state collision in ValidateOAuthState in github.com/hatchet-dev/hatchet
Recommended action: Upgrade to 0.91.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Cross-tenant disclosure risk on DurableTask bidi RPC This is a low-severity, low-risk cross-tenant data exposure vuln caused by blindly accepting a durable task id, in addition to a list of node and branch ids that identify records in that task's event log, and returning them to the caller via the handleWorkerStatus polling path. Impact This advisory requires an attacker to successfully guess a durable task's external uuid belonging to another tenant. External ids are generated uuid v4s (uuid.New() in Go), 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: Hatchet Cloud (multi-tenant SaaS) Self-hosted Hatchet with multiple internal teams / business units sharing one instance Any deployment where a single tenant's API token can be…
Recommended action: Upgrade to 0.106.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 taskexternalid 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. Impact 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,…
Recommended action: Upgrade to 0.95.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The GET /api/v1/stable/durable-tasks/{durable-task} endpoint (listDurableEventLog) is missing tenant authorization validation, allowing any authenticated user to read durable task event logs from any tenant. Impact This CVE requires the attacker to successfully guess the target UUID. Any authenticated Hatchet user can read durable task event logs from any other tenant, exposing: - Task display names and workflow identifiers - User messages (may contain sensitive business data) - Wait conditions and branching logic - Timing information
Recommended action: Upgrade to 0.91.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/hatchet-dev/hatchet >= 0.40.0, < 0.91.2
Fixed in
0.91.2· Vendor fix available
Issue
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…
Recommended action: Upgrade to 0.91.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A missing authorization directive on the GET /api/v1/stable/dags/tasks endpoint caused Hatchet's tenant-membership check to be skipped for this route. A user authenticated to any tenant on the same Hatchet instance could query the endpoint with another tenant's UUID and a DAG UUID belonging to that tenant, and receive task metadata for that DAG. This issue has been patched in v0.83.39. Hatchet Cloud has been patched and requires no action from users. Self-hosted users should upgrade. Impact Who is affected. Multi-tenant Hatchet instances reachable by an attacker who can obtain an account on that instance. On Hatchet Cloud, account creation is open by default. On self-hosted instances, the API must be reachable by the attacker and the hostname known; instances deployed inside a VPC or with signup restricted are not exposed to arbitrary external actors. Prerequisites for exploitation. An attacker needed: 1. An account on the target Hatchet instance. 2. The victim tenant's UUID.…
Recommended action: Upgrade to 0.83.39 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.