JUMPSHOT: XM Cyber Uncovers Critical Local Privilege Escalation (CVE-2025-34352) in JumpCloud Agent

Phase 1: Finding an entry point

While searching for functions that interact with untrusted paths or processes, I found internal logic related to the uninstallation of JumpCloud Remote Assist, triggered during the removal of the main JumpCloud Agent.

Key Findings:

• The agent builds the full path to the Remote Assist folder dynamically based on environment variables.
• It looks for the uninstaller binary within the folder.
• It executes the binary.

So every uninstallation of the main JumpCloud agent will also uninstall all the other components including JumpCloud Remote Assist.

Let’s start exploring our functions.

The symbols are stripped but we can recover function names using Go’s internal pclntab metadata – see Ready, Set, Go — Golang Internals and Symbol Recovery | Google Cloud Blog. This data is embedded in the binary and allows us to map function addresses back to their original names.

Using this technique we can go from:

jumpcloud-agent.exe symbols stripped

to:

jumpcloud-agent.exe symbols restored

The following screenshot displays the functionality of a specific routine, assist_GetExecutablePath()

Building full path to JumpCloud Remote Assist folder

The code constructs a file path by combining the Windows %ProgramFiles% environment variable with the hardcoded string “JumpCloud Remote Assist” to target files in that specific application directory.

The function above is called by a function named assist_GetUninstallerPath()

Creating complete path to JumpCloud Remote Assist Uninstaller’s binary

The two functions combine the JumpCloud Remote Assist program directory path with the hardcoded uninstaller filename “Uninstall JumpCloud RemoteAssist.exe” to create the complete path to the uninstaller executable.

Uninstaller’s binary location

Let’s understand now where this path is needed and expected by the jumpcloud-agent.exe process.

Execution of uninstaller’s binary

Okay, we got a hit; the JumpCloud Remote Assists’s uninstaller path is requested in a function named agent_uninstallRemoteAssistAgent(), the function’s name is self explanatory.

We can clearly see that once the path to the uninstaller is built successfully, the jumpcloud-agent.exe process will execute it, and this starts to feel like a promising lead.

Now again, let’s see where this last function agent_uninstallRemoteAssistAgent() is called.

The function is called only in one place by a function named Agent_Uninstall() and here’s how it is implemented:

Main caller to the remote assist component uninstallation

The whole flow looks like the following:

From this we can clearly trace the execution flow:

• When the main agent is uninstalled, it also triggers the uninstallation of Remote Assist component.
• This is done as NT AUTHORITY\SYSTEM, since the call originates from the jumpcloud-agent.exe process.

Analyzing JumpCloud Remote Assist Uninstaller

Here’s the interesting part of a snapshot of what’s being executed when running the JumpCloud Remote Assist Uninstaller.

1. The process will check if file Un_A.exe under %TEMP%/~nsuA.tmp exists and here’s the operation’s flow:
   1. Existent? DeleteFileW(Un_A.exe) → WriteFile → Execute the file (CreateProcessW).
   2. Not existent? Create it (CreateFile) → WriteFile → Execute the file (CreateProcessW).

   

2.  The process deletes any file from Un_B.exe to Un_Z.exe (if existent) from the %TEMP%\~nsu.tmpA directory.This is the operations when the files do not exist:
   

   

This is the operations when one of these files (Un_B.exe in the example) exists:

So what we have is a JumpCloud process with NT AUTHORITY\SYSTEM privileges that is deleting, writing, and executing a file with a predictable filename from an untrusted path.

Now let’s see how we can exploit it.

Phase 2: Exploiting the Primitives

The core of the exploit involves Link Following, utilizing mount points and symbolic links to redirect the privileged I/O operation.

1. Arbitrary File Write → Denial of Service (DoS)

The write primitive allows an attacker to write arbitrary data to any file, including critical system drivers, using a Mount Point/Object Manager namespace attack (bypassing the need for SeCreateSymbolicLinkPrivilege).

2. Arbitrary File Delete → Local Privilege Escalation (LPE)

The delete primitive is exploited via a classic Time-of-Check to Time-of-Use (TOCTOU) race condition combined with a Windows Installer LPE technique (targeting C:\Config.Msi).

This vulnerability is a stark reminder that “classic” security flaws in agent technology remain a high-fidelity path to full host compromise.