authd Handed FileVault Key Material to Any Sandboxed App

The promise the sandbox makes

The App Sandbox exists to draw a hard line: an application, even a malicious one, should not be able to reach the parts of the system that hold your secrets. FileVault key material sits at the top of that list. It is the thing the whole full-disk-encryption model depends on keeping out of reach.

On macOS 26.4 and earlier, a single XPC call from inside a locked-down sandbox walked straight past that line.

The finding

authd, the macOS authorization daemon, answers XPC requests on the com.apple.authd Mach service. App Sandbox allows a lookup of that service, so any app can talk to it. Most of what authd does is properly gated. Request the rights table (operation 3), set a right (8), remove a right (9), and it returns errAuthorizationDenied (-60005). The daemon clearly knows how to say no.

Operation 16, AUTHORIZATION_COPY_PRELOGIN_USERDB, did not say no. It returned the complete pre-login user database to the caller. No entitlement, no TCC, no user interaction, from inside a restrictive sandbox profile.

Per user, the response carried:

• username, full legal name, uid, guid
• admin status and FileVault owner flag
• home directory, data volume, and preboot volume paths
• vek: a 139-byte DER-encoded, password-wrapped Volume Encryption Key
• kek: a 161-byte DER-encoded, password-wrapped Key Encryption Key
• the password hash algorithms and PBKDF2/SRP parameters, plus the local Kerberos (LKDC) principal

Why password-wrapped is not the same as safe

The VEK and KEK are wrapped with the user's password, not raw. That sounds reassuring until you notice what shipped alongside them: the exact PBKDF2 and SRP parameters used to derive the wrapping key. A sandboxed app with zero permissions now holds the encrypted key blobs and the recipe for the key that unlocks them. That is an offline password-cracking problem, run at the attacker's leisure, with no access to the physical disk and no second factor.

The pre-login database is meant for loginwindow and the FileVault pre-boot flow. Operation 16 never checked that the caller was one of those privileged clients.

Reproduction

Build a small client, then run it under a deny-by-default sandbox that allows only the authd lookup:

clang -framework Foundation -o poc poc.m
sandbox-exec -p '(version 1)(deny default)(allow mach-lookup (global-name "com.apple.authd"))(allow process-exec)(allow file-read*)' ./poc

Send an XPC message with type = 16 and read the data field of the reply. The VEK, KEK, and guid are right there.

Verified on macOS 26.4 (25E246) with SIP and AMFI enabled on a stock config, and on the macOS 26.5 beta (25F5042g) on Apple Silicon. In both cases from inside the App Sandbox.

Disposition

Reported to Apple Product Security on 1 April 2026. Apple addressed it in macOS 26.5 by adding the authorization check that operation 16 was missing, which is the cleanest possible confirmation that the prior behavior was unintended. The report is credited to Maliq Barnard under Additional Recognition, Security, in the macOS Tahoe 26.5 advisory. No CVE was assigned.

We will leave the CVE question there. A sandboxed process pulling FileVault key material past a control that every sibling operation enforced is exactly the kind of thing the sandbox exists to stop. The fix says as much.