On September 3, 2026, I reported a third defect in /System/Library/CoreServices/ScopedBookmarkAgent. It is the same binary as the two defects I wrote up previously and it is not the same bug. Those were a gate that permitted too much. This is a gate that is not reached at all.

An app signed with com.apple.security.app-sandbox and com.apple.security.files.bookmarks.document-scope, and nothing else, received an app-scoped security-scoped bookmark for / and read /Users. document-scope grants no file access outside the app's own container.

The gate, and the branch over it

The crea handler decides whether a caller may create an app-scoped bookmark with three consecutive entitlement tests, each a bool_entitlement_for_audit_token, falling through to a refusal when none matches:

0x100008d2c   com.apple.security.files.bookmarks.app-scope
0x100008d5c   com.apple.security.files.user-selected.read-only
0x100008d8c   com.apple.security.files.user-selected.read-write

Immediately before all three, at 0x100008cec:

100008cec   cbz   w0, 0x100008cf8       ; w0 = sandbox_check_by_audit_token result
100008cf0   ldr   x8, [sp, #0x40]      ; the "opti" uint64 taken from the message
100008cf4   tbnz  w8, #0x19, 0x100008e08

0x100008e08 is downstream of all three tests. Bit 25 of opti lands the caller there with none of them having run. opti is read out of the XPC message, so the caller chooses it.

Why that is reachable by the wrong caller

The sandbox profile and the agent disagree about who may talk to it. /System/Library/Sandbox/Profiles/application.sb, lines 295 to 300, allows the mach-lookup under a five-way entitlement OR:

(when (or (entitlement "com.apple.security.files.bookmarks.app-scope")
          (entitlement "com.apple.security.files.bookmarks.document-scope")
          (entitlement "com.apple.security.files.bookmarks.collection-scope")
          (entitlement "com.apple.security.files.user-selected.read-only")
          (entitlement "com.apple.security.files.user-selected.read-write"))
      (allow mach-lookup (global-name "com.apple.scopedbookmarksagent.xpc")))

The agent's own app-scope gate is a three-way OR. document-scope and collection-scope are in the first set and not the second: they may reach the service and must be refused app scope. That is precisely the caller the gate exists to stop, and the branch skips it.

The measurement

Same app, same process, same path. Only bit 25 differs between the two requests:

before   /Users   read=1  opendir=failed errno=1
CONTROL  opti=0x800      errc=256  "Required entitlement ...bookmarks.app-scope is missing or false"
TEST     opti=0x2000800  errc=0    bookmark=460 bytes, resolves to /
after    /Users   read=0  opendir=6 entries, canary readable
revoked  /Users   read=1  opendir=failed errno=1

With the bit clear the agent refuses this caller by name. With it set the same caller receives a bookmark for /. The grant is the bookmark's: /Users returns to denied on stopAccessing. The entitlements were dumped back out of the signed bundle with codesign -d --entitlements on every trial and the run aborted unless the set was exactly app-sandbox plus document-scope. Six trials, three with the bit and three controls, all six behaved as claimed.

The part I got wrong first

This took five runs, and two of them reached the wrong conclusion. The first measurements showed the bit-25 caller reaching a different error, "Failed to retrieve app-scope key", instead of the entitlement refusal, and I read that as a second, independent check holding the line: key material the caller could not obtain. Two failure messages were being treated as evidence of a gate.

The agent's own log settled it:

(peer pid=85853) peer sent message. message_type=crea
-[KeyManager getSigningIdentifier:...forAuditToken:]:
    SecCodeCopyGuestWithAttributes returned 100001 for pid=85853
-[KeyManager appInfoForAuditToken:]: failed to get code signature for pid=85853, aborting
Failed to retrieve app-scope key, aborting.

That is not an authorisation decision. It is a code-signature lookup returning 100001, which is errSecErrnoBase + EPERM, in a process that had never transacted with the agent before, so its cached AppInfo was empty. The app-scope key is not a gate either: -[KeyManager scopeKeyForSigningIdentifier:] is HMAC-SHA256(agentKey, signingIdentifier), one agent-wide key derived on demand, with no entitlement check anywhere in the derivation and nothing to provision.

Letting the app make one ordinary bookmark call first, which for this app fails, warms that cache, and the escalation reproduces. The entitled control had been clearing the same hurdle by accident, because its first operation succeeded and populated AppInfo on the way past.

Impact

An app whose only declared file entitlement is com.apple.security.files.bookmarks.document-scope reads any file the user can read outside the TCC-protected folders, with no prompt and no user action. The reach is the same as the app-scope gate defect, but a fix that adjusts which entitlements are accepted leaves this path open, because on this path none of them are consulted. That is why I raised it separately rather than as a rider on the earlier case.

The fix

Apple addressed it in macOS Golden Gate 27. Disassembling the shipping 26A428 agent shows the fix is an added gate rather than a repair of the skip. A new call to sandbox_query_user_intent_for_process_with_audit_token at 0x100008b60 sits after the entitlement block, and on failure emits a string that is not in the older binary:

Process is not allowed to create bookmark to '/' without explicit
user intent. Use an open panel to convey intent from the user.

That matches the behaviour on the updated system. With bit 25 clear the caller still gets the old "Required entitlement … is missing or false"; with it set, it now gets the new message. Whether the tbnz at 0x100008cf4 still skips the entitlement tests is not something I have established. The check that stops the attack is downstream of it. Apple describes the fix as a permissions issue addressed with improved validation.

Report status

I reported this under OE1107685948017 on September 3, 2026. Apple's Security Research portal records it as addressed in macOS Golden Gate 27 under CVE-2026-84559, published September 14, 2026 in macOS Golden Gate 27, macOS Tahoe 26.7 and macOS Sequoia 15.8, with the impact stated as "A malicious application may be able to access restricted files". NVD scores it CVSS 3.1 5.5 Medium, AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, CWE-693. The published advisory credit line does not currently include me; I have asked Apple to correct it.

A check that an untrusted caller can branch around is not a weaker check. It is not a check.