ESET patched a Mac flaw that let any local user gain root control (CVE-2026-7483)

The software you install to guard a Mac runs with more power than any ordinary account on the machine, which is exactly what makes a bug inside it worth so much. ESET disclosed a flaw in its Mac security products today that let any logged-in user write files onto the disk as root, the top account on macOS. There is no sign anyone used it, and fixed builds have been out since early July. The shape of the bug is still worth a minute, because it is the same mistake privileged macOS software keeps making.

The flaw is tracked as CVE-2026-7483, rated 8.5 on the CVSS 4.0 scale, and it affects ESET Endpoint Security for macOS and ESET Cyber Security for macOS. ESET credits Martin Orem of Binary House with the discovery. The company says that, to the best of its knowledge, no exploits for it exist in the wild.

What the flaw actually is

ESET ships a background service that runs as root so it can do the privileged work an antivirus needs, like touching protected files and system state. On macOS, programs talk to a helper like this over a channel called XPC. The safe pattern is that the root helper checks who is calling before it acts. This service did not. It accepted connections from any local user and never verified the caller, so an unprivileged account could ask it to write a file, with content the user controlled, anywhere on disk, as root.

Writing an arbitrary file as root is a well-worn path to full control. A root-owned file dropped into a startup or scheduling location runs as root the next time the system reads it, which turns a file write into code execution as the machine's most powerful account. That is why ESET scores the flaw high, with full impact to the confidentiality, integrity, and availability of the host. In vulnerability terms it is improper privilege management (CWE-269): a powerful helper trusting a caller it should have checked.

Who is actually exposed

This is a local flaw, not a remote one. An attacker cannot reach the service across the network; they need to already run code as some user on the Mac. So the real risk is post-compromise. A phishing payload or a second-stage tool that lands as a normal user now has a clean, reliable way to become root, without dropping a noisy exploit. It also matters on shared and managed Macs where more than one person holds an account.

That is a different kind of danger than a remote code-execution bug, and it deserves a different urgency. It is not a drop-everything emergency. It is a strong rung in an intrusion chain, and endpoint security software is a high-value place to find one precisely because it already sits at root.

Which versions are affected

The table lists the exact fixed build for each supported branch, and any Mac at or below the affected build on its line needs that update. One caveat sits outside the grid: the 8.0 line (8.0.7200.0 and earlier) is affected with no fix on that branch, so those hosts have to move to a supported release rather than take a point update.

Update the fixed build, then check for root-owned files

Patch every Mac in the fleet to a fixed build, and confirm the installed version on each host rather than the ones you assume already run the latest. Fleets trail the current release far more often than inventories suggest, and this is the kind of flaw where one forgotten laptop is the whole exposure.

Detection here is host-side, because there is nothing on the wire to catch. An arbitrary-file-write-as-root flaw leaves root-owned files in places an unprivileged user could not otherwise write, so the tell is a new root-owned file appearing right after ordinary user activity, especially in startup and scheduling locations such as LaunchDaemons, LaunchAgents, cron, and the periodic scripts. File integrity monitoring on those paths, paired with a build inventory of the security agent itself, is the practical check, and it is the kind of behavioral signal a managed detection service watches for whether or not a signature exists. The same discipline caught its Linux cousins, as we covered with a local-root flaw in the Linux kernel's XFS filesystem.

Your security agent is privileged attack surface

The root cause here is a recurring macOS pattern: a privileged helper that talks over XPC but does not verify which process is on the other end. Apple gives developers ways to check the calling program's code signature and entitlements before acting on its request. When a helper skips that check, any local process can ask it to do privileged work, and the helper obliges. It has bitten security and non-security vendors alike, and it keeps recurring because the insecure version works exactly the same as the secure one until someone looks.

The lesson for defenders is an uncomfortable one. The agents you deploy to watch the endpoint are themselves some of the most powerful local software running on it, and they belong in your patch and inventory discipline like anything else that runs as root. We have made the same point when attackers turned signed drivers into a way to kill endpoint defenses: the security stack is not exempt from being the attack surface. Update the Mac fleet to the fixed builds, treat a local privilege escalation in that stack as a rung an intruder climbs after they are already inside, and close it now, while nobody is using it.