SSTI Lab: Read a Secret Through an Email Preview Template

This article describes a Server-Side Template Injection (SSTI) lab that demonstrates how email preview features can be exploited when template engines evaluate user input as expressions rather than treating it as plain data. The vulnerability occurs when applications allow users to supply template code instead of just data values, enabling attackers to access server-side objects and configuration secrets. Understanding SSTI is critical because it appears frequently in customizable features and can escalate from information disclosure to remote code execution.

• Template engine evaluates user expressionsMarketingHub's preview feature accepts placeholders like {{name}} and {{company}}, but the underlying template engine does not restrict evaluation to variable names—it evaluates any expression within the braces. This means an attacker can place arbitrary code such as arithmetic calculations or references to configuration objects, and the engine will compute and return the result into the rendered preview.
• Attack confirms evaluation with arithmeticThe lab attack strategy begins by inserting a simple calculation between braces to prove expressions are evaluated rather than printed literally. Once a computation renders correctly in the preview output, the attacker knows the template engine is executing code, not just substituting variables.
• Access server configuration through contextAfter confirming expression evaluation, an attacker can reference the template context's configuration object—such as config.flag—within the preview expression. The template engine then evaluates this reference and outputs the secret value into the rendered preview, making it visible to the attacker.
• Root cause: user supplies the templateThe vulnerability exists because the application allows users to control the template itself rather than only the data that fills it. This hands users an expression evaluator running on the server; the template was designed to substitute a name, but now executes arbitrary code the user provides.
• SSTI maps to OWASP Top 10 InjectionThe article notes that SSTI in customizable features like email templates, invoices, and report builders is a frequent high-severity finding and classifies as Injection (A03) in OWASP Top 10 (2021). In engines like Jinja2, Twig, or ERB, SSTI can escalate beyond reading values to achieving remote code execution.
• Separate template from user dataThe core defense is architectural: keep the template fixed and developer-controlled while users supply only data values. Users never provide or modify the template itself, eliminating the ability to inject expressions into the rendering engine.
• Use logic-less templating for user contentFor any user-facing templating feature, employ a logic-less template language that cannot evaluate expressions. This ensures that even if a user's input reaches the template engine, it cannot be executed as code—only substituted as literal data.
• Testing strategy: arithmetic injection probeThe article recommends a quick detection method: drop a simple arithmetic expression into any 'customize your template' field and observe whether it is computed or printed verbatim. If computed, the engine is evaluating user input and SSTI is present.

Bottom line: Server-Side Template Injection occurs when applications allow users to supply template expressions rather than just data, granting attackers access to server-side objects and potentially enabling code execution. The defense is architectural: always keep templates developer-controlled, pass user input only as data, and use logic-less templating for customizable features.