Hatchet EUVD-2026-83980

Requires a multi-tenant Hatchet deployment (single-tenant installs are explicitly unaffected) prior to version 0.106.1, plus an authenticated tenant worker that can reach the WorkerStatus gRPC polling path. The attacker must already possess or guess a victim tenant's durable-task UUIDv4 - the 122-bit random identifier is the primary limiting factor, per the vendor 'exploitation unlikely' note, and cannot be practically enumerated. Impact is limited to reading durable event-log records; no write, execution, or availability impact.

This is a genuine but low-priority cross-tenant information-disclosure flaw (CWE-639 IDOR), not a critical issue. The vendor CVSS of 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) correctly captures confidentiality-only impact with no integrity or availability effect. No EPSS score, KEV listing, POC, or SSVC decision data is present in the input, so exploitation-probability signals are absent rather than conflicting. The one internal tension: the CVSS vector rates AC:L, but the vendor's own description states the UUIDv4 requirement 'makes exploitation unlikely' - an unguessable 122-bit random identifier is a real barrier, which argues for AC:H and lowers realistic risk below the raw score. Exploitation is further bounded by requiring an authenticated tenant worker (PR:L) and a multi-tenant deployment; single-tenant installs are explicitly unaffected. Net: a real defense-in-depth authorization gap worth patching on a normal cycle, not an emergency.

An authenticated worker in tenant A that has somehow learned or captured tenant B's durable-task UUIDv4 (e.g. from logs, a shared integration, or a leaked identifier) issues WorkerStatus gRPC polls supplying that UUID. Because ListSatisfiedEntries omits a tenant filter, Hatchet returns tenant B's matching durable event-log records to tenant A. No public exploit identified at time of analysis; the UUIDv4 requirement makes opportunistic exploitation unlikely and points to targeted abuse rather than mass scanning.