How to use the Offensive SSTI Testing Methodology agent skill

What the skill makes the agent do

SKILL.md is a methodology document. Once the skill is loaded, the agent follows a structured workflow: map the injection surfaces (URL parameters, POST bodies, JSON values, path segments, headers and cookies), send polyglot and arithmetic probes, fingerprint which template engine is in use, confirm the evaluation happens on the server rather than in the browser, and then work through information disclosure and code execution chains.

The file covers engines including Jinja2, Twig, Freemarker, Velocity, Pebble, Smarty, Mako, Handlebars, ERB, Thymeleaf, EJS and Pug. It includes decision-tree probes, a table of error signatures that map to each engine, blind detection methods (time-based and out-of-band DNS), and per-engine RCE and file-read examples. It also asks the agent to produce a non-destructive proof of concept with a unique marker and to capture the full request and response chain.

Install the offensive-ssti skill

Download the ZIP for the skill from this page and unzip it. The skill is a folder containing SKILL.md. Put that folder in one of these locations:

Personal install: unzip into ~/.claude/skills/ so it is available in all of your projects.

Project install: unzip into the .claude/skills/ folder inside a specific project so it applies only there.

Claude apps: open Settings, go to Capabilities, then Skills, and upload the skill there.

• Personal: ~/.claude/skills/
• Project: .claude/skills/ inside your project folder
• Claude apps: Settings → Capabilities → Skills

Trigger the skill with natural requests

You do not need a special command. The skill's description says it applies when testing template rendering endpoints or exploiting template injection for code execution, so describe your task in those terms. Include the authorization context, because the skill is intended only for systems you are permitted to test.

Good requests name the target, the scope and the goal. For example: "I have written permission to test staging.example.com. Check whether the search page renders my input through a template engine and identify which engine it is." Another: "Walk through SSTI testing on the profile endpoint, starting with polyglot probes and engine fingerprinting, and stop before code execution so I can review the findings."

Examples of what the agent can do with it

The skill gives the agent concrete material to work from. Typical uses are below. Each one assumes an authorized target.

• Fingerprint a template engine: send {{7*7}} and {{7*'7'}} and use the result to narrow the engine, such as Jinja2 versus Twig.
• Read an error message and match it to an engine using the signature table, for example a jinja2.exceptions.UndefinedError.
• Plan blind detection with a time-based probe or an out-of-band DNS payload when output is not reflected.
• Explain to a student how an SSTI chain moves from information disclosure to code execution in a given engine.
• Draft a finding write-up that records the request, the response and a harmless marker.

What you need before you start

The skill itself is text. The source lists these requirements for running the work it describes:

You need an authorized target and written permission to test it. This is the most important requirement.

Optional: Burp Collaborator or interactsh for out-of-band detection.

The skill refers to tplmap by name in its description. tplmap is not included in the files, so you must obtain it separately if you want to use it.

• Authorized target and written permission to test it
• Optional: Burp Collaborator or interactsh for out-of-band detection
• tplmap, referenced by name but not included in the ZIP

Safety notes on scripts and network access

The skill does not run scripts and does not use the network by itself. It is a set of instructions. The payloads it describes are active attacks, though. They can cause code execution on the target, read files and disclose secrets. Use them only against systems you own or have written permission to test, and stay inside the program's scope.

Keep tests non-destructive. The skill recommends a unique marker in proof-of-concept output rather than damaging actions, and it lists file write examples that you should not run against live systems without explicit approval.

• The skill runs no scripts and uses no network access on its own.
• Payloads are real attacks: confirm written authorization first.
• Prefer harmless markers and read-only checks in proof-of-concept work.