Hatchet EUVD-2026-83979

Exploitation requires ALL of the following: (1) a multi-tenant Hatchet deployment running a version prior to 0.95.3 - single-tenant deployments are unaffected in practice; (2) valid authenticated tenant-worker credentials (PR:L); (3) prior knowledge of a victim tenant's durable task UUID, which is a non-enumerable UUIDv4 and therefore cannot be brute-forced or guessed (must be obtained out-of-band); and (4) the attacker's DurableTask stream must be held open on the SAME dispatcher process that is handling the victim's durable task, so that the tenant-blind durableInvocations routing map delivers the callback to the attacker. These conditions - non-enumerable identifier plus same-process co-location timing - are the primary limiting factors (AC:H) and confine exploitation to targeted rather than opportunistic attacks; impact is confidentiality-only (leak of the durable callback result payload).

This is a genuine but low-priority multi-tenant confidentiality flaw, and the signals are consistent rather than conflicting. The vendor CVSS 3.1 score of 3.1 (AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N) accurately reflects a narrow, high-complexity, authenticated-only issue with limited (low) confidentiality impact and no integrity or availability effect - I concur with this vector. AC:H is well justified: the description explicitly states UUIDv4 task identifiers are not enumerable, and successful exploitation additionally requires the attacker's stream to remain open on the SAME dispatcher process handling the victim's callback, a race/co-location condition the attacker cannot reliably force. No EPSS score, no CISA KEV listing, and no public POC are present in the input; the fix commit (9555bfdd) is confirmed but does not constitute an exploit. Net: this is a real defect worth patching for multi-tenant/SaaS Hatchet operators, but it is NOT a high-real-risk issue - it is a low-CVSS flaw whose low score correctly matches its constrained, targeted exploitation profile. The single-tenant caveat further shrinks the exposed population.

A malicious but legitimately authenticated tenant on a shared multi-tenant Hatchet deployment obtains another tenant's durable task UUID (e.g., leaked via logs, a chained info-disclosure bug, or an insider) and opens a DurableTask stream on the dispatcher process that is servicing the victim's task. Because the durableInvocations routing map is keyed only by task UUID without tenant identity, the victim's durable callback result payload is delivered to the attacker's stream. No public exploit code was identified at time of analysis, and the non-enumerable UUID plus same-process co-location requirement make this opportunistic and targeted rather than mass-exploitable.