GHSA-GRR9-747V-XVCP: Uncontrolled Recursion in Scriban Templates Leads to Denial of Service

Scriban is a fast, powerful text templating engine for .NET applications, frequently used for dynamic content generation, email rendering, and code generation. GHSA-GRR9-747V-XVCP identifies a high-severity vulnerability within the engine's core processing logic that allows for unauthenticated denial-of-service (DoS) attacks.

The vulnerability is classified as Uncontrolled Recursion (CWE-674) and Uncontrolled Resource Consumption (CWE-400). It manifests in two distinct phases of the engine's lifecycle: the parsing of the template structure and the rendering of the provided data model. In both cases, the engine fails to enforce bounds on the depth of the operations.

Because the underlying platform is .NET, exhausting the call stack results in a StackOverflowException. Unlike standard exceptions, a stack overflow in modern .NET environments is unrecoverable and immediately terminates the process, making this an effective and highly disruptive attack vector against applications relying on Scriban.

The root cause of this vulnerability lies in the "unlimited by default" configuration design of the Scriban engine. The engine exposes limits for parsing and rendering, but prior to the patch, these bounds were either disabled or absent by default, shifting the burden of safety entirely onto the implementing developer.

During the rendering phase, the TemplateContext object is responsible for managing the state and traversal of the data model. The property ObjectRecursionLimit was historically initialized to 0, which the engine interpreted as an instruction to perform boundless recursion. If the object graph contains a circular reference, the engine traverses it infinitely until thread stack space is entirely consumed.

During the parsing phase, the abstract syntax tree (AST) generation is governed by the ParserOptions class. The ExpressionDepthLimit property was set to null by default. This permitted the parser to accept and process templates containing extreme levels of syntactic nesting, such as thousands of nested parenthetical expressions, leading to call stack exhaustion before the rendering phase even begins.

The remediation introduced in commit a6fe6074199e5c04f4d29dc8d8e652b24d33e3e4 addresses the vulnerability by enforcing safe, finite default limits across both affected code paths. The fix fundamentally alters the default state of the engine to prioritize resilience over unbounded processing.

// Vulnerable State (Conceptual)
public class TemplateContext {
    public int ObjectRecursionLimit { get; set; } = 0; // 0 = Unlimited
}
 
public class ParserOptions {
    public int? ExpressionDepthLimit { get; set; } = null; // null = Unlimited
}

The patched version establishes hardcoded default limits. The ObjectRecursionLimit is now defaulted to 20, ensuring that rendering traversal will abort safely if an object graph is exceptionally deep or circular. Similarly, the ExpressionDepthLimit is defaulted to 250, preventing AST parsing from spiraling out of control.

// Patched State (Conceptual)
public class TemplateContext {
    public int ObjectRecursionLimit { get; set; } = 20;
}
 
public class ParserOptions {
    public int? ExpressionDepthLimit { get; set; } = 250;
}

Crucially, when these new limits are exceeded, the engine explicitly halts processing and throws a ScriptRuntimeException. This is a standard managed exception that can be caught by the host application's error handling logic, preventing the fatal process crash.

Exploitation requires no specialized tooling and relies solely on the ability to provide input that the target application processes using the Scriban engine. The attack is highly deterministic and consistently results in a denial-of-service condition.

The parsing vector involves injecting a maliciously crafted template string. An attacker can construct a payload containing hundreds or thousands of nested structures. A simple example involves deeply nested parentheses: {{ (((...))) }}. When the application invokes the template parsing logic, the recursive descent parser exhausts the call stack attempting to evaluate the nested nodes.

The rendering vector involves manipulating the data model passed to the engine. If the application serializes user-controlled data into an object that is subsequently rendered, the attacker can establish a self-referencing relationship. For example, creating an entity where ObjectA.Child = ObjectA. When Template.Render(context) is called, the renderer attempts to resolve the infinite loop.

The vulnerability directly compromises the availability of the application hosting the Scriban engine. The estimated CVSS v3.1 base score is 7.5, reflecting a network-based attack with low complexity, no required privileges, and a high impact on availability (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).

The consequence of a StackOverflowException in the .NET Common Language Runtime (CLR) is severe. The runtime considers stack corruption to be an unrecoverable state, meaning standard try/catch blocks surrounding the Scriban rendering logic will be completely bypassed. The operating system immediately terminates the application process.

In a production environment, this translates to the complete outage of the affected service. For web applications, the application pool or worker process will crash, dropping all current connections and requiring a restart. In a distributed architecture, repeated exploitation will cause continuous health check failures, leading load balancers or container orchestrators to perpetually cycle the service, resulting in extended downtime.

The most effective and comprehensive remediation is to update the Scriban NuGet package to the latest version published after March 2026, which includes the fix commit a6fe6074199e5c04f4d29dc8d8e652b24d33e3e4. The updated version safely handles deeply nested expressions and circular references by throwing manageable exceptions rather than crashing.

If an immediate upgrade is not feasible, developers must manually enforce the depth limits within their application code. This workaround exactly mirrors the logic introduced in the official patch and provides immediate protection against the vulnerability.

To apply the mitigation, the ObjectRecursionLimit must be set on every instantiated TemplateContext, and the ExpressionDepthLimit must be explicitly defined in the ParserOptions. Developers should ensure these limits are applied globally wherever the Scriban engine is initialized in the codebase.