macOS Accounts CVE-2026-43749: how path handling can lead to root

A privileged helper can perform operations an ordinary app cannot. When it accepts a filesystem path from that app, it has to keep the request within the caller’s allowed scope. Apple’s Accounts fix addresses a path-handling problem with a potential root-privilege impact.

What Apple says was fixed

Apple’s Accounts entry for CVE-2026-43749 describes a parsing problem involving directory paths and a potential ability for an app to obtain root privileges. The stated fix improves path validation. Apple’s public CVE record lists corrections in macOS Tahoe 26.6, Sequoia 15.7.8 and Sonoma 14.8.8, released in the July update cycle.

Apple’s Accounts entry in the Tahoe 26.6 advisory

Apple’s CVE record with the three fixed macOS branches

The advisory’s starting point is an app on the system. It does not describe a remote Apple Account login flaw or a leaked iCloud password database. Accounts is the name of the affected component, not a statement that all Apple account services share the issue.

A privileged service must check the caller’s scope

Before using a path, the OS resolves it in a particular context. Security-sensitive code has to act on the object it meant to validate, and check whether the caller is allowed to request the operation. Validating the path string alone does not settle both questions.

For example, an app may ask a helper to manage data in its assigned workspace. The helper must keep that request inside the permitted objects and operations even if its own process has much broader access. The helper’s authority cannot simply become the caller’s authority.

Apple has not published the affected syntax, privileged operation or any role for links or concurrent activity. A path-validation issue could have several causes. Calling this a symbolic-link race would add a mechanism the advisory does not establish.

Root access is serious, but does not describe every outcome

Root is a highly privileged operating-system identity, so unintended elevation is a serious boundary failure. macOS also includes System Integrity Protection, which restricts changes to protected parts of the system even for root processes. Other mechanisms control application admission and runtime behavior. The presence of those protections does not make the elevation harmless, but neither does the word root establish that each protection was bypassed.

Apple’s explanation of System Integrity Protection

Apple Platform Security: Gatekeeper and runtime protection

Apple reports that an app could gain root. It does not document a SIP bypass, persistence mechanism or observed campaign. Those claims would require further evidence. The absence of those details does not remove the need for the applicable OS update.

Check the fix for the installed macOS branch

Record the branch and full installed version, then check Apple’s release information for the correction. Tahoe, Sequoia and Sonoma use separate version sequences; a smaller Sonoma number does not make it directly comparable with a Tahoe release.

Apple’s supported macOS update process

After updating, check the business applications that use account-related workflows with normal authorized accounts. Keep installation failures and compatibility problems in the maintenance record. Resolve them through the supported OS and application update paths rather than replacing system components piecemeal or weakening macOS protections.

For your own privileged helpers, review the caller, requested operation and permitted resources together. Keep validation close to the operation it protects, make rejection explicit, and use benign regression fixtures to check both legitimate and unauthorized requests. Those design checks are useful without recreating Apple’s bug.

Source check: September 8, 2026. This is Short Circuit LLC’s analysis of Apple’s public vulnerability record and documented macOS protections. Apple credits Adam Franke, Ashish Kunwar and Trung Nguyen of CyStack with this finding.