FIX Mitigate Jinja2 Server-Side Template Injection (SSTI) vulnerability

[romanlutz]

Problem

PyRIT's template rendering in seed.py used an unsandboxed Jinja2 Environment, and 21 of 30 remote dataset loaders passed fetched data directly into SeedPrompt(value=...) without escaping. Since
SeedPrompt.__post_init__ renders self.value as a Jinja2 template, a poisoned remote dataset could achieve Python object traversal (e.g. "".__class__.__mro__[1].__subclasses__()) — confirmed via
proof-of-concept.

The 9 loaders that did wrap values in {% raw %}...{% endraw %} were also bypassable via {% endraw %} injection in the payload.

Changes

Layer 1 — Sandbox the rendering engine (seed.py)

• Replace Environment() / Template() with SandboxedEnvironment from jinja2.sandbox
• Blocks __class__, __mro__, __subclasses__() and other unsafe attribute access
• All 40+ call sites across converters, scorers, and attack executors are covered since they all funnel through render_template_value / render_template_value_silent

Layer 2 — Safe-by-default SeedPrompt

• Add is_jinja_template field to Seed (default False)
• When False, __post_init__ auto-wraps the value in {% raw %}...{% endraw %} before rendering
• Seed.from_yaml_file and SeedDataset.from_yaml_file set is_jinja_template=True for trusted local YAML templates
• Dataset loaders no longer need explicit escaping — SeedPrompt(value=remote_data) is safe by default
• Call sites that construct SeedPrompt with Jinja2 template syntax explicitly opt in with is_jinja_template=True

Layer 3 — Eliminate supply chain risk in many-shot jailbreak

• Vendor the many-shot jailbreaking dataset (400 examples, ~664KB) locally as pyrit/datasets/jailbreak/many_shot_examples.json. The dataset was provided by @KutalVolkan originally. For simplicity, we're
  including it here as well.
• Replace runtime requests.get() from GitHub URL with local json.load()
• Rename fetch_many_shot_jailbreaking_dataset → load_many_shot_jailbreaking_dataset
• Deprecate fetch_many_shot_jailbreaking_dataset (removal in 0.14.0)

Regression tests

• test_untrusted_seed_prompt_auto_escapes_template_syntax — verifies default auto-escaping
• test_render_template_value_blocks_ssti_via_endraw_injection — verifies sandbox blocks {% endraw %} escape attack on trusted templates
• test_render_template_value_silent_blocks_ssti_via_endraw_injection — same for the silent rendering path
• test_seed_group_untrusted_auto_escapes — verifies SeedGroup propagates untrusted default

Testing

• 2760+ unit tests pass (models, datasets, converters, executors, scorers, scenarios)
• All pre-commit hooks pass (ruff, mypy, etc.)
• Manual verification: SSTI payload returns SecurityError with sandbox, executes without
• All 42 pliny jailbreak templates + many-shot template verified to render correctly

[cherry-bisht]

Hey genuine question. I reported this exact vuln to MSRC on April 5 (VULN-181209 / Case 112392) unsandboxed Jinja2 in SeedPrompt.post_init
allowing RCE via malicious remote datasets. This PR was opened April 8, one month later. MSRC marked my report as a duplicate of an earlier submission but hasn't confirmed the date of that report. Was this fix triggered by an external report, or discovered internally? Just trying to understand the timeline.

[romanlutz]

Hi @cherry-bisht ! Thanks for reaching out. I can check with MSRC. Mind sending me whatever you submitted to MSRC and their response to romanlutz@microsoft.com? I can respond here or via email with whatever I find.

Regardless of what we find here, thank you for submitting your finding to MSRC and trying to keep people safe!