CVE-2026-47133 in ClearanceKit
Summary
by MITRE • 07/21/2026
ClearanceKit intercepts file-system access events on macOS and enforces per-process access policies. Prior to version 5.0.10, each table in the on-disk SQLite policy store (`/Library/Application Support/clearancekit/store.db`) is verified using an ECDSA signature stored in the `data_signatures` table. The signed payload contains only the canonical row content, with no version counter or freshness binding. An attacker who can write `store.db` and the matching `data_signatures` row — feasible during the opfilter-update window when the Endpoint Security filter is offline, or via offline-boot / decrypted-backup scenarios — can substitute a previously-captured legitimately-signed snapshot. opfilter accepts the older snapshot as fully valid on next boot because the existing signatures still verify. Version 5.0.10 patches the issue.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 07/21/2026
The ClearanceKit macOS security solution implements a sophisticated policy enforcement mechanism that monitors file system access events and enforces granular per-process access controls. The system maintains its policy configuration in an on-disk SQLite database located at `/Library/Application Support/clearancekit/store.db` which serves as the central repository for all access control rules. This database structure employs a cryptographic signature verification approach where each table within the policy store is protected by ECDSA signatures stored in a dedicated `data_signatures` table. The signature verification process validates the integrity of policy data by ensuring that the canonical row content matches the expected signed payload, creating a trust boundary between the policy store and the enforcement engine.
The vulnerability stems from a critical design flaw in the signature validation mechanism that lacks proper versioning and freshness controls within the signed payloads. Specifically, the ECDSA signatures only encompass the canonical row content without incorporating any version counters or temporal binding elements that would indicate when the data was last modified or validated. This omission creates a window of opportunity for attackers to exploit the system's trust model by substituting older, previously-captured legitimate snapshots of the policy database. The attack scenario becomes feasible during specific operational conditions such as the opfilter-update window when the Endpoint Security filter is temporarily offline, or through offline-boot scenarios where an attacker has physical access to a decrypted backup that can be manipulated to restore an older policy state.
The operational impact of this vulnerability extends beyond simple policy manipulation to potentially compromise the entire security posture of systems relying on ClearanceKit. An attacker with write access to the `store.db` file and corresponding `data_signatures` row can effectively rollback to a previous policy version, potentially restoring access rules that were previously revoked or modified to address known threats. This capability undermines the fundamental principle of least privilege enforcement that ClearanceKit is designed to provide, as the system's opfilter component will accept the older snapshot as fully valid on next boot because the existing signatures still verify correctly against the manipulated data. The vulnerability represents a classic case of insufficient integrity validation where the cryptographic signature does not provide sufficient context about data freshness or version control, making it susceptible to replay attacks.
This security weakness aligns with CWE-347, which addresses improper certificate validation and weak cryptographic signatures that fail to provide adequate integrity guarantees. The flaw also demonstrates characteristics consistent with ATT&CK technique T1566, specifically the use of credential manipulation to maintain persistence and evade detection by restoring compromised system states. The vulnerability's exploitation timeline during the opfilter-update window indicates a potential attack vector that could be leveraged in targeted campaigns where attackers have knowledge of system operational windows. The patch implemented in version 5.0.10 addresses this issue through enhanced signature validation mechanisms that incorporate version counters or temporal freshness indicators, ensuring that policy snapshots cannot be successfully replayed from older states.
The remediation approach taken in version 5.0.10 demonstrates a proper response to the vulnerability by strengthening the cryptographic verification process to include explicit versioning or timestamp information within the signed payloads. This enhancement prevents attackers from successfully substituting older snapshots while maintaining backward compatibility with legitimate policy updates. The fix addresses both operational scenarios mentioned in the vulnerability description, ensuring that even in offline-boot or decrypted-backup situations, the system can detect and reject manipulated policy states that do not conform to current validation requirements, thereby preserving the integrity of the access control enforcement mechanisms.