Scriban
Monthly
Remote denial of service in Scriban before 6.6.0 allows unauthenticated attackers to crash the entire .NET hosting process by submitting deeply nested template expressions to the recursive-descent parser. Because the ExpressionDepthLimit property in ParserOptions defaults to null (disabled), an attacker can supply thousands of nested parentheses or blocks that exhaust thread stack space, triggering a StackOverflowException - which .NET cannot intercept - causing immediate, unrecoverable process termination. A proof-of-concept is publicly documented in the vendor's GitHub Security Advisory GHSA-wgh7-7m3c-fx25; no authentication is required, and the fix is available in version 6.6.0.
Scriban's template rendering engine before version 6.6.0 crashes the entire .NET hosting process when object graphs containing circular references are passed to the template context, because the ObjectRecursionLimit property defaults to 0 (unlimited) rather than a bounded safe value. Any endpoint that maps user-controlled input - such as a JSON request body or ORM entity graph - to a Scriban TemplateContext is susceptible to complete process termination with no authentication required (CVSS 4.0 AV:N/AC:L/PR:N). No public exploit or CISA KEV listing has been identified at time of analysis; however, a proof-of-concept is published in GitHub Security Advisory GHSA-grr9-747v-xvcp.
Process-terminating stack overflow in Scriban's template parser affects all versions before 7.0.0, allowing any attacker who can supply content to Template.Parse to crash the hosting .NET application via an uncatchable StackOverflowException. The flaw exploits a recursion path (ParseArrayInitializer → ParseExpression → ParseArrayInitializer) that is structurally separate from the ExpressionDepthLimit guard introduced in the prior fix for GHSA-wgh7-7m3c-fx25, meaning teams who applied that earlier patch retain a false sense of protection and remain fully vulnerable. A proof-of-concept is publicly available in the GitHub Security Advisory; no confirmed active exploitation appears in the CISA KEV catalog at time of analysis.
Information disclosure and authorization bypass in Scriban (the .NET text templating engine) before 7.0.0 lets attackers retrieve previously authorized include-template content from earlier renders. Because TemplateContext.Reset() clears output, globals, cultures, and source files but never clears the CachedTemplates dictionary, applications that pool a TemplateContext across requests and use a request-, tenant-, or user-dependent ITemplateLoader will serve a stale cached template to a later, less-privileged render without re-invoking TemplateLoader.Load(). A vendor patch exists (7.0.0) and a working proof-of-concept is published in the GHSA advisory, but there is no public exploit identified as used in active attacks.
Sandbox escape in the Scriban .NET templating engine (all versions before 7.0.0) lets attacker-influenced templates read object members that a tightened MemberFilter was meant to hide, because type accessors are cached by Type alone and survive both filter changes and TemplateContext.Reset(). Applications that reuse a single TemplateContext across requests or tenants and rely on MemberFilter as a security boundary can leak filtered properties and fields to a later, more-restricted render. Reported by VulnCheck with a working proof-of-concept in the vendor advisory; not listed in CISA KEV, and no EPSS score was provided in the source data.
Uncontrolled resource consumption in Scriban's .NET templating engine allows any party who can submit template input to bypass the LoopLimit safety control and exhaust CPU or memory on the host process. Versions 0 through 6.6.0 of the nuget/scriban and nuget/Scriban.Signed packages are affected; the root cause is that LoopLimit enforcement is coupled exclusively to script-level loop statements and is never invoked by built-in operators such as the range constructor or string multiplication. A working proof-of-concept is publicly available in the GitHub Security Advisory GHSA-c875-h985-hvrc, making exploitation trivially reproducible for any application that renders attacker-controlled templates; no public exploit identified at time of analysis for CISA KEV status.
Uncontrolled memory allocation in Scriban's string.pad_left and string.pad_right template functions enables unauthenticated remote denial of service against any application that exposes Scriban to attacker-controlled template input. All NuGet releases of scriban and scriban.Signed prior to 7.0.0 are affected, with a publicly documented 39-byte proof-of-concept payload capable of forcing ~1GB synchronous allocations per request, crashing the host process via OutOfMemoryException. No active exploitation has been confirmed in CISA KEV at time of analysis, but the trivial PoC and zero-complexity attack lower the effective risk bar significantly for exposed deployments.
Uncontrolled recursion in Scriban's `object.to_json` builtin allows any attacker who can submit template content to fatally terminate the hosting .NET process. The internal `WriteValue()` serialization function (ObjectFunctions.cs:494) recurses through object members and arrays without depth limits or circular reference detection - bypassing the `ObjectRecursionLimit`, `EnterRecursive()`, and `EnsureSufficientExecutionStack()` guards used everywhere else in Scriban. Because `StackOverflowException` is unrecoverable in .NET, a single crafted template request causes immediate, irreversible process death. No public exploit or CISA KEV listing identified at time of analysis; vendor-confirmed fix is available in version 7.0.0.
Denial of service in Scriban's .NET template engine (all versions before 7.0.0) allows low-privileged attackers who can supply templates to exhaust host application memory and crash the process. By rendering a string just under the 1MB LimitToString default inside a template loop, each iteration resets the per-call length counter in ObjectToString while the underlying StringBuilderOutput appends to a StringBuilder with no cumulative size guard - enabling ~1GB of allocation across 1,000 loop iterations. No public exploit tool has been separately released, but the GitHub security advisory (GHSA-m2p3-hwv5-xpqw) contains full source-level reproduction detail sufficient to implement the attack without further research.
Three distinct denial-of-service vulnerabilities in Scriban's expression evaluator (all versions before 7.0.0) allow any low-privileged attacker who can supply templates to exhaust host process memory or CPU, typically crashing the entire .NET application. The flaws are particularly deceptive because they bypass Scriban's own built-in safety controls - LimitToString and LoopLimit - through unbounded string multiplication, uncapped BigInteger left-shift operations, and lazy range enumeration passed to builtin functions, giving developers a false sense of protection. No public exploit has been identified at time of analysis, but the GHSA advisory provides full source-code-level disclosure of all three code paths with file and line references.
Unbounded memory allocation in Scriban's `array.insert_at` built-in function allows any template author to crash the host process with a single template call. Affected are all releases of the nuget/scriban and nuget/Scriban.Signed packages up to and including version 7.1.0. By supplying a sufficiently large index parameter, an attacker triggers a tight C# fill loop that allocates hundreds of millions of null entries, causing an `OutOfMemoryException` that terminates the host process in under a second - bypassing all existing safety controls including `LoopLimit` and `LimitToString`. A public proof-of-concept template is documented in the vendor's GHSA advisory; no CISA KEV listing has been issued at the time of analysis.
Process-terminating denial-of-service in Scriban 6.6.0-7.2.0 allows any network-reachable attacker to crash a host .NET application by submitting a crafted template containing deeply nested parentheses, array initializers, object initializers, or unary operators. The `ExpressionDepthLimit` parser guard is structurally non-enforcing: it logs a non-fatal error and sets a flag but never halts recursive descent, allowing the call stack to exhaust until an uncatchable `StackOverflowException` terminates the process - roughly achievable with an 8 KB payload. This is a regression that re-opens two previously reported 'fixed' advisories (GHSA-wgh7-7m3c-fx25, fixed in 6.6.0; GHSA-p6q4-fgr8-vx4p, fixed in 7.0.0), confirming both prior fixes are incomplete; no public exploit or KEV listing exists at time of analysis.
Resource exhaustion in Scriban 3.0.0 through 7.2.0 allows unauthenticated remote attackers to force multi-gigabyte memory allocations using a ~40-byte template containing the array multiplication operator. The flaw is an overlooked sibling of operations hardened in prior releases: `string * integer` and `array.insert_at` received LoopLimit guards in versions 7.0.0 and 7.2.0, but `array * integer` in `ScriptArray<T>.TryEvaluate` was never subjected to those checks. The vendor-released fix is available in Scriban 7.2.1 and Scriban.Signed 7.2.1; no public exploit identified at time of analysis.
Arbitrary CLR property writes in Scriban (the .NET templating engine) before 7.2.2 allow template code to mutate live host objects passed into a TemplateContext, bypassing C# setter-visibility rules entirely. Any object pushed via the documented ScriptObject pattern becomes fully writable, so template authors can set private, internal, and init-only setters as well as mass-assign public ones (e.g. {{ user.is_admin = true }}), and the changes persist on the host object after Render() returns. Publicly available proof-of-concept steps exist in the GHSA advisory; no active exploitation is reported (not in CISA KEV) and no EPSS score was supplied.
Scriban template engine versions 3.0.0 through 7.2.5 expose any application accepting untrusted templates to complete CPU exhaustion and garbage collection collapse via crafted array-multiplication expressions. The ScriptArray.Multiply operator fails to credit iterations against the caller-configured LoopLimit, rendering the safety mechanism entirely ineffective on this code path - even LoopLimit=1 provides no protection against the bypass. Vendor patches are available as two upstream commits referenced in GitHub security advisory GHSA-89cf-6hmv-8rxm, with no active exploitation confirmed at time of analysis.
Remote denial of service in Scriban before 6.6.0 allows unauthenticated attackers to crash the entire .NET hosting process by submitting deeply nested template expressions to the recursive-descent parser. Because the ExpressionDepthLimit property in ParserOptions defaults to null (disabled), an attacker can supply thousands of nested parentheses or blocks that exhaust thread stack space, triggering a StackOverflowException - which .NET cannot intercept - causing immediate, unrecoverable process termination. A proof-of-concept is publicly documented in the vendor's GitHub Security Advisory GHSA-wgh7-7m3c-fx25; no authentication is required, and the fix is available in version 6.6.0.
Scriban's template rendering engine before version 6.6.0 crashes the entire .NET hosting process when object graphs containing circular references are passed to the template context, because the ObjectRecursionLimit property defaults to 0 (unlimited) rather than a bounded safe value. Any endpoint that maps user-controlled input - such as a JSON request body or ORM entity graph - to a Scriban TemplateContext is susceptible to complete process termination with no authentication required (CVSS 4.0 AV:N/AC:L/PR:N). No public exploit or CISA KEV listing has been identified at time of analysis; however, a proof-of-concept is published in GitHub Security Advisory GHSA-grr9-747v-xvcp.
Process-terminating stack overflow in Scriban's template parser affects all versions before 7.0.0, allowing any attacker who can supply content to Template.Parse to crash the hosting .NET application via an uncatchable StackOverflowException. The flaw exploits a recursion path (ParseArrayInitializer → ParseExpression → ParseArrayInitializer) that is structurally separate from the ExpressionDepthLimit guard introduced in the prior fix for GHSA-wgh7-7m3c-fx25, meaning teams who applied that earlier patch retain a false sense of protection and remain fully vulnerable. A proof-of-concept is publicly available in the GitHub Security Advisory; no confirmed active exploitation appears in the CISA KEV catalog at time of analysis.
Information disclosure and authorization bypass in Scriban (the .NET text templating engine) before 7.0.0 lets attackers retrieve previously authorized include-template content from earlier renders. Because TemplateContext.Reset() clears output, globals, cultures, and source files but never clears the CachedTemplates dictionary, applications that pool a TemplateContext across requests and use a request-, tenant-, or user-dependent ITemplateLoader will serve a stale cached template to a later, less-privileged render without re-invoking TemplateLoader.Load(). A vendor patch exists (7.0.0) and a working proof-of-concept is published in the GHSA advisory, but there is no public exploit identified as used in active attacks.
Sandbox escape in the Scriban .NET templating engine (all versions before 7.0.0) lets attacker-influenced templates read object members that a tightened MemberFilter was meant to hide, because type accessors are cached by Type alone and survive both filter changes and TemplateContext.Reset(). Applications that reuse a single TemplateContext across requests or tenants and rely on MemberFilter as a security boundary can leak filtered properties and fields to a later, more-restricted render. Reported by VulnCheck with a working proof-of-concept in the vendor advisory; not listed in CISA KEV, and no EPSS score was provided in the source data.
Uncontrolled resource consumption in Scriban's .NET templating engine allows any party who can submit template input to bypass the LoopLimit safety control and exhaust CPU or memory on the host process. Versions 0 through 6.6.0 of the nuget/scriban and nuget/Scriban.Signed packages are affected; the root cause is that LoopLimit enforcement is coupled exclusively to script-level loop statements and is never invoked by built-in operators such as the range constructor or string multiplication. A working proof-of-concept is publicly available in the GitHub Security Advisory GHSA-c875-h985-hvrc, making exploitation trivially reproducible for any application that renders attacker-controlled templates; no public exploit identified at time of analysis for CISA KEV status.
Uncontrolled memory allocation in Scriban's string.pad_left and string.pad_right template functions enables unauthenticated remote denial of service against any application that exposes Scriban to attacker-controlled template input. All NuGet releases of scriban and scriban.Signed prior to 7.0.0 are affected, with a publicly documented 39-byte proof-of-concept payload capable of forcing ~1GB synchronous allocations per request, crashing the host process via OutOfMemoryException. No active exploitation has been confirmed in CISA KEV at time of analysis, but the trivial PoC and zero-complexity attack lower the effective risk bar significantly for exposed deployments.
Uncontrolled recursion in Scriban's `object.to_json` builtin allows any attacker who can submit template content to fatally terminate the hosting .NET process. The internal `WriteValue()` serialization function (ObjectFunctions.cs:494) recurses through object members and arrays without depth limits or circular reference detection - bypassing the `ObjectRecursionLimit`, `EnterRecursive()`, and `EnsureSufficientExecutionStack()` guards used everywhere else in Scriban. Because `StackOverflowException` is unrecoverable in .NET, a single crafted template request causes immediate, irreversible process death. No public exploit or CISA KEV listing identified at time of analysis; vendor-confirmed fix is available in version 7.0.0.
Denial of service in Scriban's .NET template engine (all versions before 7.0.0) allows low-privileged attackers who can supply templates to exhaust host application memory and crash the process. By rendering a string just under the 1MB LimitToString default inside a template loop, each iteration resets the per-call length counter in ObjectToString while the underlying StringBuilderOutput appends to a StringBuilder with no cumulative size guard - enabling ~1GB of allocation across 1,000 loop iterations. No public exploit tool has been separately released, but the GitHub security advisory (GHSA-m2p3-hwv5-xpqw) contains full source-level reproduction detail sufficient to implement the attack without further research.
Three distinct denial-of-service vulnerabilities in Scriban's expression evaluator (all versions before 7.0.0) allow any low-privileged attacker who can supply templates to exhaust host process memory or CPU, typically crashing the entire .NET application. The flaws are particularly deceptive because they bypass Scriban's own built-in safety controls - LimitToString and LoopLimit - through unbounded string multiplication, uncapped BigInteger left-shift operations, and lazy range enumeration passed to builtin functions, giving developers a false sense of protection. No public exploit has been identified at time of analysis, but the GHSA advisory provides full source-code-level disclosure of all three code paths with file and line references.
Unbounded memory allocation in Scriban's `array.insert_at` built-in function allows any template author to crash the host process with a single template call. Affected are all releases of the nuget/scriban and nuget/Scriban.Signed packages up to and including version 7.1.0. By supplying a sufficiently large index parameter, an attacker triggers a tight C# fill loop that allocates hundreds of millions of null entries, causing an `OutOfMemoryException` that terminates the host process in under a second - bypassing all existing safety controls including `LoopLimit` and `LimitToString`. A public proof-of-concept template is documented in the vendor's GHSA advisory; no CISA KEV listing has been issued at the time of analysis.
Process-terminating denial-of-service in Scriban 6.6.0-7.2.0 allows any network-reachable attacker to crash a host .NET application by submitting a crafted template containing deeply nested parentheses, array initializers, object initializers, or unary operators. The `ExpressionDepthLimit` parser guard is structurally non-enforcing: it logs a non-fatal error and sets a flag but never halts recursive descent, allowing the call stack to exhaust until an uncatchable `StackOverflowException` terminates the process - roughly achievable with an 8 KB payload. This is a regression that re-opens two previously reported 'fixed' advisories (GHSA-wgh7-7m3c-fx25, fixed in 6.6.0; GHSA-p6q4-fgr8-vx4p, fixed in 7.0.0), confirming both prior fixes are incomplete; no public exploit or KEV listing exists at time of analysis.
Resource exhaustion in Scriban 3.0.0 through 7.2.0 allows unauthenticated remote attackers to force multi-gigabyte memory allocations using a ~40-byte template containing the array multiplication operator. The flaw is an overlooked sibling of operations hardened in prior releases: `string * integer` and `array.insert_at` received LoopLimit guards in versions 7.0.0 and 7.2.0, but `array * integer` in `ScriptArray<T>.TryEvaluate` was never subjected to those checks. The vendor-released fix is available in Scriban 7.2.1 and Scriban.Signed 7.2.1; no public exploit identified at time of analysis.
Arbitrary CLR property writes in Scriban (the .NET templating engine) before 7.2.2 allow template code to mutate live host objects passed into a TemplateContext, bypassing C# setter-visibility rules entirely. Any object pushed via the documented ScriptObject pattern becomes fully writable, so template authors can set private, internal, and init-only setters as well as mass-assign public ones (e.g. {{ user.is_admin = true }}), and the changes persist on the host object after Render() returns. Publicly available proof-of-concept steps exist in the GHSA advisory; no active exploitation is reported (not in CISA KEV) and no EPSS score was supplied.
Scriban template engine versions 3.0.0 through 7.2.5 expose any application accepting untrusted templates to complete CPU exhaustion and garbage collection collapse via crafted array-multiplication expressions. The ScriptArray.Multiply operator fails to credit iterations against the caller-configured LoopLimit, rendering the safety mechanism entirely ineffective on this code path - even LoopLimit=1 provides no protection against the bypass. Vendor patches are available as two upstream commits referenced in GitHub security advisory GHSA-89cf-6hmv-8rxm, with no active exploitation confirmed at time of analysis.