Server-side template injection (SSTI): how it works, how testers detect it, how to fix it

Contexts matter. In a plaintext context the input appears in the page body, and {{7*7}} or ${7*7} can work as is. In a code context the input lands inside an existing expression. Testers then close the expression and check that appended HTML renders next to normal output, which PortSwigger calls "a key indication" of SSTI.

One result does not identify an engine. PortSwigger's example is {{7*'7'}}: it gives 49 in Twig and 7777777 in Jinja2.

This table lists arithmetic probes for 10 engines, based on each engine's own expression syntax. Run one probe, read the result, and stop.

Handlebars and Mustache are logic-less engines. PortSwigger recommends them where possible, because keeping logic apart from presentation limits the worst attacks.

Which real incidents involved template injection?#

A documented case is CVE-2023-22527 in Atlassian Confluence Data Center and Server. NVD published it on 16 January 2024 and describes "a template injection vulnerability on older versions" that allows an unauthenticated attacker to achieve RCE on an affected instance. NVD maps it to CWE-74, gives a CVSS v3.1 score of 9.8, and lists a CISA Known Exploited Vulnerabilities entry dated 24 January 2024. The record says most recent supported versions are not affected, and Atlassian recommends installing the latest version.

The case shows a pattern: a request parameter that reached a template engine on an internet-facing server, with no login needed. This page does not describe the exploit. Read the NVD record and the vendor advisory for affected versions and fixes.

Do sandboxes stop SSTI?#

A sandbox lowers the risk but does not remove it. The Jinja documentation says "the sandbox alone is not a solution for perfect security". It also warns that templates can still raise errors, and that "a relatively small template" can produce "a very large amount of output", so CPU and memory limits are advised. PortSwigger says sandboxing untrusted code is inherently difficult and prone to bypasses, and that exploitation is especially easy in unsandboxed environments.

Treat a sandbox as one layer. The primary control is to keep user input out of template source. The second layer is isolation: PortSwigger suggests running the template environment in a locked-down Docker container, on the assumption that code execution may eventually happen. Pass only data that the template needs, and avoid global objects with side effects (Jinja's advice).

How do you prevent SSTI?#

Prevent SSTI by treating user input as data. Pass it as a variable to a fixed template, and never build template text from it. If users must edit templates, use a logic-less engine, restrict what the template can reach, and render in an isolated process.

Flask and Jinja2 (Python)

# Vulnerable
return render_template_string("<p>Thanks, " + name + "!</p>")

# Safe: fixed template, user value passed as data (autoescape on)
return render_template_string("<p>Thanks, {{ name }}!</p>", name=name)
# Better: a template file in the templates folder
return render_template("thanks.html", name=name)

Django templates (Python)

from django.shortcuts import render
return render(request, "thanks.html", {"name": name})

Do not build a Template(...) object from user text. If users edit templates, use a sandboxed environment such as Jinja's ImmutableSandboxedEnvironment, with CPU and memory limits, as the Jinja documentation advises.

Express with Pug or EJS (Node.js)

// Vulnerable: user input compiled as a template
res.send(pug.render("p Thanks, " + name));

// Safe: fixed template file, user value as local data
res.render("thanks", { name });

In Pug, #{name} escapes output and !{name} does not. Keep untrusted values out of the template string and out of unescaped output.

Spring and Thymeleaf (Java)

// Safe pattern: fixed view name, data in the model
model.addAttribute("name", name);
return "thanks";

Do not build a view name or a fragment expression from request input. Use th:text for output, which escapes the value.

Rails and ERB (Ruby)

# Vulnerable
render inline: "<p>Thanks, #{params[:name]}!</p>"

# Safe: fixed template, value escaped on output
# app/views/cards/thanks.html.erb:  <p>Thanks, <%= params[:name] %>!</p>
render :thanks

Never pass user input to render inline: or ERB.new.

Twig, Smarty and Razor. Use the same pattern: load templates from files, pass user values as variables, and do not call the engine's string-render function with user text.

These examples show the pattern. Test them in your own framework version. Add a code search for string-render calls (render_template_string, Template(, render inline, ERB.new, pug.render, createTemplate).

What is the SSTI testing checklist?#

Use this list on each place where user input shows up in rendered output, and only inside the agreed scope.

1. List the places that render user text: greetings, emails, PDF and invoice templates, error pages, CMS and marketing editors, notification text, report builders.
2. Send the fuzz string for template characters and watch for errors.
3. Send the arithmetic probe for the likely engine. Compare with controls: a literal string, an unclosed expression and a HTML tag.
4. If you get 49, identify the engine with a second probe ({{7*'7'}}) and error messages.
5. Test code contexts: close the expression, then add a harmless tag.
6. Check stored values that are rendered later in emails, PDFs and admin pages, which may need a second session to read back.
7. Stop at the arithmetic proof. Running commands or reading files needs separate written approval in the scope.
8. Save requests, responses and timestamps. Report controls that held, such as parameters that escape output correctly.
9. Review the code for string-render calls and user-editable template features.

SSTI often sits next to OS command injection, because code execution in a template engine can start system commands. Test both when a template feature exists.

When should you get a professional test?#

Get a professional test when your application renders user-influenced text in emails, documents or admin pages, or when you let customers edit templates. Scanners catch simple reflected probes. Stored and second-order cases, such as a value rendered in an invoice PDF a day later, need controls and a read-back.

Excession Labs runs authorized web application penetration tests and API penetration tests. We agree the scope with you in writing, check the evidence for each finding and write the report. You can also apply for the free pentest pilot.