CVE-2025-1729 - Privilege Escalation Using TPQMAssistant.exe

While digging into the internals of my new Lenovo ThinkPad P1 Gen7, I came across an unexpected discovery that quickly escalated from curiosity to a viable privilege escalation vulnerability.  

Every day at exactly 9:30AM, a scheduled task named:

Lenovo\TrackPointQuickMenu\Schedule\ActivationDailyScheduleTask

automatically launches the binary:

C:\ProgramData\Lenovo\TPQM\Assistant\TPQMAssistant.exe

This task only runs when a user is logged in, and what makes it particularly interesting is that this binary is vulnerable to dynamic-link library (DLL) sideloading—a classic and often-overlooked attack vector.

Writable Directory and Missing DLL

The directory housing TPQMAssistant.exe is writable by standard users, which is already a red flag. The folder’s permission allows the CREATOR OWNER to write files, meaning any local user can drop files into this location.

When the scheduled task (or the binary itself) is triggered, it attempts to load hostfxr.dll from its working directory but fails, resulting in a NAME NOT FOUND event. This tells us the binary is looking for a dependency that doesn't exist in its own directory—a perfect opportunity for sideloading.

The directory containing TPQMAssistant.exe is writable by users allowing new files to be added to the folder.

Code Execution

By placing a malicious hostfxr.dll in the same directory as TPQMAssistant.exe, we can hijack the loading process. When the binary is executed, it successfully loads our planted DLL and runs our code. In my proof of concept code, I simply show a message box to verify the code execution.

From User to Admin - Scheduled Privilege Escalation

While this alone is a solid foothold, the real escalation happens when a user with administrator privileges logs in. Because the scheduled task runs daily at 9:30AM in the context of the logged-in user, our malicious DLL will execute in the administrator’s session. Although the process will run in medium integrity, there are enough UAC bypasses out there to make this a viable privilege escalation if you wanted to go all the way. I decided to stop here, and I simply asked Lenovo if they needed full proof of concept code, since I already felt I had proved the vulnerability. As it turns out, this was enough for them to start fixing it. The attack flow would be to log in as a normal user, plant the malicious code, log off, and wait for a local admin to use the machine to get the code executed.

Mitigation

Lenovo’s Product Security Incident Response Team (PSIRT) sent me a fix that I tested out and verified. The fix was to install the version 1.12.54.0 of TrackPoint Quick Menu from the Microsoft Store that they had released. The 1.12.54.0 version addresses the privilege escalation vulnerability since this is a UWP application that stores data under c:\program files\ instead. The UWP version can be found here: https://apps.microsoft.com/detail/9mz08jf4t3ng

However, this did not remove the existing win32 version of the application or the scheduled task, leaving it vulnerable. After this was communicated to the PSIRT, they responded as follows:

“The update package for preloaded TPQM will be delivered via System Update, our mechanism for automatically pulling in updates to applications, firmware, and drivers. The new package will move the standard installation path of TPQM scheduler from the C:\ProgramData directory to C:\Program Files (x86)\Lenovo\TPQM\TPQMAssistant. It will also check if the scheduler executable is already registered under C:\ProgramData path, and if so, will delete the path and uninstall the scheduler before moving forward with creating a new path for the scheduler under the C:\Program Files (x86) directory.”

Based on this, it seems that the issue will be fixed once they start to deploy the software.

Final Thoughts

Working with the PSIRT has been a pleasure—they respond quickly and are polite and forthcoming in communications. They also sent me information during the process without me having to ask multiple times. The only thing I wished for was a reward for security researchers such as swag or prize money, which could lead to more discoveries from security researchers (in my opinion). I did receive a Certificate of Appreciation.

Timeline

January 30, 2025 - Initial discovery
January 31, 2025 - First email sent to PSIRT about the discovery
January 31, 2025 - Tracking number and confirmation that it is being reviewed by the development team
February 18, 2025 - Confirmation from PSIRT development team about the issue and a fix will be produced
February 26, 2025 - Information that fix is scheduled for June 10
June 22, 2025 - Information about a delay in the deployment of the fix; New date set to July 08
June 30, 2025 - Mail about released UWP application that can be tested to confirm fix
July 01, 2025 - Sent email that the issue is not present in UWP, but it does not remove existing issue from the machine
July 01, 2025 - PSIRT responded that they are working on a fix that that will be distributed via system update for users that have preloaded version of the software that will remove the scheduled task and old executable