Why this writeup exists

Apple's advisory for CVE-2026-84568 documents the impact and the patch version. It does not document the technical mechanism:

• Which function was patched
• What the check actually does
• Why the RCE described in the advisory is not reachable through the paths tested here

No public technical writeup was found at the time of writing. This repository fills that gap with an independent reverse engineering analysis of automountd_26.6 and automountd_27, and a working PoC for the underlying trust-boundary violation.

This is not a discovery claim. The CVE was reported by Mr.Gedik and patched by Apple. The contribution here is the technical analysis and the reproduction.

Summary of the vulnerability

automountd fetches automount maps from a configured directory service (LDAP, NIS, OpenDirectory). In the vulnerable version (26.6 and earlier), automountd did not validate whether the host component of a map entry resolved to the local machine.

A malicious directory server could therefore serve a map entry whose mount source was:

• the literal string localhost
• the victim's own hostname (<hostname>.local)
• any local IP address, including 127.0.0.1

The victim would then mount from itself at an attacker-controlled mount point.

The patched version (26.7 / 27) adds a hostname check in sym.func.100005bd8 that rejects entries matching any of the above.

What this repository contains

Reverse engineering

• Disassembly diff of sym.func.100005bd8 between automountd_26.6 and automountd_27 — see docs/PATCH_DIFF.md
• Identification of the patched check: strncasecmp against "localhost", gethostname(), SCDynamicStoreCopyLocalHostName + ".local", and a getifaddrs / getipnodebyaddr loop enumerating all local IPs
• Trace of the fstype field through parse_nfs → mapline_to_mapent → asprintf("%s/mount_%s", "/sbin", fstype) — the field is not validated before constructing the program path
• SAX callback analysis of webdavfs_agent's XML parser — the characters callback uses __memcpy_chk with explicit length checks; no overflow
• Analysis of od_process_record_attributes — the OpenDirectory record parser uses CoreFoundation APIs throughout; no fixed-size buffers
• Mount program audit — mount_nfs, mount_smbfs, mount_url, and all NetFSPlugins/* bundles checked for shell execution; none found

See docs/ANALYSIS.md for the full writeup and docs/ARTIFACTS.md for addresses and log samples.

Reproduction

• poc.sh — a single-file attacker-side setup. Starts an LDAP server with a malicious auto_master / auto_evil map and an NFS export with a proof-of-access marker. When the victim's automountd fetches the map, it mounts its own NFS export at the attacker-controlled path.

What this PoC demonstrates

• A malicious LDAP server serving a crafted auto_master / auto_evil map
• The victim's automountd fetching the map over the network
• The victim mounting its own NFS export at an attacker-controlled path
• The mount source in the kernel mount table is 127.0.0.1

What this PoC does NOT demonstrate

• Arbitrary code execution
• Privilege escalation
• A shell on the victim

The "arbitrary code execution with root privileges" impact in Apple's advisory is not reachable through the paths tested in this analysis. See the "Paths tested and ruled out" section in docs/ANALYSIS.md for the full list.

The demonstrated impact is the trust-boundary violation itself: the victim mounts from a source it should have rejected.

Repository layout

Four files, two directories. Nothing else.

Requirements

Attacker host (macOS)

• Homebrew
• OpenLDAP (brew install openldap)
• slapd.conf defining: database mdb with suffix "dc=evil,dc=local"
• NFS server (nfsd) — ships with macOS
• Root access (for slapd, nfsd, /etc/exports)

Victim host

• macOS 26.6 or earlier (vulnerable automountd)
• Configured to query the attacker's LDAP server for automount maps
• +auto_master present in /etc/auto_master
• nfsd running on the victim, exporting a directory

The victim needs a running NFS server for the mount to succeed. The CVE is about the acceptance of the local-host entry, not about delivering the export. If the victim does not run nfsd, the mount fails with NFS server 127.0.0.1 not responding — which still demonstrates that automountd accepted the entry.

Usage

Attacker

Replace <ATTACKER_IP> with the attacker's IP as seen from the victim.

Victim

Expected result

The file proof.txt is readable through the mount. The mount source in mount output is 127.0.0.1:<export_dir>:

The presence of nodev and nosuid reflects the kernel's NFS mount defaults and mount_nfs's own option handling — they are not from automountd. See docs/ANALYSIS.md for the full breakdown.

Verification of the patch

On a patched system (26.7 / 27), the same map entry is rejected before any mount attempt. See docs/PATCH_DIFF.md for the disassembly comparison of sym.func.100005bd8.

To confirm on a patched host:

Expected: the mount point is not created, and no entry appears in mount output. The sym.func.100005bd8 check rejects the entry when the host is 127.0.0.1, localhost, or the local hostname.

The fstype injection (separate finding)

During the analysis, a separate defense-in-depth weakness was found: sym.func.1000086f4 (run_mount_cmd) constructs a program path via asprintf("%s/mount_%s", "/sbin", fstype) without validating the fstype field from the map entry.

Path traversal sequences in fstype reach the asprintf call:

On a stock macOS installation, the resulting path does not resolve to an executable because /sbin/mount_.. does not exist. The injection is real but blocked by path resolution. It would become exploitable only if a writable path existed under /sbin, or if a directory-symlink mount_<X> were created — neither of which holds on stock macOS.

This is documented as a separate observation, not as part of CVE-2026-84568. See docs/ANALYSIS.md for details.

Credits

• Original discovery: Mr.Gedik (@h4ck2s3c) of Turkish Technology, per the Apple security advisory for CVE-2026-84568.
• Independent analysis and PoC: jvidhan
• Reference: Apple's advisory and the patched binary served as the baseline for comparison with the vulnerable version.

Disclaimer

This repository is provided for defensive security research and education only.

• It is intended for use against systems you own or have explicit written permission to test.
• Using this tool against systems you do not own or control may violate local, national, or international law.
• The author(s) assume no responsibility or liability for any misuse or damage caused by this code.
• The PoC is limited to demonstrating a mount trust violation. It does not achieve code execution. Any claims of RCE from this PoC are unsupported by the included analysis.
• Apple, macOS, autofs, and automountd are trademarks of Apple Inc. This project is not affiliated with or endorsed by Apple.

License

MIT. See LICENSE.