In April 2025, Jorren Geurts, an ethical hacker at Resillion, identified a vulnerability within BeyondTrust Remote Desktop that enabled attackers to leverage Server-Side Template Injection (SSTI) to gain both authenticated and unauthenticated Remote Code Execution (RCE) on the target system.

The vulnerability was disclosed to BeyondTrust through their Responsible Disclosure program on 6 May 2025. A couple of weeks later, CVE-2025-5309 was reserved and later published on 16 June 2025.

The following account, written by Jorren, details the processes he went through to identify these vulnerabilities.

Summary

BeyondTrust Remote Support’s web application versions 24.2.2 to 24.2.4, 24.3.1 to 24.3.4 and 25.1.1 are all vulnerable to both authenticated and unauthenticated RCE through SSTI.

While both vectors pose a serious risk for the application’s users and data, the unauthenticated vector is particularly interesting due to the nature of the application offering (remote) support to its customers. At their core, both variants are the direct result of untrusted user input interacting with the underlying template engine and its functions.

BeyondTrust has published a security advisory related to the issue, which can be found here: BeyondTrust Security Advisory BT25-04. This advisory also details the fixed versions:

• Remote Support 24.2.2 to 24.2.4 with HELP-10826-2 Patch
• Remote Support 24.3.1 to 24.3.4 with HELP-10826-2 Patch
• Remote Support 25.1.1 with HELP-10826-1 Patch

Remote Support in a nutshell

Before getting into the good stuff, let’s take a moment to outline what Remote Support is. According to BeyondTrust’s own website, Remote Support is “a secure, enterprise-grade remote support solution that allows IT professionals to connect to and control remote systems and devices to provide technical support. It is used by IT service desks, help desks, and support teams to troubleshoot and resolve technical issues efficiently.”

To facilitate this, several components are used, from mobile apps to desktop and web applications. In the context of this piece, three available web applications are relevant:

1. Administrative Interface: This interface is generally used by administrator-level users and can be used to configure the solution.
2. Web Rep Console: The typical console where support requests come in. Here, authenticated Agents can accept, hold, transfer and close Remote Support sessions.
3. Customer Facing Interface: Best described as Remote Support’s ‘landing page’. Depending on the specific configuration, end-users can enter their Support Key here to initiate the support request or directly reach out to a specific or available Agent.

Using a combination of these three components, the vulnerability was identified. Now that that’s out of the way, let’s dive into the actual vulnerability.

Part 1: Server-Side Template Injection (SSTI)

During a recent engagement, I examined the web interfaces mentioned above. The Administrative Interface caught my eye immediately, as it had significantly more user-provided input compared to the other interfaces.

Reviewing the system, I found that several components, which the administrators control, allowed input that would be placed on the Customer Facing Interface. As an ethical hacker with a focus on web applications, a natural first step was to probe for Cross-Site Scripting (XSS) vulnerabilities. While there are multiple flavours of XSS, the stored variety was likely to be the most interesting one in this case. It quickly turned out that although payloads were accepted, the output was encoded correctly, so no clear XSS vector could be identified.

Next up was some quick fuzzing for SSTI vulnerabilities. SSTI, or Server-Side Template Injection, is an attack where native template syntax is used to inject a malicious payload into a template, which is then executed on the server. Like XSS, SSTI falls under OWASP’s A03:2021 – Injection category (the latest edition at time of writing).

It became clear that administrators could provide input that directly interfaced with the underlying template engine. As such, {{7*7}} appeared as 49 on the Customer Facing Interface that proved (some) interaction with the template engine in use was possible.

Interpreted default SSTI payload.

Now, the question became: “Which template engine are they using?”. According to this flowchart provided by the folks over at  Portswigger, the engine could be either Jinja2, Twig or something else entirely. As it turns out, it was the latter. Through trial and error, I came to the conclusion that the template engine being used was Blade, which is the default templating engine for the  Laravel framework. While the applications didn’t disclose the use of the Laravel framework directly, this was later confirmed – but stay tuned for that!

Building on the previous payload, and knowing Blade uses PHP, the following proof-of-concept payload was used: {{implode(null,array_map(chr(99).chr(104).chr(114),[105,100]))}}.

Let’s take some time to explain this payload. Blade uses the built-in chr function to convert decimal values into their corresponding characters. These characters are then inserted into an array_map and are subsequently joined together using the implode function to form a string. The 105 and 100 represent the i and d characters.

As expected, this rendered on the Customer Facing Interface as the string id.

Reflected id string.

Having proven that PHP functions like chr, array_map and implode can be used to display valid output, the only step that remained was to make Blade execute our proof-of-concept payload.

Part 2: Remote Code Execution (RCE)

PHP contains several functions that allow it to execute system commands. To execute our command, the previous payload was passed to the passthru function. Wrapping our command in this function results in {{passthru(implode(null,array_map(chr(99).chr(104).chr(114),[105,100])))}}.

If successful, the payload would execute the id command and display the effective user and group IDs on the target system. Since you made it this far, it’s probably not a surprise that this indeed worked!

Execution of the id command.

Using this, an authenticated user with administrative privileges can execute arbitrary system commands on the target server, ultimately gaining shell access to the system.

Speaking of shell access, several files on the target system were made accessible through this and, as suspected earlier, confirmed the application was built using Laravel in the composer.json file.

Target composer.json file contents.

Authenticated or unauthenticated?

From here, I decided to try and dig a little bit deeper to see if this could be leveraged by anyone other than the application administrators.

Since the SSTI payloads appear to trigger on the Customer Facing Interface, which is typically visited by unauthenticated end-users, I decided to focus on identifying opportunities where users of this particular interface have control over the input going into the application.

As users in a support session can chat with their Agent, the most obvious vector would be just this. However, all input appeared to be handled correctly by the application, so I had to look further.

In doing so, I discovered that Administrative Interface users can view the chat of ongoing and past support sessions. It’s worth noting that users of the Administrative Interface don’t necessarily have administrative privileges – just access to the particular interface with other functionality. This could be an interesting vector for our unauthenticated perspective.

To get started, I set up another support session between an Agent on the Web Rep Console and an unauthenticated end-user and started chatting once again. After some messages were exchanged, I could use the Agent’s perspective to view the chat messages that were just sent, and they showed up exactly as I sent them from the end-user perspective. We might be in business here…

Following this, it was time to try and input some of the previously mentioned SSTI payloads. I started with the tried and tested {{7*7}} and was thrilled when it showed up in the chat transcript as the 49 we saw before. This meant that the same SSTI vulnerability was probably present in the chat functionality of a support session.

Basic SSTI payload rendered when viewing a chat transcript.

Everything was looking promising, so expanding on this, I once again set up a remote support session but this time went with the reliable {{passthru(implode(null,array_map(chr(99).chr(104).chr(114),[105,100])))}} payload and quickly went back to view the chat transcript.

Interpreted payload in a chat transcript.

As expected, the RCE payload was interpreted by the application again, revealing the unauthenticated RCE. The only prerequisite in this scenario is an active support session and for a user on the Administrative Interface to view the chat transcript.

No Session Key, no problem!

Ultimately, this was a great result. To go from an unauthenticated end-user, to execute commands on the server is a significant success from an ethical hacker’s perspective but incredibly scary for the application’s users and, particularly, its vendor.

But there’s more to the story than this. The application offers its administrators the option to configure the application so that end-users can directly request support with a specific or available support Agent. This thus circumvents the need for a Session Key and only requires the Agent to accept the request to set up a Remote Support session.

Querying the version of Remote Support.

Whenever this particular configuration is used, the chances of malicious payloads reaching their intended users is noteworthily increased. Moreover, as viewing chat transcripts is part of its intended use, it is to be expected that such an attack will result in successful exploitation.

Mitigation

At the time of writing, the SSTI itself has not been resolved, which could mean that other attacks exploiting the interpretation of templates may still be effective. However, BeyondTrust has removed the ability to call dangerous PHP functions such as passthru, system and exec (among others). This means that using a payload like {{implode(null,array_map(chr(99).chr(104).chr(114),[105,100]))}}, is still allowed (after all, this only prints the string id). While payloads that try to wrap the above in a dangerous PHP function result in a server error upon calling the payload, such as {{exec(implode(null,array_map(chr(99).chr(104).chr(114),[105,100])))}}.

The version of Remote Support can be queried by browsing to the specific base URL and appending the following: /get_rdf?comp=sdcust&locale_code=en-us. Opening the downloaded file with a text editor (or anything that displays file contents) displays the current version of the application on top of the output.

Configurations allowing direct support access.

Ultimately, data from potentially untrusted sources should never be passed to functions that can execute commands.

Timeline

• April 2025 – Initial findings discovered.
• 6 May 2025 – Responsible Disclosure submitted, response received.
• 22 May 2025 – Notified that the vulnerability was fixed in Remote Support 24.3.4 and announced the intend of publishing this blog post.
• 28 May 2025 – CVE-2025-5309 is reserved and public disclosure is delayed until the go-ahead from BeyondTrust.
• 16 June 2025 – CVE-2025-5309 is published.
• 16 June 2025 – BeyondTrust Security Advisory BT25-04 is released.
• 18 June 2025 – Release of this write-up.

Credits

Special thanks to Jim Blankendaal for reviewing this piece and advising me along the way during the Responsible Disclosure procedure.