A public, source-guided analysis of CVE-2026-84568 and CVE-2026-84570, with reversible proofs for LDAP/OD input, NFS delivery, helper dispatch, Gatekeeper behavior, and the device-node boundary.

Publication status — October 2026. Apple fixed both vulnerabilities on September 14, 2026 in macOS Sequoia 15.8, macOS Tahoe 26.7, and macOS Golden Gate 27. The reproducer in this repository is intended only for an isolated, authorized lab containing an intentionally unpatched Mac.

Validation status. The included on-host validators were run successfully on an affected macOS 26.4 (build 25E246, arm64) lab host. The helper-dispatch test, complete loopback NFS delivery chain, pathname/credential probe, Gatekeeper differential, and nodev/device boundary test all returned PASS. In the Gatekeeper test, assessments were enabled; the app was structurally valid but ad-hoc signed with no Team ID; explicit spctl assessment rejected it; the NFS mount had neither noexec nor quarantine; and LaunchServices ran it without an approval step. Each validator also returned cleanup_result=PASS, and an independent post-run check confirmed that its temporary directory records, mounts, files, and /etc/exports changes were removed or restored. The Python harness was separately exercised against a temporary OpenLDAP server with the real automount/Apple attribute schema: both the automountKey and apple-user-homeurl routes passed create/readback/timeout/restore checks. These observations characterize that affected build and the included harness; they are not claims about patched releases.

Research credit: Mr.Gedik (@h4ck2s3c); CVE-2026-84568 is credited publicly to Mr.Gedik, and CVE-2026-84570 to Mr.Gedik, in Apple's advisories.

Scope

This is the public version of the research. It contains only information supported by Apple's published advisories, Apple's open-source code, and the included reproducible lab material. Private case identifiers, private communications, non-public artifacts, and unrelated research are intentionally excluded.

The two CVEs share an attack surface but represent independent root causes:

CVE	Apple's published impact	Client-side boundary
CVE-2026-84568	A network-directory attacker may execute arbitrary code with root privileges	A directory-controlled `fstype` influenced the executable path selected by `automountd`
CVE-2026-84570	An app may bypass Gatekeeper checks	A directory-controlled NFS automount crossed both application-provenance and device-node policy boundaries

Apple lists both issues under autofs in the security content for macOS Golden Gate 27, macOS Tahoe 26.7, and macOS Sequoia 15.8.

Executive summary

macOS automount maps are executable control data. A map line selects a filesystem type, supplies mount options, identifies a resource, and ultimately influences privileged mount dispatch. Before the September 2026 updates, two validation failures allowed directory-provided data to cross security boundaries on the client:

A crafted fstype could escape the intended /sbin/mount_<type> helper namespace and resolve to an executable delivered through NFS.
A crafted NFS option set could negate the expected nodev policy. The resulting network mount also had no noexec or quarantine policy, so an app which failed an explicit Gatekeeper assessment could still be launched from it.

Those are related observations, not interchangeable mechanisms. nodev controls whether special-device vnodes are interpreted; it does not implement Gatekeeper. noexec controls execution at the VFS boundary. Gatekeeper separately evaluates application trust and provenance. The CVE-2026-84570 validator reports each boundary independently so that a missing nodev flag is never presented as proof of a Gatekeeper bypass by itself.

Directory write access is an entry prerequisite, not the resulting authority. Changing an automount or user-home attribute is not equivalent to choosing an executable pathname on every consuming Mac or weakening the kernel policy of an NFS mount. Those transformations occur on the client.

Precision notes

A self-contained CVE-2026-84568 lab chain uses two directory values: one delivers a short NFS path and one redirects helper dispatch to the delivered binary.
Creating a record does not execute it by itself. An autofs lookup of the relevant key is still required.
The included Python harness never performs that lookup. It installs the authorized lab state and passively waits for a proof event generated by independent client activity.
Lookup credentials matter. The generic helper child is associated with the triggering UID; a root-originating lookup is therefore required to demonstrate Apple's published root-privileged endpoint.
Pathname resolution must be tested in the privileged daemon context. On the validated host, root's lookup of the constructed path succeeded while the same direct stat() by an unprivileged account returned ENOTDIR; an unprivileged realpath() or stat() result is therefore not a valid proxy for automountd here.
CVE-2026-84568 does not require the nodev bypass demonstrated for CVE-2026-84570. The complete 84568 chain succeeded while its delivery mount retained nodev and nosuid.
The Gatekeeper proof does not label modern compiler output as literally unsigned. The validator creates a structurally valid ad-hoc-signed app with no Team ID and no notarization. That is sufficient to distinguish loader-valid code from software trusted under the default Gatekeeper policy.
CVE-2026-84570 alone does not make an app execute automatically. Its validator invokes LaunchServices explicitly. CVE-2026-84568 supplies the separate dispatch primitive that executes the delivered binary when the dispatch key is looked up.
A monitoring timeout is inconclusive: it says that no matching proof event arrived during the selected interval, not that the target is patched.

From directory data to privileged dispatch

The default automount configuration exposes directory-backed inputs below /home:

/etc/auto_master:  /home  auto_home  -nobrowse,hidefromfinder
/etc/auto_home:    +auto_home
/etc/auto_home:    +/usr/libexec/od_user_homes

The first inclusion resolves automount records. The executable-map inclusion invokes od_user_homes, which resolves user-home information and emits a map line. Both routes converge on the automount parser.

The public harness keeps both directory forms explicit:

Route	Directory input	Resulting autofs key/value
`automount`	RFC 2307 entry whose RDN is `automountKey=<key>` below an `automountMapName=auto_home` map; value in `automountInformation`	`<key>` → raw map line
`userhome`	Existing user entry; value in `apple-user-homeurl`	the user's record-name key → map line wrapped in `<home_dir><url>…</url></home_dir>`

The distinction matters operationally but not at the vulnerable sink: both values eventually influence the parsed filesystem type and mount arguments on the Mac.

flowchart LR
    DS["LDAP / Open Directory"]
    AM["AutomountInformation"]
    UH["User home attribute"]
    GM["getmapent_od()"]
    OUH["od_user_homes"]
    MAP["Automount map line"]
    PARSE["parse_entry() / set_mapent_opts()"]
    TYPE{"fstype"}
    NFS["Dedicated NFS path"]
    GENERIC["Generic helper path"]
    EXEC["run_mount_cmd()"]

    DS --> AM --> GM --> MAP
    DS --> UH --> OUH --> MAP
    MAP --> PARSE --> TYPE
    TYPE -->|exactly nfs| NFS
    TYPE -->|another value| GENERIC --> EXEC

Relevant public source paths include:

CVE-2026-84568

Most Popular

Scope

Executive summary

Precision notes

From directory data to privileged dispatch