Clevis PKCS#11 EUVD-2026-101021

Requires the system to be using clevis with the PKCS#11 pin and the clevis-pkcs11-afunix-socket-unlock daemon, which must have run and logged at least one LUKS unlock passphrase; the daemon creates its log file without restrictive permissions, leaving it world-readable under the default umask. The attacker must already have a local, authenticated low-privileged account (PR:L) on the affected host to read that file - there is no remote vector and no user interaction. Limiting factors: this is a specific, non-default disk-unlock configuration, not a base RHEL default, and exploitation is confined to hosts where this pin is actively in use; no exploitation is possible without prior local access.

This is a genuine but moderate, locally-scoped information-disclosure issue rather than a high-urgency remote threat. The Red Hat CVSS vector (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, base 5.5) is internally consistent with the description: exploitation requires an existing local, low-privileged account (PR:L), there is no remote vector (AV:L), and the only impact is confidentiality (C:H) via disclosure of the LUKS passphrase, with no integrity or availability effect. No EPSS score, CISA KEV listing, or SSVC decision data was supplied, and no public exploit is referenced - consistent with a newly-published vendor-reported flaw. The confidentiality impact is serious in principle (a disk-encryption passphrase is a crown-jewel secret), but exploitation is gated by prior local access and by the system actually using the clevis PKCS#11 afunix-socket-unlock configuration, so real-world risk is bounded. No signals conflict; the main caveat is simply the absence of exploitation-probability data (EPSS/KEV/POC all unknown), so prioritization should rest on CVSS and the local-access precondition rather than on evidence of active exploitation.

On a RHEL system configured to unlock LUKS volumes via the clevis PKCS#11 pin, the clevis-pkcs11-afunix-socket-unlock daemon writes the LUKS passphrase in cleartext to a log file created world-readable under the default umask. An unprivileged local user (for example a low-privilege service or shell account) simply reads that log file and recovers the disk-encryption passphrase. No public exploit code is referenced and none is needed - reading a readable file suffices.