SYSTEM in Seconds: How MSI Center Became a Privilege-Escalation Bug

A patched-but-instructive Windows flaw (CVE-2024-37726) that turned a motherboard utility into a full system takeover — and why every “helper” app running as SYSTEM deserves a second look.

You install a new motherboard or GPU and, almost as a reflex, you install the vendor’s control-panel app that comes with it — the one that tweaks RGB lighting, spins the fans, and shows your temperatures. It’s the kind of software nobody thinks about twice. Which is exactly why it’s such a good place for a privilege-escalation bug to hide.

MSI Center — MSI’s bundled utility — had one. In versions 2.0.36.0 and earlier, a completely unprivileged user could turn it into a lever that pried open NT AUTHORITY\SYSTEM, the highest privilege level on Windows. Here’s how a “harmless” feature became a full compromise, why this whole class of bug keeps recurring, and what actually fixes it.

The setup: a helpful feature with too much power

Like most of these utilities, MSI Center runs a background service as SYSTEM so it can read hardware sensors and touch protected parts of the machine. That’s normal. The problem starts with a convenience feature: Export System Info, which writes a report file to a location you choose.

Read that again. A process running as SYSTEM is writing a file into a folder a normal user controls. That single sentence is the entire vulnerability. When a high-privileged process performs file operations inside a directory a low-privileged user can manipulate, you have the raw ingredients for privilege escalation — the user gets to change the ground under the privileged process’s feet.

The trick: winning a race the process didn’t know it was in

The naive assumption in the code is that the path it’s about to write is the path it will actually write. On Windows, that assumption is false, and there are two well-worn primitives that break it:

• OpLocks (opportunistic locks). A normal user can place a lock on a file that pauses any process the instant it tries to open it. That freezes the SYSTEM service at the exact moment of the write — turning a microsecond race into a comfortable pause the attacker fully controls.
• Junctions and symlinks. While the service is frozen, the attacker swaps the innocent target directory for a reparse point — a redirect — pointing somewhere else entirely. When the lock is released and SYSTEM resumes, it dutifully follows the redirect and writes to a path it was never meant to touch.

Chain those together and the SYSTEM process can be steered into overwriting, deleting, or creating any file on the machine. This is a classic TOCTOU bug — time-of-check to time-of-use — where what the program validated and what it acted on are no longer the same thing.

From “write a file” to “own the box”

Arbitrary file write as SYSTEM sounds abstract until you remember one folder: the All Users Startup directory. Anything placed there runs automatically the next time any user — including an administrator — logs in. Redirect the privileged write into that folder, drop a script, and wait. The next admin login executes attacker-chosen code with full privileges. Game over.

No memory corruption, no exotic exploit, no zero-day in the kernel. Just file-handling logic that trusted a path it shouldn’t have.

Why this keeps happening

The uncomfortable part isn’t MSI specifically — it’s the pattern. Motherboard, GPU, and peripheral vendors all ship “helper” apps, and those apps almost always install a SYSTEM-level service so they can do privileged things. Each one is extra attack surface running at the highest privilege on your machine, written under deadline pressure by teams whose job is fan curves and lighting effects, not adversarial file-system races. Security researchers have found this same shape — privileged process, user-controlled path, symlink redirect — in vendor utility after vendor utility.

What actually fixes it

MSI patched this in version 2.0.38.0 (released July 3, 2024), and if you run MSI Center the single most useful takeaway is: update it, or remove it if you don’t use it. Every SYSTEM helper service you don’t need is risk you’re carrying for no benefit.

If you write this kind of software, the defenses are well established:

• Don’t do privileged file operations in user-writable locations. If SYSTEM must write a file, write it somewhere only SYSTEM can reach, then hand it to the user — not the other way around.
• Impersonate the user for actions taken on their behalf, so the write happens with their token and their permissions, not SYSTEM’s.
• Refuse to follow reparse points on privileged paths, and re-validate the final target after opening the handle, not before.
• Drop privileges. If a task doesn’t genuinely need SYSTEM, don’t run it as SYSTEM. Least privilege isn’t a slogan; it’s the difference between a bug and a breach.

The takeaway

The scariest vulnerabilities usually aren’t the cinematic ones. They’re a privileged process, a path someone else controls, and an assumption that the file you checked is the file you’ll write. MSI Center’s bug is patched — but the pattern is sitting in a lot of software you didn’t choose and rarely open. Audit what runs as SYSTEM on your machine. Uninstall the helpers you don’t use. And if you build privileged software, treat every user-controllable path as hostile — because eventually one of them will be.