Dask EUVD-2026-34064

Exploitation requires an authenticated attacker (PR:L confirmed by CVSS vector) with the ability to submit data for distributed computation through a Dask DataFrame workflow that invokes nunique_approx (e.g., dask.dataframe.Series.nunique() with approximate mode) or the shuffle path over string/object-typed columns. High attack complexity (AC:H) means the attacker must possess knowledge of Dask's 32-bit hashing algorithm and engineer specific input values to produce predictable hash collisions - this is non-trivial and requires pre-computation effort. Exploitation is further constrained to deployments where adversarial user input can reach the HLL or shuffle execution path; internal batch ETL pipelines operating on fully trusted data are not exploitable. Enabling the dataframe.shuffle.hash-key configuration to a random value eliminates the hash predictability that this attack depends on.

The CVSS 3.1 base score of 3.1 (Low) is well-supported by the vector components: network-accessible (AV:N) but high attack complexity (AC:H), requiring low privileges (PR:L), with only low availability impact (A:L) and no confidentiality or integrity impact. The report confidence is RC:R (Reasonable), meaning vendor confirmation is pending - the fix PR #12401 had not been merged at time of analysis. No EPSS score was provided, and there is no CISA KEV listing, no public exploit code, and exploit maturity is undefined (E:X). Real-world exploitation risk is narrow: it primarily threatens multi-tenant Dask analytics environments where untrusted users can submit arbitrary data for distributed DataFrame operations invoking nunique_approx. Organizations running Dask for internal batch ETL on trusted data sources face negligible practical risk. The AC:H requirement means exploitation is non-trivial and targeted, not opportunistic or automated.

An attacker with low-privileged access to a multi-tenant Dask analytics environment submits a crafted DataFrame containing string values deliberately engineered - using knowledge of the predictable 32-bit hashing algorithm - to collide into the same HyperLogLog buckets or shuffle partitions during a nunique_approx operation. The collision causes specific worker nodes to receive disproportionately large partition workloads, spiking CPU and memory consumption and potentially causing task starvation or worker failure. No public proof-of-concept exploit code has been identified at time of analysis.