{"api_version":"1","generated_at":"2026-07-22T04:25:19+00:00","cve":"CVE-2026-47134","urls":{"html":"https://cve.report/CVE-2026-47134","api":"https://cve.report/api/cve/CVE-2026-47134.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-47134","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-47134"},"summary":{"title":"ClearanceKit: Policy signing key in System Keychain has permissive ACL allowing any local-root process to forge signed policy","description":"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.","state":"PUBLISHED","assigner":"GitHub_M","published_at":"2026-07-20 22:17:15","updated_at":"2026-07-21 16:17:11"},"problem_types":["CWE-732","CWE-732 CWE-732: Incorrect Permission Assignment for Critical Resource"],"metrics":[{"version":"4.0","source":"security-advisories@github.com","type":"Secondary","score":"6.9","severity":"MEDIUM","vector":"CVSS:4.0/AV:L/AC:L/AT:P/PR:H/UI:N/VC:N/VI:H/VA:N/SC:H/SI:H/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","data":{"version":"4.0","vectorString":"CVSS:4.0/AV:L/AC:L/AT:P/PR:H/UI:N/VC:N/VI:H/VA:N/SC:H/SI:H/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","baseScore":6.9,"baseSeverity":"MEDIUM","attackVector":"LOCAL","attackComplexity":"LOW","attackRequirements":"PRESENT","privilegesRequired":"HIGH","userInteraction":"NONE","vulnConfidentialityImpact":"NONE","vulnIntegrityImpact":"HIGH","vulnAvailabilityImpact":"NONE","subConfidentialityImpact":"HIGH","subIntegrityImpact":"HIGH","subAvailabilityImpact":"NONE","exploitMaturity":"NOT_DEFINED","confidentialityRequirement":"NOT_DEFINED","integrityRequirement":"NOT_DEFINED","availabilityRequirement":"NOT_DEFINED","modifiedAttackVector":"NOT_DEFINED","modifiedAttackComplexity":"NOT_DEFINED","modifiedAttackRequirements":"NOT_DEFINED","modifiedPrivilegesRequired":"NOT_DEFINED","modifiedUserInteraction":"NOT_DEFINED","modifiedVulnConfidentialityImpact":"NOT_DEFINED","modifiedVulnIntegrityImpact":"NOT_DEFINED","modifiedVulnAvailabilityImpact":"NOT_DEFINED","modifiedSubConfidentialityImpact":"NOT_DEFINED","modifiedSubIntegrityImpact":"NOT_DEFINED","modifiedSubAvailabilityImpact":"NOT_DEFINED","Safety":"NOT_DEFINED","Automatable":"NOT_DEFINED","Recovery":"NOT_DEFINED","valueDensity":"NOT_DEFINED","vulnerabilityResponseEffort":"NOT_DEFINED","providerUrgency":"NOT_DEFINED"}},{"version":"4.0","source":"CNA","type":"DECLARED","score":"6.9","severity":"MEDIUM","vector":"CVSS:4.0/AV:L/AC:L/AT:P/PR:H/UI:N/VC:N/VI:H/VA:N/SC:H/SI:H/SA:N","data":{"attackComplexity":"LOW","attackRequirements":"PRESENT","attackVector":"LOCAL","baseScore":6.9,"baseSeverity":"MEDIUM","privilegesRequired":"HIGH","subAvailabilityImpact":"NONE","subConfidentialityImpact":"HIGH","subIntegrityImpact":"HIGH","userInteraction":"NONE","vectorString":"CVSS:4.0/AV:L/AC:L/AT:P/PR:H/UI:N/VC:N/VI:H/VA:N/SC:H/SI:H/SA:N","version":"4.0","vulnAvailabilityImpact":"NONE","vulnConfidentialityImpact":"NONE","vulnIntegrityImpact":"HIGH"}}],"references":[{"url":"https://github.com/craigjbass/clearancekit/security/advisories/GHSA-w254-hxm5-3hgh","name":"https://github.com/craigjbass/clearancekit/security/advisories/GHSA-w254-hxm5-3hgh","refsource":"security-advisories@github.com","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-47134","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-47134","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"craigjbass","product":"clearancekit","version":"affected < 5.0.10","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":{"cve_year":"2026","cve_id":"47134","cve":"CVE-2026-47134","epss":"0.001060000","percentile":"0.013060000","score_date":"2026-07-21","updated_at":"2026-07-22 00:11:17"},"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"adp":[{"metrics":[{"other":{"content":{"id":"CVE-2026-47134","options":[{"Exploitation":"none"},{"Automatable":"no"},{"Technical Impact":"partial"}],"role":"CISA Coordinator","timestamp":"2026-07-21T13:16:06.301506Z","version":"2.0.3"},"type":"ssvc"}}],"providerMetadata":{"dateUpdated":"2026-07-21T14:56:09.708Z","orgId":"134c704f-9b21-4f2e-91b3-4a467353bcc0","shortName":"CISA-ADP"},"title":"CISA ADP Vulnrichment"}],"cna":{"affected":[{"product":"clearancekit","vendor":"craigjbass","versions":[{"status":"affected","version":"< 5.0.10"}]}],"descriptions":[{"lang":"en","value":"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."}],"metrics":[{"cvssV4_0":{"attackComplexity":"LOW","attackRequirements":"PRESENT","attackVector":"LOCAL","baseScore":6.9,"baseSeverity":"MEDIUM","privilegesRequired":"HIGH","subAvailabilityImpact":"NONE","subConfidentialityImpact":"HIGH","subIntegrityImpact":"HIGH","userInteraction":"NONE","vectorString":"CVSS:4.0/AV:L/AC:L/AT:P/PR:H/UI:N/VC:N/VI:H/VA:N/SC:H/SI:H/SA:N","version":"4.0","vulnAvailabilityImpact":"NONE","vulnConfidentialityImpact":"NONE","vulnIntegrityImpact":"HIGH"}}],"problemTypes":[{"descriptions":[{"cweId":"CWE-732","description":"CWE-732: Incorrect Permission Assignment for Critical Resource","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-07-20T21:17:22.539Z","orgId":"a0819718-46f1-4df5-94e2-005712e83aaa","shortName":"GitHub_M"},"references":[{"name":"https://github.com/craigjbass/clearancekit/security/advisories/GHSA-w254-hxm5-3hgh","tags":["x_refsource_CONFIRM"],"url":"https://github.com/craigjbass/clearancekit/security/advisories/GHSA-w254-hxm5-3hgh"}],"source":{"advisory":"GHSA-w254-hxm5-3hgh","discovery":"UNKNOWN"},"title":"ClearanceKit: Policy signing key in System Keychain has permissive ACL allowing any local-root process to forge signed policy"}},"cveMetadata":{"assignerOrgId":"a0819718-46f1-4df5-94e2-005712e83aaa","assignerShortName":"GitHub_M","cveId":"CVE-2026-47134","datePublished":"2026-07-20T21:17:22.539Z","dateReserved":"2026-05-18T19:50:18.695Z","dateUpdated":"2026-07-21T14:56:09.708Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-07-20 22:17:15","lastModifiedDate":"2026-07-21 16:17:11","problem_types":["CWE-732","CWE-732 CWE-732: Incorrect Permission Assignment for Critical Resource"],"metrics":{"cvssMetricV40":[{"source":"security-advisories@github.com","type":"Secondary","cvssData":{"version":"4.0","vectorString":"CVSS:4.0/AV:L/AC:L/AT:P/PR:H/UI:N/VC:N/VI:H/VA:N/SC:H/SI:H/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","baseScore":6.9,"baseSeverity":"MEDIUM","attackVector":"LOCAL","attackComplexity":"LOW","attackRequirements":"PRESENT","privilegesRequired":"HIGH","userInteraction":"NONE","vulnConfidentialityImpact":"NONE","vulnIntegrityImpact":"HIGH","vulnAvailabilityImpact":"NONE","subConfidentialityImpact":"HIGH","subIntegrityImpact":"HIGH","subAvailabilityImpact":"NONE","exploitMaturity":"NOT_DEFINED","confidentialityRequirement":"NOT_DEFINED","integrityRequirement":"NOT_DEFINED","availabilityRequirement":"NOT_DEFINED","modifiedAttackVector":"NOT_DEFINED","modifiedAttackComplexity":"NOT_DEFINED","modifiedAttackRequirements":"NOT_DEFINED","modifiedPrivilegesRequired":"NOT_DEFINED","modifiedUserInteraction":"NOT_DEFINED","modifiedVulnConfidentialityImpact":"NOT_DEFINED","modifiedVulnIntegrityImpact":"NOT_DEFINED","modifiedVulnAvailabilityImpact":"NOT_DEFINED","modifiedSubConfidentialityImpact":"NOT_DEFINED","modifiedSubIntegrityImpact":"NOT_DEFINED","modifiedSubAvailabilityImpact":"NOT_DEFINED","Safety":"NOT_DEFINED","Automatable":"NOT_DEFINED","Recovery":"NOT_DEFINED","valueDensity":"NOT_DEFINED","vulnerabilityResponseEffort":"NOT_DEFINED","providerUrgency":"NOT_DEFINED"}}],"ssvcV203":[{"source":"134c704f-9b21-4f2e-91b3-4a467353bcc0","ssvcData":{"timestamp":"2026-07-21T13:16:06.301506Z","id":"CVE-2026-47134","options":[{"exploitation":"none"},{"automatable":"no"},{"technicalImpact":"partial"}],"role":"CISA Coordinator","version":"2.0.3"}}]},"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"47134","Ordinal":"1","Title":"ClearanceKit: Policy signing key in System Keychain has permissi","CVE":"CVE-2026-47134","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"47134","Ordinal":"1","NoteData":"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.","Type":"Description","Title":"ClearanceKit: Policy signing key in System Keychain has permissi"}]}}}