CVE-2026-47134 in clearancekit
Summary
by MITRE • 07/21/2026
ClearanceKit intercepts file-system access events on macOS and enforces per-process access policies. The ECDSA private key used to sign the on-disk policy database (`/Library/Application Support/clearancekit/store.db`) is stored in the macOS System Keychain. The key was created via the two-step pattern `SecKeyCreateRandomKey` (in-memory) followed by `SecItemAdd(kSecValueRef:, kSecAttrAccess:)` (persist). Prior to version 5.0.10, for `kSecClassKey` items in the legacy System Keychain, `kSecAttrAccess` passed to `SecItemAdd` is silently ignored — the persisted key inherits no ACL restriction. The same access builder applied to `kSecClassGenericPassword` items correctly binds the ACL, making this bug specific to the EC key. The result is that any process running as root can use the key to produce valid signatures over arbitrary policy content. Version 5.0.10 fixes the issue. No known workarounds are available. Disabling the system extension and manually removing the System Keychain item labelled `clearancekit policy signing key` would prevent the forged-signature path but also disables policy enforcement.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 07/21/2026
The ClearanceKit vulnerability represents a critical security flaw in macOS access control enforcement mechanisms that stems from improper handling of cryptographic key storage within the System Keychain. This software solution intercepts file system events and enforces process-specific access policies, making it a core component of system security controls. The system employs ECDSA signatures to validate policy databases stored at /Library/Application Support/clearancekit/store.db, creating a trust boundary that relies entirely on the secrecy and integrity of the signing key. The cryptographic infrastructure uses a two-step key generation process that begins with SecKeyCreateRandomKey to create an in-memory key and subsequently stores it persistently using SecItemAdd with kSecValueRef and kSecAttrAccess parameters.
The vulnerability manifests specifically within the legacy System Keychain implementation where the kSecAttrAccess parameter passed to SecItemAdd for kSecClassKey items is silently ignored during persistence operations. This represents a fundamental failure in access control enforcement that directly contradicts established security principles and standards such as those defined in CWE-284 Access Control. The flaw exists because macOS legacy keychain handling does not properly apply the specified access controls to cryptographic keys, allowing the persisted ECDSA private key to inherit no access restrictions despite explicit ACL specifications during creation. This vulnerability is particularly dangerous because it affects only the specific key class while maintaining correct behavior for generic password items, creating an inconsistent and exploitable security boundary.
The operational impact of this vulnerability extends beyond simple privilege escalation to compromise the entire policy enforcement mechanism that ClearanceKit provides. Any process running with root privileges can extract the unprotected private key from the System Keychain and use it to generate valid signatures over arbitrary policy content, effectively allowing attackers to bypass all access controls implemented by the system extension. This creates a complete breakdown of the security model where the attacker can modify policy databases without detection, potentially enabling persistent backdoor access or complete system compromise. The vulnerability represents a direct violation of the principle of least privilege and undermines the cryptographic integrity that should protect critical system configuration data.
Security mitigations for this vulnerability require careful consideration of both immediate remediation and long-term architectural improvements. Version 5.0.10 addresses the core issue by properly implementing access control restrictions for cryptographic keys in the legacy System Keychain, ensuring that kSecAttrAccess parameters are correctly applied during key persistence operations. However, organizations must understand that this fix requires careful deployment planning as the system extension will need to be updated and validated across all affected systems. The lack of known workarounds means that administrators cannot simply disable policy enforcement without potentially compromising their security posture, creating a challenging operational scenario where complete removal of the system extension would eliminate both the vulnerability and the intended security controls. This situation highlights the importance of proper key management practices and adherence to established security frameworks such as those recommended in NIST SP 800-57 for cryptographic key lifecycle management.
The technical nature of this vulnerability aligns with ATT&CK technique T1552.001 Credential Access: Credentials In Files, as it involves unauthorized access to stored cryptographic credentials within the system keychain. The exploitability characteristics make this a high-severity issue that would likely be detected by security monitoring systems during routine audit activities, particularly those focused on privilege escalation attempts or unusual cryptographic operations. Organizations should implement comprehensive monitoring for keychain access patterns and signature validation operations to detect potential exploitation attempts. The root cause demonstrates a failure in proper API usage and security boundary enforcement that could be prevented through better adherence to secure coding practices and more rigorous testing of cryptographic implementations against established security standards.