Hunt Ssti

Hunt SSTI documents a server-side template injection assessment workflow for explicitly authorized security engagements. It covers template-engine identification, possible rendering surfaces, distinctions between expression evaluation and command-execution impact, and evidence requirements for reporting. Named engines include Jinja2, Twig, Freemarker, ERB, Velocity, Mako, Thymeleaf, and Smarty.

The catalog copy is documentation only. It does not bundle the upstream testing engine, executable helpers, commands, or research assets. A user must locate appropriate tooling and establish the target and permitted scope before any active work. Unsafe template rendering can have serious consequences; that possibility does not authorize testing an arbitrary system.

Use it within a written, authorized bug-bounty or penetration-test engagement when the assigned technique is server-side template injection. Read-only review can help identify which scope facts and evidence are missing before deciding whether an active assessment is permitted.

Before any probing, exploitation, persistence, data extraction, change, or credential access, establish the exact target, written authorization and scope, the proposed commands and their expected effects, and explicit confirmation in the current conversation. Without that confirmation, remain read-only and provide defensive guidance. A sandbox, disposable virtual machine, or controlled lab is preferred.

Inputs include the authorized engagement brief, exact resources, permitted techniques, application context, and observed rendering behavior. Begin with read-only inspection of the scope:

# Read-only first step; confirm scope before anything active.
cat scope.txt  # target list from the authorized engagement brief

Potential surfaces named in the guide include user profile fields, descriptions, search results, email templates, invoice or PDF generation, reflected headers, URL parameters, and authenticated template editors. The evaluated result may appear in outbound email rather than the browser response, so evidence collection must match the actual sink.

Engine syntax, input length constraints, request encoding, record identifiers, and CSRF state can affect interpretation. The document contains both an aggressive execution-first section and a template-editor section that requires fingerprinting first. These are context-dependent instructions to review within the approved assessment plan rather than a universal sequence to run automatically. Previewing and saving templates also have different persistence effects.

Expected outputs are validated observations and a report whose impact matches the evidence. Arithmetic expression evaluation alone does not prove remote command execution. A sandboxed template result should not be labeled critical execution without separate authorized proof. Use a unique marker and validate severity before reporting.

Related documentation covers execution impact, cross-site scripting, server-side request forgery, uploaded document rendering, engine-specific research, triage validation, and report writing. These are adjacent assessment topics, not automatic authorization to expand scope or access credentials.

This guide supports authorized security assessors reviewing SSTI findings and their evidence. It is not a ready-to-run scanner or a substitute for the engagement's permissions, boundaries, and reporting process.