CVE-2026-73062

Scriban versions 3.0.0 through 7.2.0 contain a denial of service vulnerability in the array multiplication operator that allocates memory without enforcing LoopLimit or overflow-safe arithmetic checks. Attackers can supply a large integer multiplier in a template to force multi-gigabyte memory allocations, causing resource exhaustion and availability degradation.

Scriban versions 3.0.0 through 7.2.0 contain a denial of service vulnerability in the array multiplication operator that allocates memory without enforcing LoopLimit or overflow-safe arithmetic checks. Attackers can supply a large integer multiplier in a template to force multi-gigabyte memory allocations, causing resource exhaustion and availability degradation.

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…

Scriban versions 3.0.0 through 7.2.0 contain a denial of service vulnerability in the array multiplication operator that allocates memory without enforcing LoopLimit or overflow-safe arithmetic checks. Attackers can supply a large integer multiplier in a template to force multi-gigabyte memory allocations, causing resource exhaustion and availability degradation.

Scriban versions 3.0.0 through 7.2.0 contain a denial of service vulnerability in the array multiplication operator that allocates memory without enforcing LoopLimit or overflow-safe arithmetic checks. Attackers can supply a large integer multiplier in a template to force multi-gigabyte memory allocations, causing resource exhaustion and availability degradation.

Scriban versions 3.0.0 through 7.2.0 contain a denial of service vulnerability in the array multiplication operator that allocates memory without enforcing LoopLimit or overflow-safe arithmetic checks. Attackers can supply a large integer multiplier in a template to force multi-gigabyte memory allocations, causing resource exhaustion and availability degradation.

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…