CVE-2026-74783

CVE-2026-74783 in Scriban exposes a critical deception in the library's security contract: the ExpressionDepthLimit parameter documented in the API was never actually enforced during parsing. This is not a guard that failed — it's a guard that exists only on paper. If your application uses Scriban to parse templates from any untrusted source (user-generated content, API inputs, file uploads), you have a depth-of-recursion vulnerability that your documentation says is protected against but absolutely is not. The technical failure is straightforward: recursive expression parsing in Scriban's template engine does not check or respect the ExpressionDepthLimit configuration value. Adversarial input is trivial to construct — deeply nested parentheses or array initializers exceeding the .NET stack threshold will trigger StackOverflowException, and because this exception is uncatchable in .NET, your application process terminates immediately. Try/catch blocks, global exception handlers, and graceful degradation strategies are all bypassed. This breaks the fundamental reliability contract most applications depend on: user input causes error, error gets handled, application continues. The more dangerous dimension is the organizational trust layer. ExpressionDepthLimit appears in public API documentation as a security parameter. Security audits that look for declared safeguards will find it and reasonably conclude protection exists. WAF rulesets may exclude Scriban from depth-testing on that basis. Code review scopes may mark it as already addressed. Every downstream trust decision made on the false premise of enforcement expands the real blast radius beyond the immediate code path. What to check: Audit your Scriban integration for any untrusted template input paths. Evaluate whether depth limits were ever actually tested in your integration. Note that the current library version may not contain the fix yet — the remediation requires the maintainers to actually wire the enforcement, not just document it. Until that fix ships and you update, consider wrapping Scriban in a separate process boundary with aggressive depth validation at the input layer, accepting that any template parsing from untrusted sources carries uncatchable termination risk.

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