Acer's PLANET9 ships a background service, PLANET9DAService, that runs as NT AUTHORITY\SYSTEM. The directory holding its executable had permissions that let a standard, non-admin user overwrite that executable. So any unprivileged user could drop their own binary in place of the service's, wait for the next service start or reboot, and have Windows run their code as SYSTEM. Full local privilege escalation, and the cleanest bug in the whole Acer batch. No protocol to reverse, no crypto to crack, just a wrong ACL on a file that runs as SYSTEM.

CVE: CVE-2026-50602
CWE: CWE-732, Incorrect Permission Assignment for Critical Resource
Affected: Acer PLANET9 background service (PLANET9DAService)
CVSS 4.0: 8.5 (High), AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Vendor advisory: Acer KB 19870
Published: 2026-08-17
Credit: Tolga Cöhce (@0xbigturk)
Why this is the first thing I check

When I go after OEM software, the very first pass is dumb and mechanical. I list every service running as SYSTEM, then look at the permissions on the files and folders each one launches from. It's the least glamorous check in the playbook and it pays out more than anything else, because the logic is airtight. If a service runs as SYSTEM, and a normal user can modify the file that service executes, then the normal user can run code as SYSTEM. There's no exploit to engineer. You're just swapping a file and letting the service do the rest. Vendors get this wrong constantly because the installer creates the directory with permissions inherited from somewhere too loose, and nobody ever audits the ACL after the fact.

PLANET9 was the first Acer service where that check lit up.

The target

Stock Acer Nitro ANV15-41, Windows 11 Home build 26200, OEM image. PLANET9 is Acer's gaming and community platform, and it installs PLANET9DAService, a background service configured to start as LocalSystem.

The service executable lives under C:\Program Files\PLANET9\. By convention, anything under Program Files should be writable only by administrators and SYSTEM; a standard user gets read-and-execute and nothing more. That convention is the entire security model for "it's fine to run this as SYSTEM." Break it and the whole thing collapses.

Finding the bad ACL

I enumerated SYSTEM services and their on-disk paths, then checked the ACL on each service binary and its parent directory. For PLANET9DAService, the executable's directory granted write/modify to a non-administrative group, the kind of entry that means a regular user can replace the file.

The quick way to see it:

icacls "C:\Program Files\PLANET9\<service executable>"

What you're looking for is any entry granting (M) modify, (W) write, or (F) full control to Users, Authenticated Users, Everyone, or the interactive user, on a file that a SYSTEM service executes. That's the whole bug. Confirm the service's run-as identity separately:

powershell

Get-CimInstance Win32_Service -Filter "Name='PLANET9DAService'" |
    Select-Object Name, StartName, State, PathName
# StartName = LocalSystem  ->  it runs as SYSTEM

SYSTEM-level service plus user-writable executable equals local privilege escalation. Both halves confirmed on a stock install, no modifications.

The exploit, and why it's trivial

The attack is just the definition of the bug carried out:

As a standard user, back up the real service executable.
Replace it with your payload (anything that runs as the service will run as SYSTEM: a dropper, a net user add-admin, a reverse shell).
Trigger a service restart. You don't need admin to wait. A reboot does it, and so does anything that recycles the service.
On start, the Service Control Manager launches your binary as NT AUTHORITY\SYSTEM.
powershell

As an unprivileged user:

`copy "C:\Program Files\PLANET9\<service exe>" "$env:TEMP\planet9_orig.bak"
copy ".\payload.exe" "C:\Program Files\PLANET9\<service exe>" # succeeds = you win`

then reboot, or wait for the service to cycle

If step two's copy succeeds from a normal account, it's over. You've written to a SYSTEM-executed path, and SYSTEM will run it for you on the next start.

Kill testing

This is the part I care most about, because an LPE claim is only as good as your attempt to break it. I ran the finding through 15 checks designed to disprove it before I'd submit, and all passed:

The permissive ACL is really there on a clean install, not something I or another tool loosened.
The write genuinely succeeds from a standard, non-elevated token, not just in an elevated prompt I forgot I'd opened.
The service really runs as LocalSystem, not as the logged-in user or a restricted service account.
The replaced binary actually executes on service start, rather than being validated, signature-checked, or rejected.
A standard user can cause a restart (reboot suffices), so the trigger isn't admin-gated.
No self-repair, no file-integrity check, no WDAC/AppLocker policy silently blocking the swap.

Only after none of those killed it did I write it up.

Impact

Any local, authenticated, non-administrative user goes to full SYSTEM. That's complete compromise of the machine, the VC:H/VI:H/VA:H across the board. It needs a foothold on the box (local vector, AV:L, and PR:L for the standard-user account), which is exactly the position malware, a limited guest account, or a second-stage payload is already in. It's the canonical "get a shell, become SYSTEM" primitive, handed over by a file permission.

Root cause

A directory under Program Files holding a SYSTEM service's executable was created with write access for ordinary users. The trust model for running anything as SYSTEM assumes only admins can change what that SYSTEM process executes; the ACL quietly broke that assumption. The code wasn't the problem. The permission on the code was.

The fix

The correct ACL on a SYSTEM service's binary and its directory is: Administrators and SYSTEM get full control, everyone else read-and-execute only, with no write/modify for Users, Authenticated Users, Everyone, or the interactive user. Set it at install time and don't inherit it from a looser parent. Acer corrected the permissions on the PLANET9 executable in their fix. See Acer KB 19870.

Timeline

2026-03-20: Reported; also filed to ZDI as case bigturk0001.
Spring 2026: Acer triages and verifies; CVE ID reserved in June.
2026-08-17: Acer publishes advisory KB 19870; CVE-2026-50602 assigned. First of my Acer findings to go public, about a month ahead of the NitroSense/PredatorSense batch.
2026-10-12: This writeup.