Microsoft has disclosed a fresh local elevation-of-privilege vulnerability in its Microsoft AutoUpdate (MAU) agent that allows an attacker with an existing foothold on a macOS machine to escalate to root privileges. The flaw, tracked as CVE-2025-55317, stems from improper link resolution before file access—a classic “link following” weakness that has plagued the updater repeatedly in recent months.

The advisory, published on the Microsoft Security Response Center (MSRC), warns that an authorized local attacker can coerce MAU into following a reparse point (such as a symlink or junction) and redirect a privileged file operation to a protected system location. The result could be the overwriting of system binaries, planting of malicious executables, or tampering with configuration files that run with elevated rights.

This is not an isolated incident. MAU—a critical background service that keeps Microsoft Office, Teams, Edge, and other Microsoft apps updated on macOS—has been dogged by a string of similar link-following bugs throughout 2024 and 2025. CVEs like CVE-2025-47968, CVE-2025-29800, and CVE-2025-24036 all documented comparable local privilege escalations, underscoring a worrying pattern: when an updater runs with root privileges yet lacks robust path validation, it becomes a high-value target for attackers who have already gained limited access to a machine.

How the bug works

Microsoft AutoUpdate runs in the background, periodically checking for updates and deploying them. To modify application files in /Applications or /Library, it must often operate with elevated permissions. Normally, MAU writes files to well-defined staging areas and then moves them into place. But if an attacker can plant a specially crafted symbolic link in a directory MAU accesses—say /tmp, an app cache, or a user profile—they can trick the updater into writing a file to an unintended location.

The exploit chain is straightforward: the attacker, operating as an ordinary user, creates a symlink in a writable directory that points to a protected system file or binary. When MAU later performs a privileged file write, copy, or move operation on that symlink, it follows the link and overwrites the target. The corrupted target could be a launch daemon plist, a shared library, or an executable that will be launched by a privileged process. Once the payload is in place, the attacker simply triggers or waits for that process to run, and they instantly gain root-level code execution.

Microsoft classifies the attack as requiring a local authorized user, meaning the attacker already needs credentials on the host. That limits its usefulness for initial access, but makes it a perfect tool for post-compromise escalation: a malware dropper, a disgruntled insider, or an attacker who has stolen valid user credentials can pivot from a standard account to fully compromise the device.

The patch and what it means for enterprises

Microsoft has not publicly released exact version numbers or KB identifiers for the fix on the advisory page—the MSRC entry is served as a client-side application that requires JavaScript. But the standard guidance is clear: apply the latest Microsoft AutoUpdate package through Microsoft’s normal update channels. The advisory page at https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-55317/ remains the authoritative source for remediation details.

For IT administrators overseeing fleets of Macs, this is a high-priority patch. Shared workstations, developer machines, and any host where multiple users have local access are at heightened risk. But even single-user corporate laptops are not immune: an initial compromise via a malicious document or phishing link could now be parlayed into a full system takeover if MAU is left unpatched.

The real-world impact is chilling. Consider a scenario where an employee opens a weaponized email attachment. The first-stage payload gives the attacker a limited user shell. Using CVE-2025-55317, that attacker then overwrites a system daemon or loads a dynamic library that will be injected into a privileged application. Within seconds, they have root access. They can disable security tools, steal credentials, exfiltrate sensitive data, or deploy ransomware—all without triggering traditional network alerts, because the malicious activity stems from a trusted, signed Microsoft binary.

Microsoft AutoUpdate is not unique in its vulnerability to symlink attacks. Many update agents and installers have faced similar issues over the years. But the frequency of CVEs in this single component is remarkable. The root cause is a design pattern that trusts the filesystem more than it should: MAU processes run with elevated privileges and access user-writable directories like /tmp or $TMPDIR. Unless every file operation carefully validates that the target is not a reparse point and that the resolved path falls within an expected safe directory, an attacker can redirect those operations.

Microsoft has attempted to harden MAU in the past—recent patches have introduced more rigorous canonicalization and ownership checks. Yet the recurrence suggests that the underlying architecture still relies on code paths where user-controlled locations intersect with privileged file writes. For a sustainable fix, Microsoft would need to redesign MAU’s staging and installation logic to operate entirely within a sandboxed, root-owned directory that no user can tamper with, and to never load resources or resolve paths from unprivileged locations while running as root.

Detection: finding traces of exploitation

Because the attack blends normal updater behavior, detection is challenging. Dedicated hunting queries are essential. Security teams should look for correlation between symlink creation in user-writable directories (like /tmp, ~/Library/Caches, ~/Library/Application Support) and subsequent file writes by the Microsoft AutoUpdate process (com.microsoft.autoupdate2 or MAU) to protected paths such as /Library, /System, or /. A spike in file integrity monitoring alerts for system binaries immediately following an update run could be a red flag.

On macOS, enabling the Endpoint Security framework or using an EDR that monitors symlink creation and privileged file writes is critical. The following pseudo-hunt can be adapted to most SIEMs:

  • Detect the creation of a symbolic link (via ln -s or programmatic APIs) in any directory with loose permissions.
  • Within a short time window (e.g., 5 minutes), identify any process associated with Microsoft AutoUpdate that writes to a path outside its normal update cache (e.g., /Library/LaunchDaemons, /usr/local/bin, /Applications/.*).
  • Alert on matches for immediate investigation.

For organizations without advanced EDR, enabling basic file auditing on critical directories and collecting system logs can at least provide post-incident forensic evidence.

Mitigations beyond patching

Applying the vendor patch is the only guaranteed fix. But for environments where patching must be delayed, short-term workarounds can reduce risk:
- Remove local administrator rights from standard user accounts and enforce strict sudo policies.
- Configure MAU to run on demand rather than automatically, reducing the window of opportunity.
- Monitor and lock down /tmp and user cache directories with sticky bit and strict permissions where feasible.
- Use application control software to restrict which processes MAU can launch or which files it can write to.

Longer term, Microsoft and other vendors shipping privileged updaters must embrace secure-by-design principles: never perform elevated file operations based on paths that an unprivileged user can influence. That means avoiding loading plugins, libraries, or configuration files from user home directories, and always resolving the full, final path of a file before acting on it, verifying that it does not traverse a symlink or junction.

A broader lesson for the industry

CVE-2025-55317 is a reminder that auto-update agents are a double-edged sword. They are essential for keeping software current, but their privileged nature makes every bug a potential admin-to-root escalation. Microsoft’s MAU is not the only updater to struggle with this; many Linux package managers and third-party software updaters have faced similar CVEs. The security community has long advocated for updaters to drop privileges as much as possible and to use dedicated, isolated staging directories that no user can write to.

Until vendors internalize that lesson, enterprises will continue to see a steady drumbeat of local privilege escalation tickets. And because exploitation requires only low-privileged code execution—something extremely common in today’s threat landscape—these bugs act as force multipliers for any initial compromise.

What to do right now

Every security team should inventory their macOS fleet and identify any hosts running Microsoft Office or other Microsoft apps that rely on MAU. Check the current MAU version against the advisory information once Microsoft publishes the exact fixed build numbers. Then deploy the update through your existing patch management tool—Jamf Pro, Munki, Intune, or whatever you use. Prioritize developer and shared systems first, then roll out broadly. After patching, audit recent file changes on critical paths and review EDR telemetry for any suspicious symlink activity.

The vulnerability might not yet have a public proof-of-concept or known in-the-wild exploitation, but that window is closing. Microsoft itself notes in its advisory guidance that the urgency of a vulnerability increases when it is known to exist with certainty. CVE-2025-55317 fits that description. Administrators should not wait.