Template string built directly from request data
Part of Security, which counts for 30% of the overall score. When this check fires it deducts 25 points from that category, once per scan, no matter how many places it turns up.
What it detects
render_template_string() or Template() receives request.args/form/values/json/data directly, so the attacker controls the template body itself, not just a value inside it. This is server-side template injection and Jinja2 SSTI payloads routinely achieve full remote code execution.
Why it matters
render_template_string() and Template() compile whatever string they are given as a Jinja2 template, running any {{ }} or {% %} expressions inside it. When that string is request.args, request.form, or similar taken directly, the attacker is not filling in a blank in your template, they are writing the template, and public Jinja2 SSTI payloads escape the sandbox to read files, environment variables, or run shell commands.
How to fix it
Never pass request data as the template argument itself. Use a fixed, developer-authored template string (or a real template file with render_template) and pass the request value only as a variable for the template to reference, for example render_template_string("Hello {{ name }}", name=request.args.get("name")).
The paid report includes a ready-to-paste prompt for your AI coding agent for every check it finds, pointed at the exact findings from your scan. See pricing
Does your repo trip this check?
Paste a GitHub URL or drop a project folder. Scans run in your browser and take seconds.
Scan your repo