A new technical study published yesterday by mobile-application security expert Egor Filatov details how commonplace mistakes in macOS “launchd” service configuration can give attackers an instant, code-signing-free jump from standard user to root.
At the heart of the flaw are XML property lists—known as plists—that tell the operating system which background daemons to start and where their executable files live.
Many commercial installers park those helper binaries inside the parent .app bundle under /Applications, a directory that any local user can delete or recreate.
If the application is later uninstalled but its LaunchDaemon plist remains behind, the system tries to run a non-existent file at boot, essentially handing intruders a blank cheque to drop malicious code in the expected location.
From Root to Routine—Attack Flow Simplified
Filatov’s proof-of-concept requires fewer than ten terminal commands.
First, the attacker writes a tiny C program that prints the current username to a text file, demonstrating command execution.
Second, they compile it with gcc and then rebuild the original, now-missing folder hierarchy:
c#include <stdlib.h>
int main(){system("echo $(whoami) > /tmp/owned.txt");}
bashgcc exploit.c -o myvpn
mkdir -p "/Applications/Test VPN.app/Contents/MacOS"
mv myvpn "/Applications/Test VPN.app/Contents/MacOS/Test VPN"
On the next reboot, macOS dutifully loads “Test VPN” as root, placing “root” inside /tmp/owned.txt.
A variant misuses the MachServices key, launching only when an attacker-supplied XPC client pings the advertised service name—ideal for stealthy, on-demand privilege escalation.
Vendors Begin Rolling Out Fixes Amid Disclosure
A preliminary vendor survey found at least nine popular VPN brands, several remote-desktop suites, and even cloud-storage clients affected.
Mozilla, Pritunl, and Tunnelblick confirmed receipt of vulnerability reports and plan to relocate helpers to the SIP-protected /Library/PrivilegedHelperTools directory.
Microsoft’s Defender already mitigates the risk by shipping a watchdog that erases plists when users drag the main application to the Trash.
Apple declined to comment but privately encourages developers to adopt the PrivilegedHelperTools model.
For users, the quickest safeguard is to audit /Library/LaunchDaemons, check each Program path, and delete orphaned plists that reference writable directories.
Although exploitation still requires local code execution, the newly charted shortcut to root strips away the final barrier for adversaries who have already tricked targets into installing malware, making prompt patching essential.
Future Work and Research Directions
Several fertile avenues remain unexplored.
First, systematic fuzzing of plist-parsing logic inside launchd could reveal memory-safety bugs co-located with the present configuration flaw, enabling direct remote code execution via malformed user-controlled launchd jobs.
Second, Apple might consider a hardened runtime revocation list that invalidates daemons whose Program path falls under a user-writable mount point after system integrity verification.
Third, machine-learning classifiers could mine historical Unified Log telemetry to flag sudden ServiceManagement-related path changes, giving enterprise security operations centres near-real-time visibility.
The power and convenience of launchd-managed Agents and Daemons underpin macOS’s seamless user experience, yet that same convenience becomes perilous when installer authors disregard path immutability constraints.
By tracing the entire lifecycle—from plist authoring through installation, potential uninstallation, exploitation mechanics, and incident response—this report underscores that the vulnerability class is not merely a collection of isolated vendor oversights but a systemic pattern amplified by developmental haste and inadequate QA pipelines.
Mitigation is conceptually straightforward: house privileged binaries in SIP-protected directories or atomically tear down plists when the parent bundle disappears.
Until such hygiene is universal, defenders must remain vigilant, routinely auditing LaunchDaemon entries and teaching users that dragging an application to Trash does not always drag its daemons with it.
The hope is that, by combining rigorous technical exposition with a digestible news summary, stakeholders at every expertise level can appreciate both the depth of the issue and the pragmatic steps required to shut the door on Daemon Ex Plist-style privilege escalations.
Find this Story Interesting! Follow us on Google News, LinkedIn, and X to Get More Instant updates
%20(1).webp?w=1200&resize=1200,0&ssl=1&description=At the heart of the flaw are XML property lists—known as plists—that tell the operating system which background daemons to start and where their executable files live.){kind=link}