Threat Intelligence Database

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.

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.

ClearanceKit intercepts file-system access events on macOS and enforces per-process access policies. Prior to 5.0.6, the opfilter Endpoint Security system extension (bundle ID uk.craigbass.clearancekit.opfilter) can be suspended with SIGSTOP or kill -STOP, or killed with SIGKILL/SIGTERM, by any process running as root. While the extension is suspended, all AUTH Endpoint Security events time out and default to allow, silently disabling ClearanceKit's file-access policy enforcement for the duration of the suspension. This vulnerability is fixed in 5.0.6.

ClearanceKit intercepts file-system access events on macOS and enforces per-process access policies. Prior to 5.0.5, ClearanceKit incorrectly treats a process with an empty Team ID and a non-empty Signing ID as an Apple platform binary. This bug allows a malicious software to impersonate an apple process in the global allowlist, and access all protected files. This vulnerability is fixed in 5.0.5.

ClearanceKit intercepts file-system access events on macOS and enforces per-process access policies. Prior to 5.0.4-beta-1f46165, ClearanceKit's Endpoint Security event handler only checked the source path of dual-path file operations against File Access Authorization (FAA) rules and App Jail policies. The destination path was ignored entirely. This allowed any local process to bypass file-access protection by using rename, link, copyfile, exchangedata, or clone operations to place or replace files inside protected directories. This vulnerability is fixed in 5.0.4-beta-1f46165.

ClearanceKit intercepts file-system access events on macOS and enforces per-process access policies. Prior to version 4.2.14, two related startup defects created a window during which only the single compile-time baseline rule was enforced by opfilter. All managed (MDM-delivered) and user-defined file-access rules were not applied until the user interacted with policies through the GUI, triggering a policy mutation over XPC. This issue has been patched in version 4.2.14.

CVE-2026-33632 is a high-severity vulnerability in ClearanceKit versions prior to 4.2.4 on macOS. The vulnerability arises because two file operation event types, ES_EVENT_TYPE_AUTH_EXCHANGEDATA and ES_EVENT_TYPE_AUTH_CLONE, were not intercepted by ClearanceKit's opfilter system extension. This omission allows local processes to bypass the file access policies enforced by ClearanceKit. The issue is addressed in version 4.2.4 by subscribing to these event types and routing them through the policy evaluator. Users must upgrade to version 4.2.

ClearanceKit intercepts file-system access events on macOS and enforces per-process access policies. In versions on the 4.1 branch and earlier, the opfilter Endpoint Security system extension enforced file access policy exclusively by intercepting ES_EVENT_TYPE_AUTH_OPEN events. Seven additional file operation event types were not intercepted, allowing any locally running process to bypass the configured FAA policy without triggering a denial. Commit a3d1733 adds subscriptions for all seven event types and routes them through the existing FAA policy evaluator. AUTH_RENAME and AUTH_UNLINK additionally preserve XProtect change detection: events on the XProtect path are allowed and trigger the existing onXProtectChanged callback rather than being evaluated against user policy. All versions on the 4.2 branch contain the fix. No known workarounds are available.