Scriban has Uncontrolled Recursion in Parser Leads to Stack Overflow and Process Crash (Denial of Service)
Scriban is vulnerable to an uncontrolled process crash resulting in a Denial of Service. Because the recursive-descent parser does not enforce a default limit on expression depth, an attacker who controls template input can craft a heavily nested template that triggers a `StackOverflowException`. In .NET, a `StackOverflowException` cannot be caught by standard `try-catch` blocks, resulting in the immediate and ungraceful termination of the entire hosting process. Scriban utilizes a recursive-descent parser to process template expressions. While the library exposes an `ExpressionDepthLimit` property in its `ParserOptions`, this property defaults to `null` (disabled). If an application accepts user-supplied templates (or dynamically constructs templates from untrusted input), an attacker can supply thousands of nested parentheses or blocks. As the parser recursively evaluates each nested layer, it consumes thread stack space until it exceeds the limits of the host OS, triggering a fatal crash. #### Impact An attacker can supply crafted input that triggers a `StackOverflowException`, causing immediate termination of the hosting process and resulting in a Denial of Service. In applications that process untrusted or user-controlled templates (e.g., web applications or APIs), this can be exploited remotely without authentication. The failure is not recoverable, requiring a full process restart and leading to service disruption. #### Proof of Concept (PoC) The following C# code demonstrates the vulnerability. Executing this code will immediately terminate the application process. ```csharp using Scriban; // Creates a deeply nested expression: (((( ... (1) ... )))) string nested = new string('(', 10000) + "1" + new string(')', 10000); try { // This will crash the entire process immediately Scriban.Template.Parse("{{ " + nested + " }}"); } catch (Exception ex) { // This catch block will never execute because StackOverflowException Console.WriteLine("Caught exception: " + ex.Message); } ``` #### Suggested Remediation Update the `ParserOptions` constructor (or the internal parser initialization) to set a default value for `ExpressionDepthLimit`. A limit of `1000` (or even lower, such as `250` or `500`) is generally more than enough for legitimate templates while safely preventing stack exhaustion. ```csharp public int? ExpressionDepthLimit { get; set; } = 250; ``` Alternatively, document the risk heavily and warn developers to manually set `ExpressionDepthLimit` if evaluating untrusted templates, though a secure-by-default approach is strongly preferred.
AI Analysis
Technical Summary
Scriban's recursive-descent parser lacks a default limit on expression depth, exposing versions before 6.6.0 to a denial of service via stack overflow. An attacker who controls template input can supply thousands of nested parentheses or blocks, causing the parser to exhaust thread stack space and trigger a StackOverflowException. Because .NET does not allow catching StackOverflowException with standard try-catch blocks, the entire hosting process terminates immediately and ungracefully. The library exposes an ExpressionDepthLimit property in ParserOptions, but it defaults to null (disabled), leaving applications vulnerable unless this limit is explicitly set. The recommended remediation is to set a safe default limit (e.g., 250) on ExpressionDepthLimit to prevent stack exhaustion.
Potential Impact
Exploitation results in immediate termination of the hosting process due to an uncaught StackOverflowException, causing a denial of service. Applications processing untrusted or user-controlled templates can be remotely exploited without authentication. The failure is not recoverable without restarting the process, leading to service disruption.
Mitigation Recommendations
Set the ExpressionDepthLimit property in Scriban's ParserOptions to a safe default value (e.g., 250) to limit expression nesting depth and prevent stack overflow. This can be done by updating the parser initialization or constructor to enforce this limit. If updating is not possible, developers should be heavily warned to manually configure ExpressionDepthLimit when evaluating untrusted templates. No official patch link is provided; patch status is not yet confirmed—check vendor advisories for updates.
Scriban has Uncontrolled Recursion in Parser Leads to Stack Overflow and Process Crash (Denial of Service)
Description
Scriban is vulnerable to an uncontrolled process crash resulting in a Denial of Service. Because the recursive-descent parser does not enforce a default limit on expression depth, an attacker who controls template input can craft a heavily nested template that triggers a `StackOverflowException`. In .NET, a `StackOverflowException` cannot be caught by standard `try-catch` blocks, resulting in the immediate and ungraceful termination of the entire hosting process. Scriban utilizes a recursive-descent parser to process template expressions. While the library exposes an `ExpressionDepthLimit` property in its `ParserOptions`, this property defaults to `null` (disabled). If an application accepts user-supplied templates (or dynamically constructs templates from untrusted input), an attacker can supply thousands of nested parentheses or blocks. As the parser recursively evaluates each nested layer, it consumes thread stack space until it exceeds the limits of the host OS, triggering a fatal crash. #### Impact An attacker can supply crafted input that triggers a `StackOverflowException`, causing immediate termination of the hosting process and resulting in a Denial of Service. In applications that process untrusted or user-controlled templates (e.g., web applications or APIs), this can be exploited remotely without authentication. The failure is not recoverable, requiring a full process restart and leading to service disruption. #### Proof of Concept (PoC) The following C# code demonstrates the vulnerability. Executing this code will immediately terminate the application process. ```csharp using Scriban; // Creates a deeply nested expression: (((( ... (1) ... )))) string nested = new string('(', 10000) + "1" + new string(')', 10000); try { // This will crash the entire process immediately Scriban.Template.Parse("{{ " + nested + " }}"); } catch (Exception ex) { // This catch block will never execute because StackOverflowException Console.WriteLine("Caught exception: " + ex.Message); } ``` #### Suggested Remediation Update the `ParserOptions` constructor (or the internal parser initialization) to set a default value for `ExpressionDepthLimit`. A limit of `1000` (or even lower, such as `250` or `500`) is generally more than enough for legitimate templates while safely preventing stack exhaustion. ```csharp public int? ExpressionDepthLimit { get; set; } = 250; ``` Alternatively, document the risk heavily and warn developers to manually set `ExpressionDepthLimit` if evaluating untrusted templates, though a secure-by-default approach is strongly preferred.
CVSS v3.1
Score 7.5high
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
Scriban's recursive-descent parser lacks a default limit on expression depth, exposing versions before 6.6.0 to a denial of service via stack overflow. An attacker who controls template input can supply thousands of nested parentheses or blocks, causing the parser to exhaust thread stack space and trigger a StackOverflowException. Because .NET does not allow catching StackOverflowException with standard try-catch blocks, the entire hosting process terminates immediately and ungracefully. The library exposes an ExpressionDepthLimit property in ParserOptions, but it defaults to null (disabled), leaving applications vulnerable unless this limit is explicitly set. The recommended remediation is to set a safe default limit (e.g., 250) on ExpressionDepthLimit to prevent stack exhaustion.
Potential Impact
Exploitation results in immediate termination of the hosting process due to an uncaught StackOverflowException, causing a denial of service. Applications processing untrusted or user-controlled templates can be remotely exploited without authentication. The failure is not recoverable without restarting the process, leading to service disruption.
Mitigation Recommendations
Set the ExpressionDepthLimit property in Scriban's ParserOptions to a safe default value (e.g., 250) to limit expression nesting depth and prevent stack overflow. This can be done by updating the parser initialization or constructor to enforce this limit. If updating is not possible, developers should be heavily warned to manually configure ExpressionDepthLimit when evaluating untrusted templates. No official patch link is provided; patch status is not yet confirmed—check vendor advisories for updates.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-wgh7-7m3c-fx25
- Osv Schema Version
- 1.4.0
- Aliases
- []
- Ecosystems
- ["NuGet"]
- Database Specific Severity
- HIGH
- Cvss Version
- 3.1
Threat ID: 6a4c346127e9c79719600aef
Added to database: 07/06/2026, 23:04:01 UTC
Last enriched: 07/06/2026, 23:34:16 UTC
Last updated: 07/31/2026, 12:27:30 UTC
Views: 18
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.
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.