CVE-2025-68921: Local Privilege Escalation Affecting Millions of Gaming Laptops
Summary
This write-up details a local privilege escalation vulnerability that I reported to Lenovo PSIRT in January of last year. The issue affects an audio enhancement software pre-installed on many gaming laptops, including Lenovo Legion, IdeaPad Gaming, MSI, Thunderobot, and others. The vulnerability was tracked by Lenovo PSIRT as LEN-18785 and assigned CVE-2025-68921, allowing a low-privileged user to escalate privileges directly to NT AUTHORITY\SYSTEM.
Technical Details
The Vulnerable Component
Nahimic is an audio enhancement suite developed by A-Volute it consists of the Nahimic UWP App which is the user-facing application available through the Microsoft Store, NahimicService.exe which is a Windows service running as NT AUTHORITY\SYSTEM , and the Nahimic APO Driver for audio processing.
The Vulnerability Class
This vulnerability falls into the category of arbitrary file deletion leading to privilege escalation, a well-documented attack pattern. The core issue is that a privileged service running as SYSTEM performs file operations in a directory writable by standard users without validating whether it's operating on the intended file or following a symbolic link/junction.
An attacker can exploit this by replacing the target with a symlink/junction pointing elsewhere before the service completes its operation.
This vulnerability class has been extensively documented by Zero Day Initiative, Google Project Zero see references below.
Vulnerability Analysis
Root Cause
When a user interacts with the Remove Optimization or Optimize My Device buttons in the Nahimic UWP application, NahimicService.exe deletes the render.txt file located at C:\ProgramData\Nahimic\render.txt.
The vulnerability exists because C:\ProgramData\Nahimic\ inherit parent permissions allowing standard users to create, modify, and delete files and folders.
while NahimicService.exe runs as NT AUTHORITY\SYSTEM and performs file deletions with full privileges. The service neither impersonates the calling user nor performs any validation when following junctions or symbolic links.
Attack Vectors
Vector 1: Arbitrary File Deletion
An attacker can delete any file on the system, regardless of permissions, to exploit this, open the Nahimic application and delete the C:\ProgramData\Nahimic\ directory. Then recreate it as a junction pointing to \RPC Control\ in the object namespace, and create a symbolic link at \RPC Control\render.txt pointing to any target file such as a protected system DLL. When you click the Remove Optimization or Optimize My Device button, NahimicService.exe follows the junction chain and deletes the target file with SYSTEM privileges.
Vector 2: Local Privilege Escalation
arbitrary file deletion could be weaponized into full SYSTEM privilege escalation using the Windows Installer rollback mechanism.
The attack works by recreating C:\ProgramData\Nahimic\ as a junction pointing to \RPC Control\. Then create a symbolic link at \RPC Control\render.txt pointing to C:\Config.Msi::$INDEX_ALLOCATION. Clicking Remove Optimization or Optimize My Device causes NahimicService.exe to delete the C:\Config.Msi directory. We then recreate C:\Config.Msi with a weak ACL and place a fake rollback script inside it. When we trigger a rollback by failing an MSI installation, Windows Installer executes our fake rollback script with SYSTEM privileges, resulting in a command prompt running as NT AUTHORITY\SYSTEM.
I've previously documented this technique in detail in my write-up From DoS to Privilege Escalation, where I exploited an arbitrary folder deletion vulnerability in IObit Malware Fighter and turned it into a privilege escalation; however, that one was in a driver, not a service.
Triggering Without User Interaction ?
Yes, we can trigger this vulnerability without UWP interaction by sending an RPC to NahimicService.exe, but I was too lazy to add it 😄.
Patch Analysis
Attempt 1: Randomized Filenames (April 2025)
SteelSeries first mitigation replaced the predictable render_txt_copy.txt temporary filename with randomly generated names.
Why it failed: The vulnerability wasn't about predicting filenames. The service still deleted render.txt with SYSTEM privileges, and this operation was still vulnerable to symlink redirection.
Attempt 2: Incomplete FILE_FLAG_OPEN_REPARSE_POINT (July 2025)
The second attempt implemented the FILE_FLAG_OPEN_REPARSE_POINT flag, which prevents following reparse points during file operations.
Why it failed: the service still performed file operations on render.txt without the flag, leaving the vulnerability exploitable .
My Suggested Fix: ProcessRedirectionTrustPolicy (August 2025)
After the second patch bypass, I suggested implementing SetProcessMitigationPolicy with ProcessRedirectionTrustPolicy:
This policy causes Windows to block following junctions and symlinks created by non-administrative users, effectively preventing the entire class of attacks. However, implementing this required significant SDK changes that would have delayed the fix until Q4 2025.
Final Fix: Correct FILE_FLAG_OPEN_REPARSE_POINT Implementation (November 2025)
The final fix properly implemented FILE_FLAG_OPEN_REPARSE_POINT across all code paths that performed file operations in the vulnerable directory. This forces the file system to open the file itself rather than following reparse points, effectively mitigating the vulnerability without requiring the broader SDK changes.
The patch was officially released on December 29, 2025.
PoC
ZeroMemoryEx
Conclusion
This vulnerability highlights the impact of filesystem bugs, After reporting to Lenovo PSIRT, they coordinated with SteelSeries (the Nahimic developer) to address the issue. It took some time initially to explain the full impact of the vulnerability and demonstrate that early patch attempts were insufficient, but eventually the team understood the severity and implemented a proper fix.
I'd like to thank Lenovo PSIRT and the SteelSeries team for their collaboration throughout this nearly year-long disclosure process.
The Bigger Picture
Anas Hadane
