OpenZFS EUVD-2026-66419

Two conditions must both be true simultaneously. First, the local user must be able to open /dev/zfs - on most Linux distributions the device is world-readable/writable or accessible to the 'disk' or 'zfs' group by default, but site-hardened systems that have restricted this permission are not exploitable via this path. Second, the kernel must permit unprivileged user namespace creation; this is controlled by kernel.unprivileged_userns_clone (Debian/Ubuntu) or user.max_user_namespaces sysctl and is enabled by default on Ubuntu 22.04+, Debian 11+, and most enterprise Linux distributions. No prior access to any ZFS pool or underlying block device is required. Exploitation is limited to local users with an interactive or programmatic shell session; remote exploitation requires a separate initial access vector. The condition that limits exploitation most in practice is the device permission on /dev/zfs - environments that have restricted it to root-only or a privileged group break the attack entirely without requiring a kernel parameter change.

The CVSS 4.0 score of 7.3 with vector AV:L/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H reflects accurate severity: local access with low privilege suffices, there is no user interaction, and all three CIA pillars are high within the vulnerable system. The AT:P (attack target: present) metric flags the one meaningful precondition - the kernel must allow unprivileged user namespace creation - which is enabled by default on Ubuntu, Debian, and most modern Linux server distributions, reducing that gate substantially. No KEV listing exists, meaning CISA has not confirmed active exploitation, and no public exploit code has been identified in the provided data. EPSS data is absent from the input and cannot be cited. Despite the absence of active exploitation indicators, the real-world risk is non-trivial: the attack requires no special tools beyond standard Linux utilities (unshare -Ur), the steps are mechanical and repeatable, and the impact allows a local user to destroy storage pools or inject faults - consequences that are catastrophic and difficult to recover from. Systems where untrusted local users exist (multi-tenant environments, shared compute, container hosts where user namespace creation is unrestricted) should treat this as a high-priority patch. Single-tenant or air-gapped storage appliances where no unprivileged shell access is granted to non-admin users have materially reduced exposure.

An unprivileged user on a multi-user Linux server runs 'unshare -Ur zpool destroy tank' from their shell session. Within the new user namespace, the kernel grants them CAP_SYS_ADMIN scoped to that namespace; OpenZFS's ioctl handler accepts this as sufficient authorization and proceeds to destroy the production ZFS pool 'tank' without any further authentication. No root password, sudo rights, or prior ZFS access is required - only a valid local shell account and the ability to open /dev/zfs.