This blog is about a vulnerability on macOS which impacts every third party installer if they try to run a privileged command from within the application bundle.

This vulnerability has a very long history, and Apple never managed to properly fix it, and I never got a CVE only a note in the “Additional Recognition” section.

A Little History Link to heading

There is a very long history of this specific bug that I kept reporting to Apple since 2018 (7 years!!). This bug can be exploited when we install third party software on the system. Actually this was my very first vulnerability I submitted to Apple, and my very first macOS talk back in 2019, called macOS - Getting root with benign AppStore apps.

The main idea is that we either redirect the files being installed somewhere else on the system, or by pre-creating the directory structure, we will own the app’s directories and then later we can swap any file. Imagine a software is installing a LaunchDaemon and the related binary is in the application’s directory (as it should be since macOS Sequoia by design). This is OK if the application was installed via a package which was run as root. In that case the folder is owned by root, and no one can modify those binaries anymore. But if we create the app bundle directories first, then we will be able to swap any binary after the installation. I truly believe that this is an Apple problem and third parties should rightfully expect being installed properly, without going the extra mile of verification.

I had four tickets opened for this specific issue. I don’t have the number of the first two, as I opened them via my old company email and those are gone now, but the next two were OE1924072282339, OE1912725854317. The very last one was decided not to be a security issue first but they eventually fixed it in macOS Sonoma. It turned out that it still wasn’t good, you could still race the fact that Apple tried to delete any preexisting directory.

Honestly I gave up at this point, I never got a CVE, nor any reward for this, had to fight every single time to be considered as a vulnerability, so I just Let It Go at that point.

Luckily Mickey Jin (@patch1t) had more luck, and he got them to fix this properly (kinda), and even got assigned CVE-2025-24099. He wrote about this in his blog post Endless Exploits: The Saga of a macOS Vulnerability Struck Nine Times. The funny thing is that Apple told him the same as they told me, but before his OBTS talk, where he planned to publish it, Apple decided to fix it.

So here we are in 2025, with a vulnerability still exploitable 7 years later, although in a different way. We can no longer race the installation process and pre-create the directories. But there is still a way.

Meet .localized Link to heading

I thought that we are finally done with this, until 2025 came and I read a blog post from @p1tsist1p. He wrote about a vulnerability in NordVPN installer and also the same issue in Microsoft Teams installer. The technique he described was new to me, and it had the exact same impact as my original reports, you could own the application bundle directory and replace later any binaries. This was first discovered by Arjen, back in 2017 and there is even a rdar ticket for this, rdar://33005768: Installer creates .localized directory for application bundle. But what is the issue?

Let’s say we try upgrade or install /Applications/Test.app, but if there is already an application with the same directory name but with a different bundle id, the new application will be installed in /Applications/Test.localized/Test.app. See the problem?

The problem is that when we install an application it expects to be installed in its final location (rightfully I think), but if there is something else with different bundle ID that won’t be deleted and the app will be placed in .localized. Now when the app installs and registers its launch daemon, which executes something from the proper application directory, we will have full control over that. Here is the flow of events:

1. We place an application called Test.app in /Applications with some random bundle ID. We also place our own launch daemon binary what will be registered by the real Test.app.
2. The user installs Test.app. This will go under /Applications/Test.localized and our app will not be removed.
3. The Test.app registers its launch daemon.
4. launchd starts the binary specified in the previously registered launch daemon. This will be executed as root.
5. Since we own the binary we will get root code execution.

That’s it.

Here is a video showing this working with an old version of Microsoft Teams.

POC

I think this is a problem at Apple side, as you can’t expect ALL third party vendors preparing for this edge case. We, as a security community, can either start reporting issues to every impacted third party vendor, which is not feasible and doesn’t scale, or we can get Apple fixing this.

So because this is an evolution of the issue I kept reporting for 7 years, I submitted a new ticket to Apple, OE110192294822. After 8 months going back and forth I had no luck convincing them that they should fix it. They closed it as “We’re unable to identify a security issue in your report.” and they claim it’s a problem in the installer.

I get that this is not the most exciting LPE, and yes, it does require the user installing a product in order to exploit this, but in enterprise environment these packages will be most likely installed or pushed down via MDM, where user interaction is not really needed, so it can be useful in a red teaming scenario.

Recommendation Link to heading

If you are third party vendor and reading this:

1. Considering the above please check your installer and if you run any privileged process from your application bundle, then try to do something about this on your end, e.g.:

2. Move it to another location, like /Library/PrivilegedHelpers or anywhere in /Library/.

3. Ensure during the installation that it goes to the right place. This will be really hard, as there are ton of race condition possibilities.

4. If you feel like, report this to Apple via Apple Security Reports and you can also refer to my original ticket, OE110192294822

5. If you are a security researcher:

6. If you find a vulnerable package, and I can assure you there are a ton of these, report it to the vendor, maybe you will also get some bounty.

7. You can also try convincing Apple, by reporting this via Apple Security Reports and you can also refer to my original ticket, OE110192294822.

Final Thoughts Link to heading

Not really :D