CVE-2026-74795

The CVSS 7.5 rating for CVE-2026-74795 does not capture what makes this vulnerability distinct: it produces a StackOverflowException, the only exception in .NET that cannot be caught. When triggered, the process dies immediately and permanently. There is no graceful degradation, no opportunity to log the failure, no restart policy that gets a chance to execute cleanly. The hosting application does not decide what happens next — the process simply terminates. This changes the risk calculus from service degradation to immediate hard failure requiring process restart, which is a fundamentally different class of denial-of-service than typical resource exhaustion vulnerabilities. The root cause is that Scriban's ExpressionDepthLimit defaults to null (unlimited), allowing arbitrarily deep template nesting to exhaust the call stack. This was almost certainly a developer-experience decision — complex templates during development would hit limits and throw, so disabling the limit felt natural. But Scriban is explicitly positioned as a secure alternative to scripting, which means it is likely deployed in contexts where untrusted template input reaches the parser. The burden of safe configuration should not rest on every downstream developer who may not even know this option exists in ParserOptions. What you should check: if your application uses Scriban to render templates from any source you do not fully control (user input, stored templates, external API payloads), verify that ParserOptions.ExpressionDepthLimit is set to a finite value. The fix in version 6.6.0 defaults this to a sensible value, but audit your dependency tree — Scriban is frequently a transitive dependency embedded in CMS platforms, code generators, and documentation tools. You may be loading it without ever invoking it directly, and your transitive dependency may be several versions behind the fix. The practical question is whether the fix introduces breaking changes. Legitimate complex templates pushing deep nesting could hit a restrictive default in production. If your deployment relies on deep template structures, test against 6.6.0 before upgrading and understand how to tune the limit if needed. The patch addresses the vulnerability, but the discoverability problem remains — ExpressionDepthLimit remains buried in ParserOptions, meaning the next developer who hits a limit may simply disable it again without understanding the security cost.

Reviewed through automated stages and approved by a human before publication.