SSTI is particularly dangerous when a template engine exposes powerful objects, functions or operating-system interfaces to the rendering environment.

• Primary risk: Untrusted input is evaluated as template syntax.

• Common entry points: Email templates, page rendering, report generation and customisable document templates.

• Potential impact: Information disclosure, server-side code execution and application compromise.

• Key investigation evidence: Application input, rendered output, template errors, process execution and outbound network activity.

• Primary defences: Separate data from templates, use safe rendering APIs, restrict template capabilities and enforce least privilege.

1. When Text Becomes Executable

Imagine a company operates a web application that generates personalised welcome messages. Users can enter their names, and the application inserts those names into a template before displaying the final message.

Under normal circumstances, the application treats a name as data. If a user enters Alex, the rendered page displays Welcome, Alex.

Now consider what happens when an application passes user-controlled input into a template engine as part of the template itself.

Instead of treating the input as plain text, the engine may interpret special template syntax and evaluate it.

This creates a potential Server-Side Template Injection vulnerability.

The difference is fundamental: the problem is not simply that user input appears in a template; it is that user input can influence the template instructions being executed.

When an attacker discovers this behaviour, the impact depends on the capabilities available inside the rendering environment. A restricted template engine may expose only limited information, while a poorly isolated engine may provide access to sensitive application objects or dangerous functions.

2. How Template Engines Work

Template engines allow developers to combine static content with dynamic values.

They are commonly used to generate:

• HTML pages.

• Transactional emails.

• PDF reports and invoices.

• Notification messages.

• Configuration files.

• Dynamic documents and dashboards.

A developer typically defines a template containing placeholders or expressions. The application supplies the relevant data, and the engine renders the final output.

For example, a conceptual template might look like this:

Welcome, {{ username }}

If the application supplies Alex as the value of username, the intended result is:

Welcome, Alex

The syntax shown here is illustrative and resembles syntax used by some template engines. Exact syntax and evaluation rules vary by engine.

The secure approach

The template is defined by the application, while user input is supplied as a variable:

Template: Welcome, {{ username }} Data: username = "Alex"

The template engine evaluates the trusted template and inserts the supplied value as data.

The vulnerable approach

A dangerous design constructs a template by concatenating untrusted input into its source before rendering it.

Conceptually:

template_source = "Welcome, " + user_input render(template_source)

If the user can introduce template expressions and the engine evaluates them, the input may become executable template syntax.

This distinction explains why output encoding alone is not always sufficient to prevent SSTI. The core issue is how the application constructs and evaluates the template.

3. How Attackers Identify SSTI

During an authorised security assessment, an analyst may investigate fields that appear to influence dynamically rendered content.

Examples include:

• Customisable greetings and messages.

• Email subjects or bodies.

• Report titles.

• Product descriptions processed by a template engine.

• User-defined notification formats.

• Template preview and document-generation features.

A typical assessment follows several stages.

Stage 1 — Identify a rendering feature. Determine where user-controlled values influence server-generated output.

Stage 2 — Observe the baseline. Record how ordinary input appears in the rendered response.

Stage 3 — Test expression handling safely. In an authorised test environment, use harmless arithmetic or engine-specific test expressions to determine whether the application evaluates template syntax.

Stage 4 — Identify the engine. Use documented syntax, error messages and application dependencies to establish which template engine may be involved.

Stage 5 — Assess the available capabilities. Determine whether the rendering context is restricted or exposes sensitive objects, functions or operating-system interfaces.

Stage 6 — Establish impact. Confirm the vulnerability's practical consequences using non-destructive tests and the minimum necessary permissions.

A single unusual response is not sufficient to prove SSTI. Some applications intentionally evaluate expressions, and some error messages may arise from ordinary parsing or validation failures.

4. From Template Evaluation to Server Compromise

SSTI does not always lead to remote code execution. The potential escalation depends on the template engine, its configuration, the application framework and the privileges of the process performing the rendering.

Stage 1: Template expression evaluation

The attacker discovers that user-controlled content is interpreted as a template expression.

At this stage, the impact may be limited to evaluating expressions or accessing values exposed by the template context.

Stage 2: Information disclosure

Some rendering contexts expose application variables, object properties, configuration values or other internal data.

If the attacker can access these objects, sensitive information may be disclosed. Whether secrets are accessible depends on what the application passes into the template and how the engine isolates its context.

Stage 3: Access to powerful objects or functions

Certain template engines and framework integrations expose functionality beyond simple text substitution.

If the rendering environment allows access to powerful objects, reflection mechanisms, imported modules or callable functions, the consequences may become more serious.

This is an implementation-specific risk rather than a universal property of every template engine.

Stage 4: Server-side code execution

In vulnerable configurations, an attacker may be able to reach functionality that executes code or invokes operating-system commands.

Successful execution occurs in the security context of the application process. Its permissions determine which files, services and system resources may be accessible.

Stage 5: Follow-on activity

If code execution is achieved, an attacker may attempt to access application secrets, establish persistence, communicate with external infrastructure or reach other systems.

These activities require additional capabilities and should be investigated separately. SSTI does not automatically imply privilege escalation, lateral movement or complete host compromise.

5. Common Template Engines and Their Security Considerations

Different template engines expose different expression languages and capabilities. Defenders should identify the engine in use rather than assume that one detection or mitigation works everywhere.

Template engineCommon ecosystemSecurity considerationJinja2Python applicationsReview sandboxing, exposed objects and environment configurationTwigPHP applicationsReview sandbox policies and the functions or objects available to templatesFreeMarkerJava applicationsReview exposed Java objects, built-ins and template configurationThymeleafJava applicationsReview expression evaluation and access to application contextHandlebarsJavaScript applications and other ecosystemsReview helpers, partials and any custom functionality exposed to templatesPugNode.js applicationsReview how templates are constructed and whether untrusted content can become executable template code

These engines differ substantially. Some provide features that can be dangerous when exposed to untrusted templates, while others restrict available functionality by default or through configuration.

The presence of a particular engine is not evidence that an application is vulnerable. The key question is whether an attacker-controlled value can influence template instructions and what those instructions are permitted to do.

6. Investigating SSTI in a SOC

Consider a hypothetical alert involving a web application that generates customer reports. The application begins recording unusual template syntax in report-title fields, followed by rendering errors and unexpected child-process activity.

The SOC team needs to establish whether this is a failed probing attempt, an exploitable SSTI vulnerability or evidence of successful compromise.

Step 1: Review the original HTTP requests

Examine reverse proxy, WAF and application logs for the affected endpoint.

Look for:

• Unusual expression delimiters or template-specific syntax.

• Repeated requests using different expression patterns.

• Input submitted to fields that influence server-generated content.

• Rendering errors that begin after suspicious requests.

• Requests to report-generation, preview or email-rendering functions.

Preserve the original request where available, including timestamps, relevant parameters and response metadata. Redact authentication tokens, session cookies and sensitive customer information.

Step 2: Identify the template engine

Review application dependencies, framework configuration, source code and deployment records.

If source code is unavailable, error messages and response behaviour may provide clues, but they should not be treated as definitive identification.

Establish whether the application uses a fixed trusted template with variables or constructs template source from user-controlled input.

Step 3: Correlate application and endpoint telemetry

Review process-creation events, application logs, EDR data and outbound network connections.

Investigate unexpected child processes spawned by web server or application processes, particularly when they occur shortly after suspicious template-related requests.

Process creation alone does not prove SSTI. Report generators, image converters and other legitimate application features may also spawn child processes.

Step 4: Review possible information exposure

Determine whether template evaluation could have exposed:

• Application configuration.

• Environment variables.

• Internal object properties.

• Database connection details.

• API keys or other credentials.

• Files accessible to the application process.

Establish what the vulnerable rendering context could access and whether evidence indicates that the information was returned to an attacker.

Step 5: Investigate potential code execution

If suspicious process activity is observed, examine:

• Parent and child process relationships.

• Command-line arguments.

• File and directory modifications.

• Network connections.

• Changes to application configuration.

• EDR alerts and endpoint timelines.

• Subsequent identity or cloud activity, where relevant.

Correlate the activity with the original web requests. If the evidence supports execution through the application, investigate the event as a potential application compromise rather than merely a template-parsing error.

Step 6: Determine scope and contain the issue

Identify affected application instances, endpoints, template types and deployment versions.

Where exploitation is plausible, disable the affected feature or restrict access while preserving evidence. Correct the template construction or execution controls, review potentially exposed credentials, and investigate follow-on activity before restoring the service.

7. Evidence and Indicators to Review

SSTI does not have a universal indicator of compromise. Investigations should combine application-level evidence with endpoint and network telemetry.

Evidence sourceWhat to investigateWAF and reverse proxy logsTemplate-like expressions and repeated probing requestsApplication logsRendering errors, unexpected evaluations and template exceptionsSource code and dependenciesDynamic template construction and unsafe rendering APIsEDR telemetryUnexpected child processes or suspicious file activityProcess command linesCommands associated with the application process that lack a legitimate explanationFile integrity monitoringUnexpected changes to application files, scripts or configurationNetwork telemetryUnusual outbound connections following suspicious rendering activitySecrets and identity logsPotential access to credentials and subsequent useCloud audit logsUnexpected activity by the application's workload identity

Patterns that may warrant investigation

• A rendering endpoint receives repeated engine-specific expression probes.

• Template exceptions occur immediately after suspicious input.

• A web application process launches an unexpected shell or scripting interpreter.

• New files or configuration changes appear after template evaluation.

• Outbound connections originate from a rendering service without an established business purpose.

• Unusual credential or cloud API activity follows suspected exploitation.

These signals are investigative leads, not standalone proof of SSTI. Correlating request content, application behaviour and process telemetry provides stronger evidence than relying on any one indicator.

8. Detection Engineering and MITRE ATT&CK

A useful detection strategy correlates suspicious template input with evidence of server-side execution or other unexpected application behaviour.

Example detection logic

1. Identify application endpoints that render user-influenced content.

2. Detect suspicious template-expression patterns, accounting for the specific engine.

3. Correlate the request with rendering exceptions and application response anomalies.

4. Look for unexpected process creation, file modifications or outbound connections from the application process.

5. Enrich the alert with the affected host, application version, process identity and workload permissions.

6. Prioritise cases where independent telemetry supports successful exploitation.

Do not alert solely on the presence of braces, dollar signs or other characters used by template languages. Legitimate templates and ordinary user content may contain them. Detection rules should be engine-aware and context-sensitive.

MITRE ATT&CK mapping

The mapping depends on the behaviour confirmed during the investigation.

• T1190 — Exploit Public-Facing Application: Relevant when an attacker exploits a vulnerability in an internet-facing application.

• T1059 — Command and Scripting Interpreter: Potentially relevant when the incident includes execution through a command or scripting interpreter.

• T1552 — Unsecured Credentials: Potentially relevant if the attacker obtains credentials from accessible files, configuration or other unsecured locations, where the evidence supports the applicable technique.

• T1105 — Ingress Tool Transfer: Relevant only when evidence establishes that tools or files were transferred into the environment.

SSTI is a vulnerability class, not a single ATT&CK technique. Do not map every suspected SSTI event to all of the techniques listed above. Record only the behaviours supported by the investigation.

9. Preventing Server-Side Template Injection

The strongest defence is to ensure that untrusted data cannot become template source code and to limit the capabilities available during rendering.

Separate templates from data

Use trusted, predefined templates and pass user input through documented variable-binding mechanisms.

Avoid dynamically constructing template source by concatenating user-controlled strings. If users need customisable content, provide a restricted format or a purpose-built expression language rather than unrestricted template execution.

Use safe rendering APIs

Review framework documentation and select APIs designed to render trusted templates with supplied data.

Avoid evaluation functions or dynamic compilation mechanisms that interpret user input as template instructions unless there is a compelling, carefully controlled requirement.

Restrict template capabilities

Where the engine supports sandboxing or restricted execution contexts, disable unnecessary access to objects, functions, imports and filesystem operations.

Sandboxing is defence in depth, not a replacement for safe template construction. Its effectiveness depends on the engine, configuration and any exposed integrations.

Apply least privilege

Run rendering services with minimal operating-system permissions. Restrict filesystem access, network egress and access to application secrets.

Where practical, isolate document generation or user-customisable templates from sensitive application components.

Protect secrets

Avoid exposing credentials, API keys and sensitive configuration values to template contexts. Store secrets in an appropriate secret-management system and grant workloads access only to the credentials they require.

Monitor template-related activity

Log rendering failures and suspicious input patterns while avoiding the unnecessary collection of secrets or sensitive personal information.

Monitor application processes for unexpected execution and outbound network activity.

Test during development

Include template-injection testing in code reviews, security assessments and CI/CD checks. Verify that user-supplied content is rendered as data, not interpreted as template source.

10. Incident Response Checklist

When SSTI exploitation is suspected:

1. Preserve evidence: Collect HTTP requests, application logs, process telemetry and relevant network records.

2. Identify the rendering path: Determine which endpoint, template engine and code path processed the input.

3. Establish the impact: Confirm whether the issue permitted expression evaluation, information disclosure or code execution.

4. Contain the vulnerability: Disable or restrict the affected feature and limit unnecessary process and network capabilities.

5. Assess secret exposure: Review whether credentials or sensitive configuration could have been accessed; rotate affected secrets when warranted.

6. Investigate follow-on activity: Examine file changes, process execution, outbound traffic and identity activity.

7. Fix the root cause: Separate trusted templates from untrusted data and restrict template capabilities.

8. Validate and monitor: Retest safely, deploy the fix and watch for renewed exploitation attempts.

Conclusion

Server-Side Template Injection demonstrates how a seemingly minor rendering flaw can become a serious application security issue. When user-controlled input is interpreted as template instructions, the consequences may extend from unexpected expression evaluation to information disclosure or server-side code execution.

For SOC analysts, the key is to connect suspicious input with what happened inside the application process. For developers and security engineers, the priority is to keep template instructions separate from user data, restrict rendering capabilities and run application components with minimal privileges.

Not every SSTI vulnerability leads to server compromise. The actual risk depends on the template engine, the rendering context and the permissions available to the application. Nevertheless, a vulnerable rendering path should be investigated carefully because its impact may extend beyond the original web request.

The key lesson: User input should supply values to a template, never control the instructions the server executes.

Further Reading

• OWASP — Server-Side Template Injection

• PortSwigger Web Security Academy — Server-Side Template Injection

• OWASP — Injection Prevention Cheat Sheet

• MITRE ATT&CK — T1190: Exploit Public-Facing Application

• Official security documentation for the template engine and application framework in use