## TL;DR
A sandboxed macOS application — with zero entitlements, zero TCC authorization, and zero user interaction — could obtain FileVault password-wrapped encryption keys (VEK and KEK), user identity information, and password hash parameters from authd via a single XPC message. The authorization gate that protects every other authd operation was simply missing from this one.
—
The Discovery
While auditing macOS XPC services accessible from App Sandbox, I found that authd (the macOS authorization daemon) exposes a pre-login user database through XPC operation 16 (AUTHORIZATIONCOPYPRELOGIN_USERDB).
The interesting part: every other authd operation I tested enforced authorization properly.
- Operation 3 (
COPY_RIGHTS) →errAuthorizationDenied (-60005)
- Operation 8 (
RIGHTSET) →errAuthorizationDenied (-60005)
- Operation 9 (
RIGHTREMOVE) →errAuthorizationDenied (-60005)
- Operation 16 (
COPYPRELOGIN_USERDB) → here's your entire pre-login database
One operation. No gate. Every other path was locked.
—
What Was Exposed
A single XPC message to com.apple.authd with type=16 returned the complete pre-login user database. Per user, that includes:
Identity:
username,lusername(full legal name),uid,guid
- Admin status, FileVault owner flag
- Home directory path, data volume, preboot volume
FileVault Encryption Material:
vek— 139-byte DER-encoded password-wrapped Volume Encryption Key
kek— 161-byte DER-encoded password-wrapped Key Encryption Key
Password Hash Parameters:
SALTED-SHA512-PBKDF2algorithm identifier + parameters
SRP-RFC5054-4096-SHA512-PBKDF2algorithm identifier + parameters
- LKDC Kerberos principal with SHA1 identifier
The VEK/KEK blobs are password-wrapped — not raw key material. But possessing them enables offline brute-force against the user's login password without any access to the physical disk. The PBKDF2 parameters tell an attacker exactly which algorithm and iteration count to target. The Kerberos principal leaks the local KDC identity.
—
The Sandbox Question
The pre-login user database is intended for loginwindow and FileVaultHelper during the pre-boot authentication flow. These are privileged system processes that run outside any sandbox.
The question was: does authd restrict operation 16 to these privileged callers?
The answer was no.
Any process that could look up the com.apple.authd Mach service — which App Sandbox allows by default — could send the XPC message and receive the full database. I verified this from the most restrictive sandbox profile possible:
(version 1)
(deny default)
(allow mach-lookup (global-name "com.apple.authd"))
(allow process-exec)
(allow file-read*)
Deny everything. Allow only the Mach lookup. The VEK/KEK came back.
I also built an Xcode project with App Sandbox enabled in the entitlements — click "Run PoC," observe FileVault encryption keys displayed in the app window. No special entitlements. No sudo. No user interaction.
—
The Fix
macOS Tahoe 26.5 added the authorization check that was absent. Operation 16 now requires proper authorization before returning the pre-login database, consistent with how every other authd operation already worked.
The fix was essentially: apply the same gate to operation 16 that operations 3, 8, and 9 already had.
—
The Takeaway
The vulnerability wasn't exotic. It wasn't a race condition, or a type confusion, or a parsing error. It was a missing if statement on one XPC handler in a daemon that correctly enforced authorization on every other handler.
That's the kind of thing that's easy to miss in a codebase where 6 out of 7 operations do the right thing. The one that doesn't is the one you ship to a billion devices.
The authorization infrastructure was already built. The policy was already defined. It just wasn't applied to one operation. And that one operation happened to serve FileVault encryption keys.
—
Maliq Barnard — Security Researcher
Credited in macOS Tahoe 26.5 Security Advisory — Additional Recognition > Security