Description

Scriban before 7.0.0 (affected versions <= 6.6.0) contains a stack overflow vulnerability in nested array initializer parsing. Deeply nested array initializers recurse through a path (ParseArrayInitializer → ParseExpression → ParseArrayInitializer) that is not covered by the ExpressionDepthLimit counter added in the fix for GHSA-wgh7-7m3c-fx25. An attacker who can supply untrusted input to Template.Parse can trigger an uncatchable StackOverflowException that immediately terminates the process, even with the default ExpressionDepthLimit enabled.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-08-16T14:16:57.317Z",
  "pubdate": "2026-08-16T14:16:57.317Z",
  "executiveSummary": "Scriban versions 6.6.0 and prior, specifically before 7.0.0, contain a stack overflow vulnerability originating from nested array initializer parsing. The vulnerability allows an unauthenticated remote attacker capable of supplying untrusted input to the template parsing engine to trigger an uncatchable StackOverflowException. This condition immediately terminates the host process, resulting in a complete denial of service (DoS) for the affected system. The issue arises because deeply nested array initializers recurse through parser functions without being intercepted by the existing ExpressionDepthLimit counter. This bypass defeats the default expression depth limitations, making applications that process untrusted templates via Template.Parse susceptible to application crashes. Remediation requires updating Scriban to version 7.0.0 or later, where the recursive parsing paths for array initializers are properly bounded by depth limit controls.",
  "technicalDetails": "The vulnerability resides in the parsing engine of the Scriban template parser, specifically within the handling of array initializers. The root cause of the flaw is an unchecked recursive invocation path during the parsing of nested array structures. Specifically, the parser alternates recursively through the functions ParseArrayInitializer, ParseExpression, and back to ParseArrayInitializer. Although a previous security patch introduced the ExpressionDepthLimit counter to mitigate similar stack exhaustion issues (referenced under GHSA-wgh7-7m3c-fx25), this specific code path for nested array initializers was omitted from depth limitation checks.\nAn attacker exploits this vulnerability by supplying a crafted malicious payload containing heavily nested array initializers to the Template.Parse method. When the parser encounters this deeply nested structure, it recursively allocates stack frames for each level of nesting without decrementing or evaluating an effective depth tracking counter. Because the ExpressionDepthLimit mechanism fails to cover this specific recursive cycle, the recursion continues unchecked until the thread stack is exhausted. This triggers a catastrophic StackOverflowException in the underlying runtime environment. In managed environments like .NET, a StackOverflowException cannot be caught by standard try-catch blocks, causing the entire host process to terminate immediately and unconditionally.\nThe exploitation vector requires no authentication, specific user interaction, or elevated privileges, provided the application exposes an interface where untrusted input is processed by Template.Parse. The attack surface is directly exposed across any network boundary or internal API that consumes external template data. Post-exploitation impact is strictly limited to denial of service through process termination, as arbitrary code execution is typically not achievable via stack overflow exceptions in memory-managed runtimes."
}