Scriban's ObjectRecursionLimit property defaults to unlimited, and when that limit is hit during template rendering, the result is not a catchable exception — it's a StackOverflowException that terminates the process outright. No try/catch, no middleware, no defensive wrapper can recover from this. The developer who wanted to be careful had no mechanism to make this safe at runtime because the language itself denies the possibility.
This is the critical insight: the vulnerability isn't just an unsafe default. It's an architectural permission for an unrecoverable failure mode to exist at all. A finite default (which 6.6.0 introduces) reduces blast radius, but it doesn't eliminate the structural problem — if an attacker can push recursive traversal to the configured limit, the process still dies from an uncatchable StackOverflow. The fix is correct, but it addresses the default, not the deeper design assumption that the engine could be driven to an unrecoverable state.
For defenders, the priority is straightforward: identify whether Scriban appears in your dependency tree, check the version, and upgrade to 6.6.0 or later. This matters because Scriban renders templates against arbitrary object graphs in web applications, serialization pipelines, logging systems, and domain models — anywhere data from user-adjacent sources can reach the rendering engine. The attack surface isn't limited to direct template injection; it's any channel where circular object references can flow into Scriban.
The CVSS 7.5 framing deserves scrutiny. The score doesn't distinguish between 'direct template injection' and 'complex domain model that an attacker partially influences through legitimate channels.' The latter is the common case in real applications, which means the vulnerability is actually harder to judge than to exploit — but devastating when triggered. That asymmetry is characteristic of this vulnerability class and generic severity scoring smooths over it.
The temporal dimension matters: even after 6.6.0 ships, every existing deployment running older versions is still detonating. In infrastructure with pinned dependencies or transitive Scriban usage, patching may not happen for months. The blast radius extends forward in time through every unpatched deployment, not just ones currently under active exploitation. Assume your templates can receive circular references from any data source until you've upgraded and explicitly configured a finite recursion limit.