CVE-2026-42572

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.

Root cause

Hatchet's multi-tenant authorization relies on an OpenAPI-driven middleware pipeline. Each authenticated operation declares x-resources: ["tenant", ...] in its spec. The populator middleware reads the declared resources, looks up the corresponding entities from request parameters, and stores them on the request context. The authz middleware then verifies that the authenticated user is a member of the tenant found on the context.

The listTasksByDAGIds operation accepted a tenant UUID as a query parameter, but its OpenAPI definition did not declare x-resources: ["tenant"]. As a result:

1. The populator, which early-returns when no resources are declared, did not populate the tenant onto the request context.
2. The authz middleware, which runs its membership check only when a tenant is present on the context, silently passed the request through.
3. The handler read the tenant UUID directly from the query parameter and used it as the filter in the downstream OLAP query.

The SQL query itself correctly filters by tenant_id, so it returned only rows matching the supplied UUID, but the UUID came from the caller rather than from an authorization-validated context, so the filter bounded the response to the attacker-named tenant rather than to a tenant the caller was authorized to read.

Every other authenticated operation in the same path file (tasks.yaml) correctly declared x-resources. This endpoint was the only authenticated operation in the file that did not.

Remediation

Hatchet Cloud. No action required. The patch was deployed on April 23, 2026 within the same day it was reported.

Self-hosted, recommended. Upgrade to v0.83.39 or later.

Self-hosted, if you cannot upgrade immediately. Either of the following reduces exposure until you can upgrade:

• Restrict account creation by setting SERVER_AUTH_RESTRICTED_EMAIL_DOMAINS to an allowlist of domains you control. This prevents arbitrary users from registering an account on your instance, which removes the most common path to the prerequisite account.
• Ensure the Hatchet API is not exposed to untrusted networks. We generally recommend running Hatchet inside a VPC and fronting the API with authenticated network controls; deployments configured this way were not reachable by arbitrary external attackers.

Timeline

All times April 23, 2026.

• 14:05, Reported to Hatchet.
• 16:28, Patch deployed to Hatchet Cloud and released as v0.83.39.
• Public disclosure, this advisory.

Credit

Reported by @sajdakabir.

Hatchet thanks the reporter for responsibly disclosing this issue and for the clear, reproducible writeup.

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.
3. At least one DAG UUID (external_id) belonging to that tenant.

The two UUIDs are not treated as secrets, they appear in URLs, API responses, audit logs, invitation flows, shared run links, and dashboard screenshots, but an attacker does need to learn them through some out-of-band channel before exploitation is possible.

What could be disclosed. For each child task of a targeted DAG, the endpoint returned:

• display_name, action_id, step_id
• workflow_id, workflow_version_id, workflow_run_id, task_external_id
• tenant_id, retry_count, status, timestamps
• additional_metadata (JSON)

The additional_metadata field is the most sensitive: Hatchet workflows commonly use it to carry domain context such as user identifiers, customer IDs, feature flags, or correlation tokens. Its contents vary by deployment.

What was not disclosed. The raw task input payload is not part of this endpoint's response shape and was not exposed through this issue. The scope is limited to task metadata, not task arguments or results.

Exploitation status. We have no evidence that this vulnerability was exploited prior to the patch.

The application does not correctly enforce access controls, allowing a principal to access resources or operations beyond their granted permissions. Typical impact: unauthorized data access or execution of privileged operations.

CVE-2026-42572 has a CVSS score of 5.3 (Medium). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.83.39); upgrading removes the vulnerable code path.

Kodem intelligence

The fix adds the missing resource authz checks inline on the handler, enforcing valid tenant membership before the handler runs.

Shipped in v0.83.39.

1. What is CVE-2026-42572? CVE-2026-42572 is a medium-severity incorrect authorization vulnerability in github.com/hatchet-dev/hatchet (go), affecting versions <= 0.83.38. It is fixed in 0.83.39. The application does not correctly enforce access controls, allowing a principal to access resources or operations beyond their granted permissions.
2. How severe is CVE-2026-42572? CVE-2026-42572 has a CVSS score of 5.3 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of github.com/hatchet-dev/hatchet are affected by CVE-2026-42572? github.com/hatchet-dev/hatchet (go) versions <= 0.83.38 is affected.
4. Is there a fix for CVE-2026-42572? Yes. CVE-2026-42572 is fixed in 0.83.39. Upgrade to this version or later.
5. Is CVE-2026-42572 exploitable, and should I be worried? Whether CVE-2026-42572 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-42572 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-42572? Upgrade github.com/hatchet-dev/hatchet to 0.83.39 or later.