EUVD-2026-34064
GHSA-qp9q-4rh4-m8jc
Severity by source
CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L
Primary rating from NVD.
CVSS VectorNVD
CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Lifecycle Timeline
3DescriptionCVE.org
A flaw has been found in dask up to 3.0. Affected by this issue is the function nunique_approx of the file dask/dataframe/hyperloglog.py of the component HLL Handler. This manipulation causes resource consumption. The attack is possible to be carried out remotely. A high degree of complexity is needed for the attack. The exploitation is known to be difficult. The pull request to fix this issue awaits acceptance.
AnalysisAI
Resource exhaustion in Dask up to version 3.0 allows authenticated remote attackers to trigger excessive resource consumption via the nunique_approx function in the HyperLogLog (HLL) handler component. The root cause is a HashDoS vulnerability - adversarially crafted string or object-type input values can be engineered to collide within the 32-bit hash space used for approximate distinct counting and shuffle partitioning, causing partition hotspotting and disproportionate CPU/memory load on worker nodes. No public exploit code exists at time of analysis, and the CVSS score of 3.1 (Low) with AC:H and A:L confirms limited real-world availability impact absent a targeted, high-complexity effort.
Technical ContextAI
The vulnerability resides in Dask's HyperLogLog (HLL) cardinality estimation implementation at dask/dataframe/hyperloglog.py, specifically the nunique_approx function used for approximate distinct counting in distributed DataFrames. Prior to the fix, the HLL algorithm operated on 32-bit hash values (via np.uint32), providing a hash space of approximately 4.3 billion possible values. CWE-400 (Uncontrolled Resource Consumption) applies because an attacker who controls string or object column inputs can engineer values that collide into identical HLL buckets or shuffle partitions, causing disproportionate processing load. The PR diff confirms a dual fix: upgrading hash computation from 32-bit to 64-bit (np.uint64) to drastically expand the collision-resistant hash space, and introducing a configurable dataframe.shuffle.hash-key option that passes a randomized key to pd.util.hash_pandas_object for string/object columns, neutralizing adversarial hash prediction. CPE data cpe:2.3:a:n/a:dask:*:*:*:*:*:*:*:* covers all Dask versions up to 3.0.
RemediationAI
The upstream fix is available as GitHub Pull Request #12401 (https://github.com/dask/dask/pull/12401), but this PR had not yet been merged into a tagged release at time of analysis - this constitutes an upstream fix available at PR/commit level with no independently confirmed patched release version. Monitor the Dask repository and upgrade promptly once a patched release is published. As an immediate compensating control, the proposed fix introduces the dataframe.shuffle.hash-key configuration option: set this to a random 16-character string via dask.config.set({'dataframe.shuffle.hash-key': '<random-16-char-string>'}) or via the dask.yaml configuration file to randomize hash outputs for string and object columns, directly mitigating HashDoS-style partition hotspotting. The trade-off is that enabling a custom hash key alters hash outputs and may affect determinism in reproducibility-sensitive or hash-order-dependent workflows. Advisory details are available via VulDB at https://vuldb.com/cve/CVE-2026-10705.
Same weakness CWE-400 – Uncontrolled Resource Consumption
View allSame technique Denial Of Service
View allVendor StatusVendor
SUSE
Severity: LowShare
External POC / Exploit Code
Leaving vuln.today