GHSA-9395-2g46-rj3f

Five independent defects in djust's template auto-escaping cause attacker-controlled input to be rendered as live markup where Django escapes it. All four are present in shipped 1.1.0 and are fixed in 1.1.1. They share one shape: **a filter or grant that escapes nothing itself and relies on the render-time auto-escape, which something downstream then removes.** They are grouped into a single advisory because the mitigation is identical — upgrade to 1.1.1 — and because no single one of them is meaningfully actionable in isolation. ## 1. `linenumbers` never escaped its input (#2291) ``` {{ p|linenumbers|safe }} with p = '<img src=x onerror=alert(1)>' djust '1. <img src=x onerror=alert(1)>' <- executes django '1. &lt;img src=x onerror=alert(1)&gt;' ``` The filter deferred all escaping to render time; a trailing `|safe` suppressed exactly that. The exposure is wider than the `|safe` form: **any downstream filter that reads the output as markup is affected**, including `{{ p|linenumbers|truncatechars_html:"5" }}`, which contains no `|safe` at all. ## 2. `escape` was a no-op (#2281) ``` {{ p|escape|safe }} djust '<img src=x onerror=alert(1)>' <- executes django '&amp;lt;img src=x onerror=alert(1)&amp;gt;' ``` Django's `escape` is eager (`conditional_escape`, returning `SafeString`). djust's returned its input unchanged and let the render site escape it — indistinguishable for `{{ p|escape }}` alone, wrong for every chain. The security cell is `{{ p|escape|safe }}`: an idiom that reads as "escape it, then it is safe to emit" — which is what Django's semantics make true — was a bare `|safe` on attacker input. A sweep of every length-2 and length-3 chain containing `escape` found **104** live-markup cells. ## 3. `unordered_list` / `safeseq` handed a string back under a safe grant (#2274) Both carry an unconditional "emit without escaping" grant, earned because they escape every item they emit. Given a **string** rather than a sequence t