Track vulnerabilities like this one.
Sign up free to get alerted when software you use is affected.
7.5
Scriban Template Parsing Causes Stack Overflow
published 7 months ago
Summary
A vulnerability in Scriban template parsing can cause a program to crash with a stack overflow error when processing certain types of input. This can happen even if the ExpressionDepthLimit is set to prevent other types of crashes. To protect against this, you should validate and sanitize any user input before passing it to Scriban's Template.Parse method.
What to do
- Update alexandre mutel scriban to version 7.0.0.
- Update alexandre mutel scriban.signed to version 7.0.0.
Affected software
| Ecosystem | Vendor | Product | Affected versions |
|---|---|---|---|
| NuGet | alexandre mutel | scriban |
< 7.0.0 Fix: upgrade to 7.0.0
|
| NuGet | alexandre mutel | scriban.signed |
< 7.0.0 Fix: upgrade to 7.0.0
|
Original advisory text
Scriban has a Stack Overflow via Nested Array Initializers That Bypass the ExpressionDepthLimit Fix
### Summary
StackOverflowException via nested array initializers bypasses ExpressionDepthLimit fix (GHSA-wgh7-7m3c-fx25)
### Details
The recent fix for GHSA-wgh7-7m3c-fx25 (uncontrolled recursion in parser) added `ExpressionDepthLimit` defaulting to 250. However, deeply nested **array initializers** (`[[[[...`) recurse through `ParseArrayInitializer` → `ParseExpression` → `ParseArrayInitializer`, which is a **different recursion path** not covered by the expression depth counter.
This causes a `StackOverflowException` on current main (commit b5ac4bf - "Add limits for default safety").
### PoC
```
using Scriban;
// ExpressionDepthLimit (default 250) does NOT prevent this crash
string nested = "{{ " + new string('[', 5000) + "1" + new string(']', 5000) + " }}";
Template.Parse(nested); // StackOverflowException - process terminates
```
### Impact
Same as GHSA-wgh7-7m3c-fx25: High severity. StackOverflowException cannot be caught with try/catch in .NET - the process terminates immediately. Any application calling Template.Parse with untrusted input is vulnerable, even with the new default ExpressionDepthLimit enabled.
StackOverflowException via nested array initializers bypasses ExpressionDepthLimit fix (GHSA-wgh7-7m3c-fx25)
### Details
The recent fix for GHSA-wgh7-7m3c-fx25 (uncontrolled recursion in parser) added `ExpressionDepthLimit` defaulting to 250. However, deeply nested **array initializers** (`[[[[...`) recurse through `ParseArrayInitializer` → `ParseExpression` → `ParseArrayInitializer`, which is a **different recursion path** not covered by the expression depth counter.
This causes a `StackOverflowException` on current main (commit b5ac4bf - "Add limits for default safety").
### PoC
```
using Scriban;
// ExpressionDepthLimit (default 250) does NOT prevent this crash
string nested = "{{ " + new string('[', 5000) + "1" + new string(']', 5000) + " }}";
Template.Parse(nested); // StackOverflowException - process terminates
```
### Impact
Same as GHSA-wgh7-7m3c-fx25: High severity. StackOverflowException cannot be caught with try/catch in .NET - the process terminates immediately. Any application calling Template.Parse with untrusted input is vulnerable, even with the new default ExpressionDepthLimit enabled.
References
Internet-facing
14 days
Internal
60 days
- Not known to be exploited
- Can be exploited automatically (estimated)
- Gives an attacker partial control (estimated)
Type
CWE-674Uncontrolled Recursion
Timeline
Published24 Mar 2026
Updated6 Jul 2026
First seen6 Jul 2026
Sources
GHSA-p6q4-fgr8-vx4p · OSV
Track software like this
Free during beta