My Mac’s keychain helper exported the keys and skipped the check

A local process on my test Mac exported private keys from the system keychain without receiving the authorization that the operation was supposed to require. This was an unsandboxed process: it was running outside the restrictions of Apple’s App Sandbox. The result did not depend on getting the user to approve a prompt. The keys came back, and I matched them against the corresponding public certificates on the same machine.

The authorization system was perfectly capable of refusing access. In the same privileged helper, the relevant check rejected an unauthorized request. Neighboring operations called that check before doing their work. The export operation did not. Having a working permission check elsewhere in the process turned out to be an optimistic substitute for using it.

Apple lists the issue as CVE-2026-84556 under Keychain Access, with fixes in its September 14, 2026 macOS releases.

Apple’s Keychain Access advisory and CVE-2026-84556 credit

The helper had more authority than its caller

System services use keychain identities to prove who they are. Some identities include private keys, which an elevated helper can handle on behalf of other software. The helper’s own access is why it can do the work; it is not permission to release that material to every process that can connect.

When I exercised the authorization routine directly without the required authority, it refused. Neighboring operations invoked it before proceeding, while the compiled export handler omitted the call. The helper’s logs recorded the exports, and the returned material let me check exactly what had been released.

I checked the keys, not just the success message

An export operation returning something is not enough to establish that private keys have escaped. A certificate is generally intended to be shared. It carries public information about an identity and its public key. Receiving that certificate would be very different from receiving the associated private key, which is supposed to remain under the control of the identity’s owner.

I verified the recovered private-key material against the live certificates on the tested Mac. The cryptographic match connected the exported keys to the identities already present in the system keychain. The result was more than an identifier, a certificate, or a helper claiming that it had completed a request.

The shipping-release capture was on an Apple Silicon Mac running macOS 26.5. It included system-provisioned identities associated with encrypted network connections and an authentication service, along with another identity present on that machine.

On a separate beta Mac, a process under an account without administrative group membership obtained key material through the affected operation, even though the authorization gate refused that account. The relevant compiled functions matched the shipping-release implementation. The low-privilege capture was on the beta host; the macOS 26.5 capture described above was the shipping-release test.

Local access still has boundaries

The unsandboxed condition is essential. The report expressly states that ordinary App Sandbox clients could not reach this helper. I did not demonstrate a sandbox escape, a remote network entry point, or a way for a website to export the keys. The starting point was a local process running outside that sandbox.

Running outside the App Sandbox does not automatically make a process an administrator, nor should it give that process unrestricted access to system credentials. Sandboxing and authorization answer different questions. The sandbox limits which resources a process can reach; the helper still needs to decide whether a reachable request is allowed to receive privileged data. The low-privilege test made that second boundary visible.

Private keys deserve particular care because they can be used to prove an identity. What someone could do with an exported key would depend on which services trust the associated certificate, what operations the protocol permits, and the surrounding configuration. I did not use the recovered keys to demonstrate impersonation of a service, intercept traffic or gain access to another system. Those would be separate claims requiring separate evidence.

The finding also does not establish access to every password on the Mac, every user or cloud keychain, or non-exportable keys protected by separate hardware. The demonstrated result was the export of the particular system-keychain private-key material captured in the report. It was an authorization failure in a helper, not a demonstrated break of the cryptographic algorithms protecting communications.

Apple’s fix and the credited researchers

Apple describes CVE-2026-84556 as an authorization issue that could expose sensitive user data, addressed by improving access control. Its public description does not detail the internal patch.

Apple’s published Keychain Access impact and fix

The September 14 fixes appear in these macOS releases:

• macOS Golden Gate 27

• macOS Tahoe 26.7

• macOS Sequoia 15.8

These are the releases that introduced the listed fixes. Install the current supported update for the macOS branch you use; there is no reason to select an older release to match this list.

Apple credits Adrián Díaz Aguilar, Chris Bailey - Short Circuit, Peter Malone, and HvxyZLF. I appreciate the other researchers’ contributions and thank Apple’s security and engineering teams for addressing the issue.

The five September Apple CVEs credited to Short Circuit

Apple’s advisories checked October 26, 2026. The technical account comes from my documented research; the linked vendor entries establish the published impact, credit and fix coverage.