The CVSS 7.5 rating for CVE-2026-74792 misrepresents the actual severity. The vulnerability—a stack overflow in Scriban's array initializer parsing path—is analytically distinct from typical DoS flaws for two reasons the rating omits entirely.
First, this stack overflow bypasses a prior security control. When GHSA-wgh7-7m3c-fx25 was disclosed, developers added ExpressionDepthLimit to mitigate recursion risk. That fix covered one recursion path through the parser, but the array initializer path (ParseArrayInitializer → ParseExpression → ParseArrayInitializer) was apparently not in scope. The advisory presented ExpressionDepthLimit as the fix, creating a false sense of closure while leaving a specific bypass vector intact. This is not a case of a vulnerability with a mitigation—it is a case of a vulnerability with a demonstrated failed mitigation, a qualitatively different situation the CVSS framework has no vocabulary for.
Second, StackOverflowException in .NET is architecturally uncatchable. Unlike most exceptions that can be trapped, logged, or handled gracefully, StackOverflowException terminates the process immediately. For applications that parse user-supplied templates—email systems, document generators, web frameworks with dynamic rendering—a single malformed input containing a deeply nested array initializer collapses the entire process. All concurrent requests on that process lose their connection mid-response. Connection pools drain, health checks fail, and dependent services face retry storms. This is not a 500 error; it is a service outage event with blast radius properties that CVSS captures as simply "process crash possible."
The pattern is not unique to Scriban. It is the Nth instance of a two-decade sequence: XML entity expansion limits, quadratic blowup workarounds, and now this. Each iteration adds a guard at an observed recursion point while leaving obscure paths unmeasured. The sediment accumulates because security advisories present targeted fixes without explicitly warning that comprehensive recursion-graph coverage is required for depth limits to be meaningful. The Scriban team wasn't careless—they worked within constraints that make enumerating all recursion cycles structurally difficult without tooling that doesn't exist in most workflows. But that doesn't change the outcome: a control that shipped with false completeness guarantees.
For defenders: verify your Scriban version, audit whether template rendering from untrusted input occurs in long-running services, and treat the current ExpressionDepthLimit as a partial mitigation rather than a complete fix. The vulnerability is not merely a crash bug—it is a demonstration that parser depth limits require formal recursion-graph analysis to be effective, a property no current guidance makes explicit.