CVE-2026-74784

Scriban before 7.2.0 contains a denial of service vulnerability in the array.insert_at function that allocates unbounded null entries without respecting LoopLimit or LimitToString constraints. Attackers can supply a large index parameter to trigger OutOfMemoryException and crash the host process in under a second.

Scriban before 7.2.0 contains a denial of service vulnerability in the array.insert_at function that allocates unbounded null entries without respecting LoopLimit or LimitToString constraints. Attackers can supply a large index parameter to trigger OutOfMemoryException and crash the host process in under a second.

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…

Scriban before 7.2.0 contains a denial of service vulnerability in the array.insert_at function that allocates unbounded null entries without respecting LoopLimit or LimitToString constraints. Attackers can supply a large index parameter to trigger OutOfMemoryException and crash the host process in under a second.

Scriban before 7.2.0 contains a denial of service vulnerability in the array.insert_at function that allocates unbounded null entries without respecting LoopLimit or LimitToString constraints. Attackers can supply a large index parameter to trigger OutOfMemoryException and crash the host process in under a second.

Scriban before 7.2.0 contains a denial of service vulnerability in the array.insert_at function that allocates unbounded null entries without respecting LoopLimit or LimitToString constraints. Attackers can supply a large index parameter to trigger OutOfMemoryException and crash the host process in under a second.

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…