CVE-2026-74786

Scriban before 7.0.0 (affected versions <= 6.6.0) contains a denial-of-service vulnerability in which the LimitToString safety limit (default 1MB) can be bypassed because ObjectToString resets the per-call length counter (_currentToStringLength) on every top-level call and StringBuilderOutput enforces no cumulative output-size limit. An attacker who can supply a template can render a near-limit string repeatedly in a loop, allocating approximately 1GB of memory and causing an out-of-memory condition that crashes the host application.

Scriban before 7.0.0 (affected versions <= 6.6.0) contains a denial-of-service vulnerability in which the LimitToString safety limit (default 1MB) can be bypassed because ObjectToString resets the per-call length counter (_currentToStringLength) on every top-level call and StringBuilderOutput enforces no cumulative output-size limit. An attacker who can supply a template can render a near-limit string repeatedly in a loop, allocating approximately 1GB of memory and causing an out-of-memory condition that crashes the host application.

Summary

The LimitToString safety limit (default 1MB since commit b5ac4bf) can be bypassed to allocate approximately 1GB of memory by exploiting the per-call reset of _currentToStringLength in ObjectToString. Each template expression rendered through TemplateContext.Write(SourceSpan, object) triggers a separate top-level ObjectToString call that resets the length counter to zero, and the underlying StringBuilderOutput has no cumulative output size limit. An attacker who can supply a template can cause an out-of-memory condition in the host application.

Details

The root cause is in TemplateContext.Helpers.cs, in the ObjectToString method:

// src/Scriban/TemplateContext.Helpers.cs:89-111
public virtual string ObjectToString(object value, bool nested = false)
{
    if (_objectToStringLevel == 0)
    {
        _currentToStringLength = 0;  // <-- resets on every top-level call
    }
    try
    {
        _objectToStringLevel++;
        // ...
        var result = ObjectToStringImpl(value, nested);
        if (LimitToString > 0 && _objectToStringLevel == 1 && result != null && result.Length >= LimitToString)
        {
            return result + "...";
        }
        return result;
    }
    // ...
}

Each time a template expression is rendered, TemplateContext.Write(SourceSpan, object) calls ObjectToString:

// src/Scriban/TemplateContext.cs:693-701
public virtual TemplateContext Write(SourceSpan span, object textAsObject)
{
    if (textAsObject != null)
    {
        var text = ObjectToString(textAsObject);  // fresh _currentToStringLength = 0
        Write(text);
    }
    return this;
}

The StringBuilderOutput.Write method appends unconditionally with no size check:

// src/Scriban/Runtime/StringBuilderOutput.cs:47-50
public void Write(string text, int offset, int count)
{
    Builder.Append(text, offset, count);  // no cumulative limit
}

Execution flow:

1. Template creates a string of length 1,048,575 (one byte under the 1MB LimitToString default)
2. A for loop iterates up to LoopLimit (default 1000) times
3. Each iteration renders the string via Write(span, x) → ObjectToString(x)
4. ObjectToString resets _currentToStringLength = 0 since _objectToStringLevel == 0
5. The string passes the LimitToString check (1,048,575 < 1,048,576)
6. Full string is appended to StringBuilder — no cumulative tracking
7. After 1000 iterations: ~1GB allocated in-memory

PoC

using Scriban;

// Uses only default TemplateContext settings (LoopLimit=1000, LimitToString=1048576)
var template = Template.Parse("{{ x = \"\" | string.pad_left 1048575 }}{{ for i in 1..1000 }}{{ x }}{{ end }}");
// This will allocate ~1GB in the StringBuilder, likely causing OOM
var result = template.Render();

Equivalent Scriban template:

{{ x = "" | string.pad_left 1048575 }}{{ for i in 1..1000 }}{{ x }}{{ end }}

Each of the 1000 loop iterations outputs a 1,048,575-character string. Each passes the per-call LimitToString check independently. Total output: ~1,000,000,000 characters (~1GB) allocated in the StringBuilder.

Impact

• Denial of Service: An attacker who can supply Scriban templates (common in CMS, email templating, report generation) can crash the host application via out-of-memory
• Process-level impact: OOM kills the entire .NET process, not just the template rendering — affects all concurrent users
• Bypass of safety mechanism: The LimitToString limit was specifically introduced to prevent resource exhaustion, but the per-call reset makes it ineffective against cumulative abuse
• Low complexity: The exploit template is trivial — a single line

Recommended Fix

Add a cumulative output size counter to TemplateContext that tracks total bytes written across all Write calls, independent of the per-object LimitToString:

// In TemplateContext.cs — add new property and field…

Scriban before 7.0.0 (affected versions <= 6.6.0) contains a denial-of-service vulnerability in which the LimitToString safety limit (default 1MB) can be bypassed because ObjectToString resets the per-call length counter (_currentToStringLength) on every top-level call and StringBuilderOutput enforces no cumulative output-size limit. An attacker who can supply a template can render a near-limit string repeatedly in a loop, allocating approximately 1GB of memory and causing an out-of-memory condition that crashes the host application.

Scriban before 7.0.0 (affected versions <= 6.6.0) contains a denial-of-service vulnerability in which the LimitToString safety limit (default 1MB) can be bypassed because ObjectToString resets the per-call length counter (_currentToStringLength) on every top-level call and StringBuilderOutput enforces no cumulative output-size limit. An attacker who can supply a template can render a near-limit string repeatedly in a loop, allocating approximately 1GB of memory and causing an out-of-memory condition that crashes the host application.

Scriban before 7.0.0 (affected versions <= 6.6.0) contains a denial-of-service vulnerability in which the LimitToString safety limit (default 1MB) can be bypassed because ObjectToString resets the per-call length counter (_currentToStringLength) on every top-level call and StringBuilderOutput enforces no cumulative output-size limit. An attacker who can supply a template can render a near-limit string repeatedly in a loop, allocating approximately 1GB of memory and causing an out-of-memory condition that crashes the host application.

Summary

The LimitToString safety limit (default 1MB since commit b5ac4bf) can be bypassed to allocate approximately 1GB of memory by exploiting the per-call reset of _currentToStringLength in ObjectToString. Each template expression rendered through TemplateContext.Write(SourceSpan, object) triggers a separate top-level ObjectToString call that resets the length counter to zero, and the underlying StringBuilderOutput has no cumulative output size limit. An attacker who can supply a template can cause an out-of-memory condition in the host application.

Details

The root cause is in TemplateContext.Helpers.cs, in the ObjectToString method:

// src/Scriban/TemplateContext.Helpers.cs:89-111
public virtual string ObjectToString(object value, bool nested = false)
{
    if (_objectToStringLevel == 0)
    {
        _currentToStringLength = 0;  // <-- resets on every top-level call
    }
    try
    {
        _objectToStringLevel++;
        // ...
        var result = ObjectToStringImpl(value, nested);
        if (LimitToString > 0 && _objectToStringLevel == 1 && result != null && result.Length >= LimitToString)
        {
            return result + "...";
        }
        return result;
    }
    // ...
}

Each time a template expression is rendered, TemplateContext.Write(SourceSpan, object) calls ObjectToString:

// src/Scriban/TemplateContext.cs:693-701
public virtual TemplateContext Write(SourceSpan span, object textAsObject)
{
    if (textAsObject != null)
    {
        var text = ObjectToString(textAsObject);  // fresh _currentToStringLength = 0
        Write(text);
    }
    return this;
}

The StringBuilderOutput.Write method appends unconditionally with no size check:

// src/Scriban/Runtime/StringBuilderOutput.cs:47-50
public void Write(string text, int offset, int count)
{
    Builder.Append(text, offset, count);  // no cumulative limit
}

Execution flow:

1. Template creates a string of length 1,048,575 (one byte under the 1MB LimitToString default)
2. A for loop iterates up to LoopLimit (default 1000) times
3. Each iteration renders the string via Write(span, x) → ObjectToString(x)
4. ObjectToString resets _currentToStringLength = 0 since _objectToStringLevel == 0
5. The string passes the LimitToString check (1,048,575 < 1,048,576)
6. Full string is appended to StringBuilder — no cumulative tracking
7. After 1000 iterations: ~1GB allocated in-memory

PoC

using Scriban;

// Uses only default TemplateContext settings (LoopLimit=1000, LimitToString=1048576)
var template = Template.Parse("{{ x = \"\" | string.pad_left 1048575 }}{{ for i in 1..1000 }}{{ x }}{{ end }}");
// This will allocate ~1GB in the StringBuilder, likely causing OOM
var result = template.Render();

Equivalent Scriban template:

{{ x = "" | string.pad_left 1048575 }}{{ for i in 1..1000 }}{{ x }}{{ end }}

Each of the 1000 loop iterations outputs a 1,048,575-character string. Each passes the per-call LimitToString check independently. Total output: ~1,000,000,000 characters (~1GB) allocated in the StringBuilder.

Impact

• Denial of Service: An attacker who can supply Scriban templates (common in CMS, email templating, report generation) can crash the host application via out-of-memory
• Process-level impact: OOM kills the entire .NET process, not just the template rendering — affects all concurrent users
• Bypass of safety mechanism: The LimitToString limit was specifically introduced to prevent resource exhaustion, but the per-call reset makes it ineffective against cumulative abuse
• Low complexity: The exploit template is trivial — a single line

Recommended Fix

Add a cumulative output size counter to TemplateContext that tracks total bytes written across all Write calls, independent of the per-object LimitToString:

// In TemplateContext.cs — add new property and field…