CVE-2026-26104: 
NixOS vulnerability analysis and mitigation

CVE-2026-26104 is a missing authorization vulnerability in the udisks storage management daemon that allows unprivileged local users to back up LUKS encryption headers without proper authorization. The flaw was reported on January 28, 2026, and publicly disclosed on February 25, 2026. It affects udisks2 versions >= 2.10.90 (patched in 2.11.1) and Red Hat Enterprise Linux 10.0, with fixes also shipped for downstream distributions including Fedora, Rocky Linux, AlmaLinux, and openSUSE. The vulnerability carries a CVSS v3.1 base score of 5.5 (Medium) (Red Hat CVE, GitHub Advisory).

The root cause is a missing authorization check (CWE-862) in the handle_header_backup() function of the udisks daemon. Specifically, the org.freedesktop.UDisks2.Encrypted.HeaderBackup D-Bus method does not call udisks_daemon_util_check_authorization_sync() (the polkit authorization check), meaning any local user can invoke this privileged system-bus method without authentication. When called, the root-owned udisksd process executes bd_crypto_luks_header_backup(), reading the LUKS header and keyslot metadata from a device and writing it to an attacker-specified file path. No user interaction is required; the attacker only needs a low-privilege local account (Red Hat Bugzilla, GitHub Advisory).

Successful exploitation allows a low-privileged local attacker to exfiltrate LUKS encryption headers and keyslot metadata to an attacker-controlled file path, without any authentication or user interaction. The exported LUKS header contains the encrypted master key material, which can be used in offline brute-force or dictionary attacks against the passphrase to ultimately decrypt the protected volume. This directly undermines the confidentiality guarantees of LUKS-encrypted storage, potentially exposing all data on the encrypted volume. There is no integrity or availability impact, but the confidentiality impact is rated High (Red Hat CVE, GitHub Advisory).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation at this time. The EPSS score is approximately 0.007% (0.000070), indicating a very low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires only a low-privilege local account and no user interaction, making it straightforward for any local user on an affected system to attempt (Red Hat CVE, GitHub Advisory).

1. Gain local access: Obtain a low-privilege local user account on a system running a vulnerable version of udisks2 (>= 2.10.90, unpatched) with LUKS-encrypted storage volumes present.
2. Identify target device: Enumerate block devices with LUKS encryption using standard tools (e.g., lsblk, blkid) to identify the target encrypted device (e.g., /dev/sda2).
3. Invoke the vulnerable D-Bus method: Use a D-Bus client tool such as gdbus or dbus-send to call the org.freedesktop.UDisks2.Encrypted.HeaderBackup method on the target device object without any authorization prompt:

gdbus call --system \
  --dest org.freedesktop.UDisks2 \
  --object-path /org/freedesktop/UDisks2/block_devices/sda2 \
  --method org.freedesktop.UDisks2.Encrypted.HeaderBackup \
  '/tmp/attacker_luks_backup' \
  '{"auth.no_user_interaction": <true>}'

4. Retrieve the LUKS header backup: The root-owned udisksd daemon writes the LUKS header and keyslot metadata to the specified attacker-controlled path (e.g., /tmp/attacker_luks_backup) without performing any polkit authorization check.
5. Conduct offline attack: Use the exported LUKS header with tools such as hashcat or john to perform offline brute-force or dictionary attacks against the passphrase, potentially recovering the master key and decrypting the volume (Red Hat Bugzilla, GitHub Advisory).

• Logs: D-Bus system log entries (e.g., in /var/log/messages or via journalctl) showing calls to org.freedesktop.UDisks2.Encrypted.HeaderBackup from non-root, unprivileged users; absence of corresponding polkit authorization prompts or denials.
• File System: Unexpected LUKS header backup files (binary files with LUKS magic bytes 4C554B53 BABE) appearing in world-writable directories such as /tmp, /dev/shm, or user home directories; files owned by root but readable by a non-root user.
• Process: Unusual invocations of udisksd or bd_crypto_luks_header_backup visible in process audit logs; auditd records showing file write operations by the udisks daemon to attacker-controlled paths.
• Network: Subsequent outbound file transfer activity (e.g., scp, curl, wget) from the compromised host shortly after a suspicious D-Bus call, potentially exfiltrating the LUKS header backup.

Red Hat has released patched packages addressing this vulnerability. For RHEL 10, apply the update via RHSA-2026:3476 (udisks2-2.10.90-6.el10_1.1), issued March 2, 2026. For RHEL 10.0 Extended Update Support, apply RHSA-2026:5831 (udisks2-2.10.90-5.el10_0.2), issued March 25, 2026. The upstream fix is available in udisks2 version 2.11.1. Patches have also been released for Fedora 43, Fedora 44, Rocky Linux, AlmaLinux, and openSUSE. As a workaround where patching is not immediately possible, restrict local user access and monitor D-Bus method calls to udisks for suspicious HeaderBackup invocations (RHSA-2026:3476, RHSA-2026:5831, GitHub Advisory).

Red Hat rated this vulnerability as "Important" severity in their security advisories, despite the CVSS score of 5.5 (Medium), reflecting the sensitive nature of LUKS cryptographic material exposure (RHSA-2026:3476). The upstream udisks project (storaged-project) published a GitHub Security Advisory crediting the finder "manizada" for the discovery (GitHub Advisory). The storaged.org project blog also noted the use of LLM-assisted code review in identifying security issues in the codebase around the same period, suggesting increased scrutiny of the udisks codebase.