SSTI Testing
Core Posture
Treat SSTI as server-side expression evaluation. Identify the template engine, where user input enters the template, and whether execution reaches objects, filesystem, commands, or secrets.
Priority Patterns
- Email templates, CMS pages, signup/name fields, preview systems, and custom content blocks.
- Reflected and stored template evaluation in admin or backend contexts.
- Path traversal plus template selection or include.
- Template engine escapes that allow sandbox escape or command execution.
- Security tooling queries and code scanning patterns for SSTI.
Assessment Loop
- Find rendered inputs: names, template bodies, CMS fields, email content, preview parameters, imports, and themes.
- Use harmless arithmetic or marker expressions to identify evaluation.
- Fingerprint engine carefully by syntax and error behavior.
- Test context and sandbox boundaries with non-destructive introspection.
- Confirm impact as server-side data access, file read, command execution, or privileged rendering.
High-Value Cues
| Cue |
Ask |
| Template preview |
Is user-controlled template content rendered server-side? |
| Email/CMS |
Can low-role input execute in a trusted render context? |
| Engine error |
Does syntax error reveal engine or object model? |
| Sandbox |
Can object traversal escape restrictions? |
| Stored render |
Does payload execute later for admin or users? |
Variant Playbook
- Try engine-specific harmless markers for Jinja, Twig, Smarty, ERB, Ruby, Java, and JavaScript engines.
- Test reflected and stored contexts separately.
- Compare plain text, HTML, Markdown, email, PDF, and CMS preview renderers.
- When the client or endpoint supports Base64 or another wrapped representation, encode equivalent harmless marker expressions and trace whether decoding happens before template rendering. Do not infer SSTI from a filter status change.
- Look for include/template-name/path controls and theme upload paths.
- Escalate only after confirming engine and context.
Confirmation Discipline
Strong evidence shows server-side expression evaluation and meaningful access beyond intended interpolation. Rule out client-side template execution and literal echo.
References
Read references/advanced-methodology.md only when the task needs deeper engine fingerprinting, application-decoded input checks, stored/render context review, sandbox escape analysis, confirmation, or remediation guidance.
1---2name: ssti3description: Advanced server-side template injection testing methodology for bug bounty and application security work. Use when testing or reviewing template rendering, email templates, CMS templates, preview/render APIs, Smarty/Jinja/Twig/ERB/Ruby/Python template engines, path traversal plus SSTI, SSTI-to-RCE, reflected or stored template execution, user-controlled template variables, and workflows where attacker input is evaluated by a server-side template engine.4---56# SSTI Testing78## Core Posture910Treat SSTI as server-side expression evaluation. Identify the template engine, where user input enters the template, and whether execution reaches objects, filesystem, commands, or secrets.1112## Priority Patterns1314- Email templates, CMS pages, signup/name fields, preview systems, and custom content blocks.15- Reflected and stored template evaluation in admin or backend contexts.16- Path traversal plus template selection or include.17- Template engine escapes that allow sandbox escape or command execution.18- Security tooling queries and code scanning patterns for SSTI.1920## Assessment Loop21221. Find rendered inputs: names, template bodies, CMS fields, email content, preview parameters, imports, and themes.232. Use harmless arithmetic or marker expressions to identify evaluation.243. Fingerprint engine carefully by syntax and error behavior.254. Test context and sandbox boundaries with non-destructive introspection.265. Confirm impact as server-side data access, file read, command execution, or privileged rendering.2728## High-Value Cues2930| Cue | Ask |31| --- | --- |32| Template preview | Is user-controlled template content rendered server-side? |33| Email/CMS | Can low-role input execute in a trusted render context? |34| Engine error | Does syntax error reveal engine or object model? |35| Sandbox | Can object traversal escape restrictions? |36| Stored render | Does payload execute later for admin or users? |3738## Variant Playbook3940- Try engine-specific harmless markers for Jinja, Twig, Smarty, ERB, Ruby, Java, and JavaScript engines.41- Test reflected and stored contexts separately.42- Compare plain text, HTML, Markdown, email, PDF, and CMS preview renderers.43- When the client or endpoint supports Base64 or another wrapped representation, encode equivalent harmless marker expressions and trace whether decoding happens before template rendering. Do not infer SSTI from a filter status change.44- Look for include/template-name/path controls and theme upload paths.45- Escalate only after confirming engine and context.4647## Confirmation Discipline4849Strong evidence shows server-side expression evaluation and meaningful access beyond intended interpolation. Rule out client-side template execution and literal echo.5051## References5253Read `references/advanced-methodology.md` only when the task needs deeper engine fingerprinting, application-decoded input checks, stored/render context review, sandbox escape analysis, confirmation, or remediation guidance.
yafet-dev