Stop compiling user-controlled prompts as Jinja2 template source
fix: stop compiling user-controlled prompts as Jinja2 template source (#1004)
Stop compiling user-controlled prompts as Jinja2 template source1b7202-fix-stop-compiling-user-controlled-prompts-as-jinja2-cve-2026-33587fixstop compiling user controlled prompts jinja2
Committed by kwp3
commit message
fix: stop compiling user-controlled prompts as Jinja2 template source (#1004)
transformation.prompt and the generic pattern-chain's prompt were
passed to Prompter(template_text=...), compiling attacker-influenced
text directly as Jinja2 template source. ai-prompter's sandboxed
environment blocks the classic __globals__/__subclasses__ RCE
gadgets, but not an unbounded {% for %} loop - a trivial DoS for any
authenticated user, and one instance of the same "user text becomes
template source" pattern behind a previously-disclosed critical CVE
(GHSA-f35w-wx37-26q7), whose fix only added sandboxing without
removing the pattern itself.
Render through fixed, developer-authored templates instead, with the
user's text passed in as a plain variable. Verified byte-identical
output for legitimate prompts and confirmed the same payload that
used to be a DoS vector now renders as inert text in under a
millisecond.Editor assessment
This commit patches CVE-2026-33587. The subject is precise: stop compiling user-controlled prompts as Jinja2 template source, and no scope is needed here. The body explains the mechanism in depth, showing that transformation prompts flowed into Prompter as template_text and that sandboxing blocked the classic RCE gadgets yet not an unbounded for loop, a trivial denial of service. It also names the earlier advisory whose fix only sandboxed without removing the pattern. The remediation, fixed developer-authored templates with user text passed as a variable, is paired with verification of byte-identical output and a payload rendering as inert text. Exemplary.