Scriban: Denial of Service via Unbounded Cumulative Template Output Bypassing LimitToString
## Summary The `LimitToString` safety limit (default 1MB since commit `b5ac4bf`) can be bypassed to allocate approximately 1GB of memory by exploiting the per-call reset of `_currentToStringLength` in `ObjectToString`. Each template expression rendered through `TemplateContext.Write(SourceSpan, object)` triggers a separate top-level `ObjectToString` call that resets the length counter to zero, and the underlying `StringBuilderOutput` has no cumulative output size limit. An attacker who can supply a template can cause an out-of-memory condition in the host application. ## Details The root cause is in `TemplateContext.Helpers.cs`, in the `ObjectToString` method: ```csharp // src/Scriban/TemplateContext.Helpers.cs:89-111 public virtual string ObjectToString(object value, bool nested = false) { if (_objectToStringLevel == 0) { _currentToStringLength = 0; // <-- resets on every top-level call } try { _objectToStringLevel++; // ... var result = ObjectToStringImpl(value, nested); if (LimitToString > 0 && _objectToStringLevel == 1 && result != null && result.Length >= LimitToString) { return result + "..."; } return result; } // ... } ``` Each time a template expression is rendered, `TemplateContext.Write(SourceSpan, object)` calls `ObjectToString`: ```csharp // src/Scriban/TemplateContext.cs:693-701 public virtual TemplateContext Write(SourceSpan span, object textAsObject) { if (textAsObject != null) { var text = ObjectToString(textAsObject); // fresh _currentToStringLength = 0 Write(text); } return this; } ``` The `StringBuilderOutput.Write` method appends unconditionally with no size check: ```csharp // src/Scriban/Runtime/StringBuilderOutput.cs:47-50 public void Write(string text, int offset, int count) { Builder.Append(text, offset, count); // no cumulative limit } ``` **Execution flow:** 1. Template creates a string of length 1,048,575 (one byte under the 1MB `LimitToString` default) 2. A `for` loop iterates up to `LoopLimit` (default 1000) times 3. Each iteration renders the string via `Write(span, x)` → `ObjectToString(x)` 4. `ObjectToString` resets `_currentToStringLength = 0` since `_objectToStringLevel == 0` 5. The string passes the `LimitToString` check (1,048,575 < 1,048,576) 6. Full string is appended to `StringBuilder` — no cumulative tracking 7. After 1000 iterations: ~1GB allocated in-memory ## PoC ```csharp using Scriban; // Uses only default TemplateContext settings (LoopLimit=1000, LimitToString=1048576) var template = Template.Parse("{{ x = \"\" | string.pad_left 1048575 }}{{ for i in 1..1000 }}{{ x }}{{ end }}"); // This will allocate ~1GB in the StringBuilder, likely causing OOM var result = template.Render(); ``` Equivalent Scriban template: ```scriban {{ x = "" | string.pad_left 1048575 }}{{ for i in 1..1000 }}{{ x }}{{ end }} ``` Each of the 1000 loop iterations outputs a 1,048,575-character string. Each passes the per-call `LimitToString` check independently. Total output: ~1,000,000,000 characters (~1GB) allocated in the `StringBuilder`. ## Impact - **Denial of Service:** An attacker who can supply Scriban templates (common in CMS, email templating, report generation) can crash the host application via out-of-memory - **Process-level impact:** OOM kills the entire .NET process, not just the template rendering — affects all concurrent users - **Bypass of safety mechanism:** The `LimitToString` limit was specifically introduced to prevent resource exhaustion, but the per-call reset makes it ineffective against cumulative abuse - **Low complexity:** The exploit template is trivial — a single line ## Recommended Fix Add a cumulative output size counter to `TemplateContext` that tracks total bytes written across all `Write` calls, independent of the per-object `LimitToString`: ```csharp // In TemplateContext.cs — add new property and field private long _totalOutputLength; /// <summary> /// Gets or sets the maximum total output length in characters. Default is 10485760 (10 MB). 0 means no limit. /// </summary> public int OutputLimit { get; set; } = 10485760; // In TemplateContext.Write(string, int, int) — add check before writing public TemplateContext Write(string text, int startIndex, int count) { if (text != null) { if (OutputLimit > 0) { _totalOutputLength += count; if (_totalOutputLength > OutputLimit) { throw new ScriptRuntimeException(CurrentSpan, $"The output limit of {OutputLimit} characters was reached."); } } // ... existing indent/write logic } return this; } ``` This provides defense-in-depth: `LimitToString` caps individual object serialization, while `OutputLimit` caps total template output.
AI Analysis
Technical Summary
The vulnerability in Scriban (versions <7.0.0) involves bypassing the LimitToString safety limit (default 1MB) by exploiting the per-call reset of the _currentToStringLength counter in the ObjectToString method. Each template expression rendered calls ObjectToString, resetting the counter, allowing repeated large strings to be appended cumulatively without a total output size limit. This results in approximately 1GB of memory allocation in the StringBuilderOutput, causing out-of-memory conditions and denial of service in the host .NET process. The root cause is the lack of a cumulative output size check in TemplateContext.Write and StringBuilderOutput.Write. A recommended fix is to add a cumulative output size counter with a configurable limit to prevent excessive memory usage.
Potential Impact
An attacker able to supply Scriban templates can cause a denial of service by triggering out-of-memory conditions in the host application. This affects the entire .NET process, potentially impacting all concurrent users. The existing LimitToString safety mechanism is ineffective against this cumulative output abuse due to its per-call reset behavior. The exploit is low complexity and can be executed with a simple crafted template, making it a practical risk in environments that accept untrusted templates.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The recommended fix involves adding a cumulative output size counter in TemplateContext to track total characters written across all Write calls and enforce an output limit (e.g., 10MB). Until an official fix is available, consider restricting or sanitizing template input to prevent untrusted templates from causing excessive output. Monitor vendor advisories for updates and apply official patches once released.
Scriban: Denial of Service via Unbounded Cumulative Template Output Bypassing LimitToString
Description
## Summary The `LimitToString` safety limit (default 1MB since commit `b5ac4bf`) can be bypassed to allocate approximately 1GB of memory by exploiting the per-call reset of `_currentToStringLength` in `ObjectToString`. Each template expression rendered through `TemplateContext.Write(SourceSpan, object)` triggers a separate top-level `ObjectToString` call that resets the length counter to zero, and the underlying `StringBuilderOutput` has no cumulative output size limit. An attacker who can supply a template can cause an out-of-memory condition in the host application. ## Details The root cause is in `TemplateContext.Helpers.cs`, in the `ObjectToString` method: ```csharp // src/Scriban/TemplateContext.Helpers.cs:89-111 public virtual string ObjectToString(object value, bool nested = false) { if (_objectToStringLevel == 0) { _currentToStringLength = 0; // <-- resets on every top-level call } try { _objectToStringLevel++; // ... var result = ObjectToStringImpl(value, nested); if (LimitToString > 0 && _objectToStringLevel == 1 && result != null && result.Length >= LimitToString) { return result + "..."; } return result; } // ... } ``` Each time a template expression is rendered, `TemplateContext.Write(SourceSpan, object)` calls `ObjectToString`: ```csharp // src/Scriban/TemplateContext.cs:693-701 public virtual TemplateContext Write(SourceSpan span, object textAsObject) { if (textAsObject != null) { var text = ObjectToString(textAsObject); // fresh _currentToStringLength = 0 Write(text); } return this; } ``` The `StringBuilderOutput.Write` method appends unconditionally with no size check: ```csharp // src/Scriban/Runtime/StringBuilderOutput.cs:47-50 public void Write(string text, int offset, int count) { Builder.Append(text, offset, count); // no cumulative limit } ``` **Execution flow:** 1. Template creates a string of length 1,048,575 (one byte under the 1MB `LimitToString` default) 2. A `for` loop iterates up to `LoopLimit` (default 1000) times 3. Each iteration renders the string via `Write(span, x)` → `ObjectToString(x)` 4. `ObjectToString` resets `_currentToStringLength = 0` since `_objectToStringLevel == 0` 5. The string passes the `LimitToString` check (1,048,575 < 1,048,576) 6. Full string is appended to `StringBuilder` — no cumulative tracking 7. After 1000 iterations: ~1GB allocated in-memory ## PoC ```csharp using Scriban; // Uses only default TemplateContext settings (LoopLimit=1000, LimitToString=1048576) var template = Template.Parse("{{ x = \"\" | string.pad_left 1048575 }}{{ for i in 1..1000 }}{{ x }}{{ end }}"); // This will allocate ~1GB in the StringBuilder, likely causing OOM var result = template.Render(); ``` Equivalent Scriban template: ```scriban {{ x = "" | string.pad_left 1048575 }}{{ for i in 1..1000 }}{{ x }}{{ end }} ``` Each of the 1000 loop iterations outputs a 1,048,575-character string. Each passes the per-call `LimitToString` check independently. Total output: ~1,000,000,000 characters (~1GB) allocated in the `StringBuilder`. ## Impact - **Denial of Service:** An attacker who can supply Scriban templates (common in CMS, email templating, report generation) can crash the host application via out-of-memory - **Process-level impact:** OOM kills the entire .NET process, not just the template rendering — affects all concurrent users - **Bypass of safety mechanism:** The `LimitToString` limit was specifically introduced to prevent resource exhaustion, but the per-call reset makes it ineffective against cumulative abuse - **Low complexity:** The exploit template is trivial — a single line ## Recommended Fix Add a cumulative output size counter to `TemplateContext` that tracks total bytes written across all `Write` calls, independent of the per-object `LimitToString`: ```csharp // In TemplateContext.cs — add new property and field private long _totalOutputLength; /// <summary> /// Gets or sets the maximum total output length in characters. Default is 10485760 (10 MB). 0 means no limit. /// </summary> public int OutputLimit { get; set; } = 10485760; // In TemplateContext.Write(string, int, int) — add check before writing public TemplateContext Write(string text, int startIndex, int count) { if (text != null) { if (OutputLimit > 0) { _totalOutputLength += count; if (_totalOutputLength > OutputLimit) { throw new ScriptRuntimeException(CurrentSpan, $"The output limit of {OutputLimit} characters was reached."); } } // ... existing indent/write logic } return this; } ``` This provides defense-in-depth: `LimitToString` caps individual object serialization, while `OutputLimit` caps total template output.
CVSS v3.1
Score 6.5medium
Affected software
Run on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The vulnerability in Scriban (versions <7.0.0) involves bypassing the LimitToString safety limit (default 1MB) by exploiting the per-call reset of the _currentToStringLength counter in the ObjectToString method. Each template expression rendered calls ObjectToString, resetting the counter, allowing repeated large strings to be appended cumulatively without a total output size limit. This results in approximately 1GB of memory allocation in the StringBuilderOutput, causing out-of-memory conditions and denial of service in the host .NET process. The root cause is the lack of a cumulative output size check in TemplateContext.Write and StringBuilderOutput.Write. A recommended fix is to add a cumulative output size counter with a configurable limit to prevent excessive memory usage.
Potential Impact
An attacker able to supply Scriban templates can cause a denial of service by triggering out-of-memory conditions in the host application. This affects the entire .NET process, potentially impacting all concurrent users. The existing LimitToString safety mechanism is ineffective against this cumulative output abuse due to its per-call reset behavior. The exploit is low complexity and can be executed with a simple crafted template, making it a practical risk in environments that accept untrusted templates.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The recommended fix involves adding a cumulative output size counter in TemplateContext to track total characters written across all Write calls and enforce an output limit (e.g., 10MB). Until an official fix is available, consider restricting or sanitizing template input to prevent untrusted templates from causing excessive output. Monitor vendor advisories for updates and apply official patches once released.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-m2p3-hwv5-xpqw
- Osv Schema Version
- 1.4.0
- Aliases
- []
- Ecosystems
- ["NuGet"]
- Database Specific Severity
- MODERATE
- Cvss Version
- 3.1
Threat ID: 6a4c346027e9c7971960089e
Added to database: 07/06/2026, 23:04:00 UTC
Last enriched: 07/06/2026, 23:37:12 UTC
Last updated: 07/31/2026, 12:27:30 UTC
Views: 20
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
External Links
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.