CVE-2026-47133
MediumCVSS 6.9Exploitation Probability (EPSS)
Low risk1th percentile - higher than 1% of all known CVEs
Summary
In ClearanceKit before version 5.0.10, ECDSA signatures for SQLite database tables lack a version counter or freshness binding. An attacker can replace the database and signatures with an older, legitimately signed version, which will be accepted by the system.
Risk Assessment
An attacker with access to the database file can roll back security policies to an older, less restrictive version, bypassing protection.
Recommendation
Update ClearanceKit to version 5.0.10. Protect the database file from unauthorized access.
Other vulnerabilities in ClearanceKit
See all- CVE-2026-47134Medium
In ClearanceKit before version 5.0.10, the ECDSA key used to sign the policy database is stored in the macOS keychain without ACL restrictions. Any root process can use this key to sign arbitrary policy content.
- CVE-2026-34218Medium
ClearanceKit has a startup defect where only compile-time rules are enforced until user interacts with GUI. MDM and user-defined rules are not applied.
Original NVD description (English source)
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.