GHSA-m2p3-hwv5-xpqw: Scriban Denial of Service Vulnerability

MODERATE
CVSS 6.5
CWE-770
Published
Advisory Summary

GHSA-m2p3-hwv5-xpqw is a MODERATE (CVSS 6.5) denial of service vulnerability (CWE-770: Allocation of Resources Without Limits or Throttling) affecting Scriban libraries in the NuGet ecosystem. The issue involves denial of service via unbounded cumulative template output bypassing limittostring. Remediation is available by upgrading affected packages to version 7.0.0.

GHSA-m2p3-hwv5-xpqw at a Glance

CVE Identifier N/A
GHSA Identifier GHSA-m2p3-hwv5-xpqw
Severity MODERATE
CVSS v3.1 Base Score 6.5
CWE Classification CWE-770: Allocation of Resources Without Limits or Throttling
Affected Product Scriban
Package Ecosystem NuGet
Published Date
Last Updated

Security Impact

CVSS: 6.5

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required Low (PR:L)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality None (C:N)
Integrity None (I:N)
Availability High (A:H)

How to Fix GHSA-m2p3-hwv5-xpqw

To remediate this vulnerability, upgrade all affected Scriban dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

Scriban fixed: 7.0.0
Upgrade Scriban to 7.0.0
Scriban.Signed fixed: 7.0.0
Upgrade Scriban.Signed to 7.0.0
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for Scriban

How to Check if You Are Affected

To determine whether your application is affected by GHSA-m2p3-hwv5-xpqw, inspect your project dependencies for Scriban:

inspect dependencies for Scriban

Analyze the terminal output to locate any version of Scriban in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 7.0.0), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-770: Allocation of Resources Without Limits or Throttling, where the product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated. In Scriban, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

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

GHSA-m2p3-hwv5-xpqw Affected Scriban Versions

2 component(s)
Fixed Versions:
7.0.0
Product / Package Ecosystem Affected Versions Fixed Version
Scriban
NuGet
< 7.0.0
7.0.0
Scriban.Signed
NuGet
< 7.0.0
7.0.0

References

Frequently Asked Questions

What is GHSA-m2p3-hwv5-xpqw?
GHSA-m2p3-hwv5-xpqw is a security vulnerability in Scriban involving Denial of Service via Unbounded Cumulative Template Output Bypassing LimitToString under CWE-770: Allocation of Resources Without Limits or Throttling.
Which Scriban versions are affected?
Affected versions include releases prior to 7.0.0 across affected packages: Scriban, Scriban.Signed.
What version fixes GHSA-m2p3-hwv5-xpqw?
Upgrading to 7.0.0 (or the latest patched release for your respective branch) resolves the vulnerability.
Is Scriban affected?
Yes, Scriban is affected in releases prior to 7.0.0. Upgrade your dependency to 7.0.0 or later.
Is Scriban.Signed affected?
Yes, Scriban.Signed is affected in releases prior to 7.0.0. Upgrade your dependency to 7.0.0 or later.
What is the CVSS score of GHSA-m2p3-hwv5-xpqw?
GHSA-m2p3-hwv5-xpqw has a CVSS v3.1 base score of 6.5 (MODERATE) with vector string CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H.
What CWE is associated with GHSA-m2p3-hwv5-xpqw?
GHSA-m2p3-hwv5-xpqw is classified under CWE-770: Allocation of Resources Without Limits or Throttling (The product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated.).
How can I check NuGet dependencies for GHSA-m2p3-hwv5-xpqw?
Run the dependency tree command: 'inspect dependencies for Scriban'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-m2p3-hwv5-xpqw",
  "modified" : "2026-07-06T13:09:51Z",
  "published" : "2026-03-24T22:15:43Z",
  "aliases" : [ ],
  "summary" : "Scriban: Denial of Service via Unbounded Cumulative Template Output Bypassing LimitToString",
  "details" : "## Summary\n\nThe `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.\n\n## Details\n\nThe root cause is in `TemplateContext.Helpers.cs`, in the `ObjectToString` method:\n\n```csharp\n// src/Scriban/TemplateContext.Helpers.cs:89-111\npublic virtual string ObjectToString(object value, bool nested = false)\n{\n    if (_objectToStringLevel == 0)\n    {\n        _currentToStringLength = 0;  // <-- resets on every top-level call\n    }\n    try\n    {\n        _objectToStringLevel++;\n        // ...\n        var result = ObjectToStringImpl(value, nested);\n        if (LimitToString > 0 && _objectToStringLevel == 1 && result != null && result.Length >= LimitToString)\n        {\n            return result + \"...\";\n        }\n        return result;\n    }\n    // ...\n}\n```\n\nEach time a template expression is rendered, `TemplateContext.Write(SourceSpan, object)` calls `ObjectToString`:\n\n```csharp\n// src/Scriban/TemplateContext.cs:693-701\npublic virtual TemplateContext Write(SourceSpan span, object textAsObject)\n{\n    if (textAsObject != null)\n    {\n        var text = ObjectToString(textAsObject);  // fresh _currentToStringLength = 0\n        Write(text);\n    }\n    return this;\n}\n```\n\nThe `StringBuilderOutput.Write` method appends unconditionally with no size check:\n\n```csharp\n// src/Scriban/Runtime/StringBuilderOutput.cs:47-50\npublic void Write(string text, int offset, int count)\n{\n    Builder.Append(text, offset, count);  // no cumulative limit\n}\n```\n\n**Execution flow:**\n1. Template creates a string of length 1,048,575 (one byte under the 1MB `LimitToString` default)\n2. A `for` loop iterates up to `LoopLimit` (default 1000) times\n3. Each iteration renders the string via `Write(span, x)` → `ObjectToString(x)`\n4. `ObjectToString` resets `_currentToStringLength = 0` since `_objectToStringLevel == 0`\n5. The string passes the `LimitToString` check (1,048,575 < 1,048,576)\n6. Full string is appended to `StringBuilder` — no cumulative tracking\n7. After 1000 iterations: ~1GB allocated in-memory\n\n## PoC\n\n```csharp\nusing Scriban;\n\n// Uses only default TemplateContext settings (LoopLimit=1000, LimitToString=1048576)\nvar template = Template.Parse(\"{{ x = \\\"\\\" | string.pad_left 1048575 }}{{ for i in 1..1000 }}{{ x }}{{ end }}\");\n// This will allocate ~1GB in the StringBuilder, likely causing OOM\nvar result = template.Render();\n```\n\nEquivalent Scriban template:\n```scriban\n{{ x = \"\" | string.pad_left 1048575 }}{{ for i in 1..1000 }}{{ x }}{{ end }}\n```\n\nEach 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`.\n\n## Impact\n\n- **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\n- **Process-level impact:** OOM kills the entire .NET process, not just the template rendering — affects all concurrent users\n- **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\n- **Low complexity:** The exploit template is trivial — a single line\n\n## Recommended Fix\n\nAdd a cumulative output size counter to `TemplateContext` that tracks total bytes written across all `Write` calls, independent of the per-object `LimitToString`:\n\n```csharp\n// In TemplateContext.cs — add new property and field\nprivate long _totalOutputLength;\n\n/// <summary>\n/// Gets or sets the maximum total output length in characters. Default is 10485760 (10 MB). 0 means no limit.\n/// </summary>\npublic int OutputLimit { get; set; } = 10485760;\n\n// In TemplateContext.Write(string, int, int) — add check before writing\npublic TemplateContext Write(string text, int startIndex, int count)\n{\n    if (text != null)\n    {\n        if (OutputLimit > 0)\n        {\n            _totalOutputLength += count;\n            if (_totalOutputLength > OutputLimit)\n            {\n                throw new ScriptRuntimeException(CurrentSpan, \n                    $\"The output limit of {OutputLimit} characters was reached.\");\n            }\n        }\n        // ... existing indent/write logic\n    }\n    return this;\n}\n```\n\nThis provides defense-in-depth: `LimitToString` caps individual object serialization, while `OutputLimit` caps total template output.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "NuGet",
      "name" : "Scriban"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "7.0.0"
      } ]
    } ]
  }, {
    "package" : {
      "ecosystem" : "NuGet",
      "name" : "Scriban.Signed"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "7.0.0"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/scriban/scriban/security/advisories/GHSA-m2p3-hwv5-xpqw"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/scriban/scriban"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-770" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-03-24T22:15:43Z",
    "nvd_published_at" : null
  }
}