What Is Server-Side Template Injection (SSTI)?

What is server-side template injection?

Server-side template injection happens when an application takes user input and places it directly into a server-side template that is then evaluated by a template engine. Template engines exist to turn templates into output by evaluating the expressions inside them. When attacker-controlled input becomes part of the template itself, rather than data passed into it, the attacker can write expressions the engine will run.

The distinction that matters is data versus template. Passing user input into a template as a value is safe. Concatenating user input into the template string that the engine parses is not. SSTI is what happens when the second occurs.

How SSTI leads to remote code execution

Template engines are more powerful than they look. Many can read object attributes, call methods, and reach language built-ins from inside an expression. An attacker who can inject template syntax first confirms the engine is evaluating their input, then walks from a harmless expression to one that reaches a dangerous function. In many engines that path ends at process execution, which turns SSTI into remote code execution.

This is why SSTI is rated so severe. It is not only about leaking a template variable. It is a foothold that frequently escalates to running code on the server.

Where SSTI shows up

SSTI appears wherever applications build templates dynamically from user input: email and document generation, customizable dashboards or reports, marketing tools that let users define content, and any feature that lets input influence the template rather than only its data. It affects common engines across languages, and framework-level cases turn up regularly in disclosed CVEs. For real examples, see the CVE archive.

How SSTI differs from cross-site scripting

SSTI and cross-site scripting (XSS) both come from unsanitized input meeting a rendering step, but they execute in different places. XSS runs in the victim's browser. SSTI runs on the server, inside the template engine, which is why its worst case is server-side code execution rather than client-side script. Confusing the two leads teams to apply output-encoding fixes that do nothing for a server-side evaluation problem.

How to prevent and detect SSTI

Prevention starts with never building templates from user input. Pass user data as bound variables into a fixed template; do not concatenate it into the template source. Where user-defined templates are a genuine requirement, use a sandboxed or logic-less engine and restrict what expressions can reach. Input validation helps but is not sufficient on its own, because template syntax is broad.

Detection matters because SSTI is easy to introduce and its escalation to code execution can be subtle. Since a successful SSTI ends in code running on the server, runtime intelligence confirms whether a suspected SSTI path is actually reachable and executing, and application detection and response catches the moment an injected expression turns into a real code-execution event. Prioritize by reachability, then defend at runtime.

Frequently Asked Questions