CVE-2026-109970 in Red Hat
Summary
by MITRE • 10/14/2026
A flaw was found in the clevis PKCS#11 pin. The clevis-luks-pkcs11-askpin script writes the PKCS#11 token PIN in plaintext to a file without setting restrictive permissions. Under the default process umask, the file is world-readable. Additionally, the PIN file is not reliably cleaned up if the decryption script exits early, leaving the PIN accessible indefinitely.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/14/2026
The vulnerability identified within the clevis PKCS#11 pin handling mechanism represents a critical failure in secure credential management and operating system permission enforcement. Clevis is an automated encryption tool that integrates with LUKS to provide transparent disk decryption using various backends, including hardware security modules via PKCS#11. The specific flaw resides in the clevis-luks-pkcs11-askpin script, which is responsible for retrieving and managing the PIN required to unlock a PKCS#11 token during the decryption process. When this script executes, it writes the sensitive PIN value directly into a temporary file on the local filesystem without explicitly defining restrictive access permissions. This oversight relies entirely on the default system umask setting rather than implementing explicit security controls within the application logic itself.
Under standard Linux operating systems, the default umask typically allows world-readable and writable permissions for newly created files if not overridden by specific policy or configuration. Consequently, any user account on the local system can read the contents of this temporary file containing the plaintext PIN. This behavior violates fundamental security principles regarding the protection of authentication credentials. The vulnerability is classified under CWE-732 as improper permission assignment for critical resource, specifically where a sensitive data file is created with overly permissive access rights that expose it to unauthorized entities within the same trust boundary.
The operational impact of this flaw extends beyond simple credential exposure during active decryption sessions. A secondary but equally severe issue involves the lifecycle management of these temporary files. The script does not reliably clean up or delete the PIN file if the decryption process exits early due to errors, timeouts, or user interruption. This lack of robust cleanup logic means that plaintext credentials can persist on the disk indefinitely after they are no longer needed for their intended purpose. An attacker with local access could scan common temporary directories such as /tmp or specific clevis cache locations to locate these orphaned files and extract the PIN without triggering any alarms or requiring active exploitation during a decryption event.
This vulnerability aligns with ATT&CK technique T1552, specifically Unsecured Credentials: Private Key, although it applies broadly to other sensitive authentication material like PINs. It also relates to T1083 File and Directory Discovery if an attacker is actively searching for these files. The persistence of the plaintext PIN allows for potential lateral movement or privilege escalation scenarios where an adversary could use the extracted key material to decrypt volumes on behalf of legitimate users, bypassing hardware security constraints that PKCS#11 tokens are designed to enforce. It effectively reduces a high-assurance hardware-backed authentication method back to a weak software-based secret stored in plaintext.
Mitigation strategies must address both the immediate permission issues and the long-term cleanup failures. The most effective remediation involves modifying the clevis-luks-pkcs11-askpin script to explicitly set restrictive file permissions, such as 0600 or 0400, immediately upon creation of the temporary PIN file using system calls like chmod. This ensures that only the owner and potentially specific privileged groups can access the credential regardless of the global umask settings. Furthermore, developers must implement robust signal handling and exit traps to guarantee that the temporary files are deleted in all execution paths, including error conditions and early exits. Utilizing secure temporary file creation functions provided by standard libraries, which often handle permissions and cleanup automatically, is a recommended best practice for preventing such vulnerabilities. System administrators should also audit their environments for any existing instances of these orphaned PIN files and remove them manually until patches are applied.