Tenable Discovers Critical Vulnerabilities in SimpleHelp Tool: CVE-2025-36727 and CVE-2025-36728

Tenable Research found two flaws in SimpleHelp’s remote-support tool that can be chained together to gain remote code execution on clients' devices. SimpleHelp has patched them: CVE-2025-36728 in version 5.5.11 and CVE-2025-36727 in version 5.5.12.

Remote support tools are essential software that allow IT professionals to remotely access and control devices for technical assistance and maintenance. While they offer features like screen sharing and file transfer, they are a major security risk, as their compromise could grant attackers widespread access and privileges across an entire network.

In this blog, we’ll describe our discovery of two vulnerabilities in SimpleHelp’s eponymous remote support tool. When chained, these vulnerabilities could provide a direct path from a click on a malicious URL to remote code execution (RCE). Here’s how these vulnerabilities work and how they can be connected together to achieve RCE on devices of IT support staff and end users.

How does SimpleHelp work?

At a high level, here’s how SimpleHelp works:

1. Server component: Organizations run a SimpleHelp web server (on-premises or hosted) that brokers connections.
2. Technician console: IT staff use the Technician Console desktop app to connect, transfer files or take remote control.
3. Customer client / installer: End users download a support app via a link, which then connects back to the SimpleHelp server.
4. Unattended access: Persistent agents can be installed for always-on access.
5. Update and installer distribution: The platform regularly fetches binaries and config files from the server to bootstrap sessions.

This design makes SimpleHelp convenient, but it also creates a critical trust boundary around installers and configuration files. Let’s look at how clients obtain the remote-support installers and how those applications interact with the server.

Cross-site request forgery in hostname parameter (CVE-2025-36728)

If a client wants to get remote support, they are directed to the /customer path, where they will see a “Download Remote Support” button. If we click on this, we are directed to this URL: https://<SERVER-ADDRESS>/customer/Remote%20Support-windows64-offline.exe?language=en&hostname=https%3A%2F%2F<SERVER-ADDRESS>
 

^{SimpleHelp client download portal}

When we first saw this, it seemed unusual for there to be a hostname parameter that specifies a URL. This made us think of previous server-side request forgery (SSRF) vulnerability findings that involved a URL parameter accepting an address that the server would then reach out to.

 By changing this value to that of a webserver we controlled on a different address, we noticed that when the installer was run, it would connect to our fake server and start requesting resources to carry out the installation.
 

^{Python3 http.server logs}

From this, it became clear that the hostname parameter accepts custom values which determine where the installer reaches out for additional files required for the installation of the client software. An attacker could craft a link that silently redirects the client to their own server where they can host their own malicious files.

In order to impersonate a SimpleHelp server, we leveraged Python's http.server module. Note that our server responded with “404” error codes because the resources were not found. We will change this later.

Inclusion of functionality from untrusted control sphere (CVE-2025-36727)

When a user downloads a support or technician binary and runs it, a number of files are downloaded, as we can see from the logs from our python3 server below.

Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
<CLIENT-ADDRESS> - - [09/Sep/2025 11:57:50] code 404, message File not found
<CLIENT-ADDRESS> - - [09/Sep/2025 11:57:50] "GET /customer/JWrapper-Windows64JRE-version.txt?time=791858819&platform=windows-intel-64&osid=w10-0-22631 HTTP/1.1" 404 -
<CLIENT-ADDRESS> - - [09/Sep/2025 11:57:50] code 404, message File not found
<CLIENT-ADDRESS> - - [09/Sep/2025 11:57:50] "GET /customer/JWrapper-Windows64JRE-version.txt?time=791858819&platform=windows-intel-64&osid=w10-0-22631 HTTP/1.1" 404 -
<CLIENT-ADDRESS> - - [09/Sep/2025 11:57:50] code 404, message File not found
<CLIENT-ADDRESS> - - [09/Sep/2025 11:57:50] "GET /customer/JWrapper-Windows64JRE-version.txt?time=791858819&platform=windows-intel-64&osid=w10-0-22631 HTTP/1.1" 404 -
<CLIENT-ADDRESS> - - [09/Sep/2025 11:57:52] "GET /customer/JWrapper-Remote%20Support-version.txt?platform=windows-intel-64&osid=w10-0-22631&guv=00114155471 HTTP/1.1" 200 -
<CLIENT-ADDRESS> - - [09/Sep/2025 11:57:53] "GET /customer/JWrapper-JWrapper-version.txt?platform=windows-intel-64&osid=w10-0-22631&guv=00114155471 HTTP/1.1" 200 -
<CLIENT-ADDRESS> - - [09/Sep/2025 11:57:53] "GET /customer/JWrapper-Remote%20Support-version.txt?platform=windows-intel-64&osid=w10-0-22631&guv=00114155471 HTTP/1.1" 200 -
<CLIENT-ADDRESS> - - [09/Sep/2025 11:57:53] "GET /customer/Remote%20Support-windows64-offline.exe?hostname=http%3A%2F%2F<SERVER-ADDRESS>%3A8000&platform=windows-intel-64&osid=w10-0-22631 HTTP/1.1" 200 -

There did not appear to be any validation that the retrieved files were from a legitimate source, since we were able to spoof all of them.

Most notably Remote Support-windows64-offline.exe was downloaded and executed without any verification.

For our proof of concept, we created a custom executable in C that executes calc.exe, put it in the spoofed server’s directory and named it Remote%20Support-windows64-offline.exe.

Once the client ran the binary, it loaded our custom executable, executed calc, and displayed our system alert.
 

^{PoC output on client device}

Chained attack: From link to RCE

Individually, each flaw was limited in terms of how an attacker could exploit it. For example, in the case of CVE-2025-36727, an attacker would have to carry out a man-in-the-middle attack to intercept the client-to-server requests, and those requests would also have to be unencrypted.

Chained together, they form a viable attack path:
 

Defensive guidance

Recent research from Tenable highlights how attackers often abuse vulnerabilities in remote-access tools like SimpleHelp and recommends strategies to strengthen defense strategies, including:

• Maintain an inventory of authorized RMM tools and flag and block unauthorized installations.
• Audit RMM session activity, review logs for unexpected or abnormal behavior.
• Monitor network traffic for RMM patterns, installer downloads, unexpected connections or proxy use.
• Scan the environment to look for listening services that are linked to known RMM tools.

Closing thoughts

This chain demonstrates how two vulnerabilities, which on their own may appear difficult to exploit, can be combined into a viable critical RCE scenario. Attackers rarely rely on a single bug; they often stack different vulnerabilities until they create a path to full system compromise.

The Tenable research cited earlier shows that threat actors are actively abusing legitimate RMM tools to persist, escalate privileges and blend into normal IT operations. The flaws discovered in SimpleHelp fit squarely into this trend, giving attackers another way to hijack trust in remote support software.

The key takeaway: Security teams and vendors must evaluate not only how issues behave in isolation, but also how they interact and how adversaries exploit trusted tools to achieve their goals.

We wish to thank SimpleHelp for acknowledging and responding to our notification of the vulnerabilities and for fixing them. 

Click here to learn how the Tenable One Exposure Management Platform gives you full visibility across your entire attack surface.