macOS LPE Flaw Resurfaces: .localized Directory Exploited to Hijack Installers and Gain Root Access

A stubborn vulnerability in macOS third-party installers has resurfaced, allowing attackers to hijack privileged processes and gain root access to a system. Discovered by security researcher Csaba Fitzl, this flaw exploits a peculiar behavior in how macOS handles file naming conflicts, creating a blind spot that persists despite seven years of reports and partial fixes.

The vulnerability affects installers that attempt to run privileged commands from within an application bundle—a common practice for software that needs to install helper tools or background daemons.

The core issue traces back to 2018, when Fitzl first reported that attackers could race against an installer to pre-create directory structures. By owning the directories before the legitimate installer arrived, an attacker could swap out binaries and trick the installer into executing malicious code as root.

While Apple addressed the specific race condition in macOS Sonoma, and researcher Mickey Jin recently secured CVE-2025-24099 for a related fix, the underlying logic flaw remains exploitable through a new vector involving the hidden .localized directory.

“This vulnerability has a very long history, and Apple never managed to properly fix it… so here we are in 2025, with a vulnerability still exploitable 7 years later, although in a different way,” Fitzl writes.

The new exploitation technique leverages a feature of the macOS filesystem designed to handle naming collisions.

When an installer attempts to place an application (e.g., Test.app) in the /Applications folder, but a folder with that name already exists with a different Bundle ID, the system does not overwrite the existing app. Instead, it silently creates a new directory named /Applications/Test.localized and installs the real application there.

“The problem is that when we install an application it expects to be installed in its final location… but if there is something else with different bundle ID that won’t be deleted and the app will be placed in .localized,” the blog explains.

This redirection creates a critical disconnect. The installer believes it has placed its files in /Applications/Test.app, but the real files are actually in /Applications/Test.localized/Test.app. Meanwhile, the attacker’s fake application remains in the expected path.

The exploit is simple but effective, requiring only that an attacker trick a user (or an MDM solution) into running an installer for a target application:

1. The Bait: An attacker places a fake Test.app in /Applications with a random bundle ID and a malicious binary disguised as a helper tool.
2. The Switch: The user installs the legitimate Test.app. macOS sees the conflict and installs the real app into /Applications/Test.localized/.
3. The Trigger: The legitimate installer registers a LaunchDaemon (a background service) pointing to where it thinks the app is: /Applications/Test.app.
4. Root Compromise: The system’s launchd service executes the binary at that path as root. Since the attacker controls that path, their code runs with full system privileges.

“Since we own the binary we will get root code execution,” Fitzl concludes. The security researcher has publicly released the exploit code here.

Fitzl argues that while the issue is rooted in macOS behavior, it ultimately impacts third-party vendors who are “rightfully expect[ing] being installed properly, without going the extra mile of verification”.

Until Apple introduces a comprehensive fix that prevents this directory redirection or verifies installation paths more rigorously, installers remain vulnerable to this subtle form of hijacking.

Related Posts:

• Google’s AI Search Goes Global: New AI Mode Supports Five Languages
• High-Severity Zoom Rooms Flaw Risks Privilege Escalation via Downgrade Protection Bypass
• From CVE to PoC: A Collection Maps Windows Privilege Escalation Landscape
• Microsoft Announces Critical Change to .NET Installer Distribution Domains