What it is
Server-Side Template Injection is sneakier than its cousins. SQLi takes you to the database, XSS takes you to the user's browser — SSTI usually takes you straight to a shell on the application server. It happens when developers reach for a template engine's flexibility (let users add a name to the email subject) and let user input cross the line from data to code.
How it happens
Server-side template injection appears when user-controlled text is evaluated by a server template engine instead of being rendered as plain data. In severe cases, that can expose sensitive data or reach server-side execution paths.
What an attacker gets
Most template engines, by design, can call into the host language. That means SSTI typically grades up to remote code execution: arbitrary shell commands, file reads, lateral movement into adjacent services, or just a reverse shell. Even on engines with sandboxes (Handlebars, Mustache without helpers) the attacker can usually exfiltrate context variables that include secrets and session data.
// what fixvibe reports
What FixVibe reports
Runs in active scans of a domain you have verified you own, on Hobby and above. Each finding shows the affected URL or host, its severity and fix steps you can paste into your AI coding tool.
How to fix it
Don't concatenate user input into templates. Pass user data as template variables, never as template source. If you must compose templates dynamically, use a sandboxed engine (Liquid is well-suited; Handlebars without runtime helpers is reasonable) and feed the user data as the data context only. As a second layer, run the rendering in a least-privileged process — separate Linux user, no shell, no network egress beyond what it needs. SSTI is one of the few classes where 'secure by construction' really applies — separate code from data and the entire family of bugs disappears.